Depending on your requirements and use cases, the standard methods of Unit Of Work may not be appropriate. The following is a list of some use cases that are not handled by default and may require a custom work callback to be registered:

• Self and recursive referencing: Records within the same object that have lookups to each other are not currently supported, for example, account hierarchies.
• More granular DML operations: The Database class methods allow the ability to permit some records to be processed when others fail. The DML statements executed in the Unit Of Work are defaulted to all or nothing.
• Sending emails: Sending emails is considered a part of the current transaction; if you want to register this kind of work with the Unit Of Work, you can do so via the registerEmail method. Multiple registrations will be automatically bulkified.

The following is a template for registering a customer work callback handler with Unit Of Work. This will be called during the commitWork method within the transaction scope it creates. This means that if work fails in this work callback, it will also call other work registered with the same Unit Of Work to rollback.

Take a look at the following code:

public inherited sharing class CustomAccountWork implements
    fflib_SObjectUnitOfWork.IDoWork { 
 
   private List<Account> accounts; 
 
   public CustomAccountWork (List<Account> accounts) { 
      this.accounts = accounts; 
   } 
 
   public void doWork(){ 
      // Do some custom account work e.g. hierarchies 
   } 
} 

Then, register the custom work as per the following example:

uow.registerNew... 
uow.registerDirty... 
uow.registerDeleted... 
uow.registerWork(new CustomAccountWork(accounts)); 
uow.commitWork(); 

The Unit Of Work pattern described in the proceeding sections helps you focus your coding efforts on implementing business logic and not on how records are persisted. In the next section, we will look at some more advanced service-related concepts.