In order to call a business policy immediately when a record is created or updated, you need to:

  • Set up an APEX trigger to call the Decisions on Demand API for the appropriate object type and event
  • Activate the trigger from the policy detail page

A business policy will only be invoked if the Decisions on Demand API is called for the relevant trigger event and that event is enabled on the policy detail page. The latter step allows you to control the activation of a business policy with a few clicks at any time without making APEX code changes. 


Only one APEX trigger is needed per object type, but multiple Decisions on Demand business policies can be active for the same object. The code can be integrated into an existing trigger, or you can create a standalone trigger for Decisions on Demand.


NOTE: this article describes the API for Decisions on Demand 1.15 or later. If you are using version 1.14 please refer to this article.


Setting up an APEX trigger

API calls

To add a trigger to an object login to a Sandbox and go to Setup > Object Manager > Object Name > Trigger and click 'New'

  • The following code can be used in a standalone Trigger on the Lead object:
    trigger DecsOnD_LeadTrigger on Lead (after insert, after update, after delete) {  
    DecsOnD.InvocationFacade.executeFromTriggerAll(); 
}
    For other objects, just replace Lead by the name of the applicable object
  • If you are updating an existing trigger add the following line to call the Decisions on Demand API:
    DecsOnD.InvocationFacade.executeFromTriggerAll();

Notes:

  • The policy will be invoked asynchronously -- any actions will only be applied after the trigger completes
  • In all cases, the API should called in the after event -- API calls from before triggers are ignored, as are calls made from unit tests or non-trigger contexts
  • The return value will be null on successful invocation
  • If there are errors, the API will return a map of record IDs to the error messages returned for those records
    For a global failure, the map will contain one entry with the error message under the GLOBAL key
  • You can optionally pass a batch size to the calls above
    For example: DecsOnD.InvocationFacade.executeFromTriggerAll(50); 
    This is required only if you are encountering timeout issues and want to strictly enforce a maximum size on callouts to our server.
    If a batch size is specified in the code as well as in the UI, the smaller of the two numbers will be used
  • Please refer to the Salesforce documentation here for information on creating a test class to deploy with your trigger


Trigger events

You only need to call the API for the events that actually need to trigger your policy. But we recommend including the code for all three events (insert, update and delete), to avoid having to make APEX changes if you later decide to enable those events. The overhead of calling the API if no policies are active for that event is low.


Related objects

If your policy needs to be triggered on insert, update or delete of related objects, you should create a trigger for those objects as well. 


For instance, if you have an Account Assignment policy, and you want to trigger a reassignment when a new opportunity is created for an account, you would need to activate a trigger for the insert event on the Opportunity object. Decisions on Demand will automatically determine the relevant Account from the Opportunity. A trigger on delete will not work with the master object. It will only work on the related child object(s).


See the Administrator Guide for more details, including a complete code example for a standalone trigger.


Activating triggers for your business policy

Setting up the trigger in the step above will call the Decisions on Demand API whenever relevant insert, update or delete events occur. This can result in the invocation of zero, one, or multiple business policies.

To activate and configure trigger-based invocation for a specific policy, go to the Trigger Settings section on the policy detail page. There, you can select the objects and events that should trigger a re-evaluation of the rules. You can also indicate in which cases you would like an Execution record to be created, and whether to send you an email on trigger failure.

You can enter the following:

  • Where Clause
    • This (optionally) allows you to select a subset of records to which the policy will be applied.
      For example, Industry = ’Insurance’ will select only records with the Industry field set to 'Insurance'.
    • The format of the where clause is defined by the SOQL language, see here for details.
    • To validate the syntax of your WHERE clause, press the Tab key or click outside of the text box. This will also display the number of records that match the condition.
  • Object
    • The objects available for selection are dependent on the objects in use in the policy.
  • Event
    • On Update
    • On Insert
    • On Delete (not available for the main object on any policy, only on related objects)
    • On Any
  • Create execution record?
    • Whether you would like to create an execution record for the trigger.
  • Send email on failure?
    • Whether you would like to send an email to the owner of the policy if the trigger fails.
  • Batch Size

    • This specifies the number of records to process in one call to the Decisions on Demand server.

    • The default is 50 which works well for most cases. If you experience issues with governor limits you can reduce this to 25 or 10. 

    • If you need to speed up your processing you can try higher values -- the maximum is 200.


For instance, to invoke a policy only on creation of a new Lead where the DecsOnD__Assignment_Status__c field is set to 'Ready', configure the triggers as follows:

Or to invoke a policy on creation of all Leads where the DecsOnD__Assignment_Status__c field is set to 'Ready' or an update of specific Leads where the DecsOnD__Assignment_Status__c field is set to 'Ready' and they are owned by a specific user create two triggers like the ones below:


Depending on the Objects in your policy you can create more complex triggers that work across multiple objects.