Overview
Admins can use Pulsar Settings to implement Validation Rules and Triggers for the following execution points:
1. OnCreate
2. BeforeEdit
3. BeforeSave
4. OnSave
5. BeforeDelete
6. OnDelete
Validation Rules and Trigger execution points are composed of three "post-action" execution points, OnCreate, OnSave, and OnDelete, where the create, save, or delete action has occurred or is certain to occur, and three "pre-action" execution points, BeforeEdit, BeforeSave, and BeforeDelete, where conditions can be validated before the actions occur. The differences actually have to do with the actions taken within the setting. Validation Rules will contain Alert actions that inform the user of a failed condition. Triggers will often update the current record or other records with no user interaction. Validation Rules and Triggers can be combined in Pulsar, and all of the logic for a particular object type and execution point can be contained in a single setting.
Basic Usage
The Validation Rules and Triggers are defined using Pulsar Settings Language (PSL). The general format for such a setting is as follows:
Name: Object Name – execution point
Key: pulsar.<executionPoint>.<ObjectAPIName>
Value: Pulsar Settings Language
One exception to this format is the OnCreate setting, which can have one of the following formats:
Name: Object Name – execution point
Key: pulsar.onCreate.<Parent Object API Name>.<Child Object API Name>
Value: Pulsar Settings Language
Name: Object Name – execution point
Key: pulsar.onCreate.<Parent Object API Name>.<Child Object API Name>.PreInit
Value: Pulsar Settings Language
The first version (without PreInit) runs immediately after the object is created, but before the object is committed to the database (before other save triggers have a chance to run). The second version (PreInit), runs before the object is created, in case there are validation conditions or trigger actions that must be occur before the new child object can be created, perhaps to ensure certain values are passed to the create action.
Example Validation Rule
Name: Order - Before Edit
Key: pulsar.beforeEdit.Order__c
Value: See the code below. This setting executes when the user tries to edit a record, and uses a query to determine if the user attempted to update a record that is already in status "Finalized" or "Cleared".
DEFAULT{
Action=SetVar;
VarName=Order_Id;
VarValue=@@CurrentObjectId;
|
Action=SqlQuery;
QueryString=SELECT Id FROM Order__c WHERE Id = '%%Order_Id%%' AND Status__c IN ('Cleared','Finalized');
QueryReturnFields=@@QueryCount;
QueryTest=%%QueryCount%%=0;
QueryTestTrue=SUCCESS;
|
Action=Alert;
Message=Update is not allowed on Orders with status finalized, or cleared.;
}
SUCCESS
{
}
Example Trigger
The following example runs the code to update the total amount on the Order object. The logic here is pretty straightforward. Upon successful save of the Order line item, it updates the Sub_total__c filed in the parent Order object and the next time Pulsar syncs the data, the updated Order object is pushed to the server. Some of our customers use this feature to run the business logic while offline enabling the field rep to be productive. Pretty convenient!
Name: On Save – Order Line Item
Key: pulsar.onSave.Order_Line_Item__c
Value: See the code below. The following example runs the code to update the total amount (Sub_Total__c) on the Order object when a line item is updated. Note that this does not include any failure states (Alert actions).
DEFAULT{
Action=SetVar;
VarName=Order_Id;
VarValue=Order__c;
|
Action=SqlQuery;
QueryString=Select SUM ( CAST( Amount__c AS REAL ) ) AS SUM_ORDER_AMOUNT FROM Order_Line_Item__c WHERE Order__c = ‘%%Order_Id%%’;
QueryReturnFields=SUM_ORDER_AMOUNT;
|
Action=SqlQuery;
QueryString=Update Order__c SET Sub_Total__c = ‘%%SUM_ORDER_AMOUNT%%’ WHERE Id = ‘%%Order_Id%%’;
}