Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Salesforce Validation Rules

Pulsar directly supports evaluating Salesforce validation rules both online and offline.

  • Supports most Salesforce formulas (see more information about formula fields)
  • Follow the pre-processing steps on the Pulsar Settings Manager tab (NOTE: this is currently a limitation of the Salesforce platform, as we cannot directly sync validation rule metadata, but first have to pre-process it).
  • Set pulsar.validation.enableSFDCValidationRules Pulsar Setting to TRUE to enable this functionality in the Pulsar mobile app
  • NOTE: If a PSL BeforeSave setting exists on an object, it will be run BEFORE saving the object and BEFORE processing any Salesforce ValidationRules for that record.


...

PSL Validation Rules and Triggers

Pulsar originally did not support running Salesforce validation rules, and instead offered similar functionality through logic implemented in Pulsar Settings Language (PSL).  Because PSL leverages the power of raw SQL, you can create complex validation logic that exceeds what Salesforce formula validation rules can perform.  Despite (or frankly because of) the power of PSL validation rules and triggers, we recommend that you use Salesforce validation rules if possible before bringing PSL to bear on a thorny problem.

...

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 four "pre-action" execution points, BeforeConvert, BeforeEdit, BeforeSave, and BeforeDelete, where conditions can be validated before the actions occur. The differences between Validation Rules and Triggers 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. 

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

or

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 trigger actions that must 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". If so, it alerts the user with the appropriate message.

Code Block
DEFAULT{ 
Action=SetVar; 
VarName=Order_Id; 
VarValue=Id; 
| 
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

Name: On Save – Order Line Item

...

Code Block
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%%’;
}


Field Triggers

Currently we only support the 'After Update' trigger type for reference fields.  The trigger code can be any valid PSL and is executed only after a specified reference field has been updated.

After Update Field Trigger Setting (without record type)

Name:  Field AfterUpdate Trigger (<object name> : <field name>)
Key:     pulsar.<Object API Name>.<Field API Name>.afterUpdate
Value:  Pulsar Settings Language

After Update Field Trigger Setting (with record type)

Name:  Field AfterUpdate Trigger (<object name> : <record type> : <field name>)
Key:     pulsar.<Object API Name>.<Record Type Developer Name>.<Field API Name>.afterUpdate
Value:  Pulsar Settings Language

Example After Update Field Trigger

Name: Field AfterUpdate Trigger (Opportunity : AccountId)
Key: pulsar.Opportunity.AccountId.afterUpdate
Value:   See the code below. The following example runs the code to update the NextStep field to 'Create Quote' every time the Account lookup field on the Opportunity object is updated.

Code Block
DEFAULT{
Action=SetFieldInMemory;
FieldType=General;
FieldName=NextStep;
FieldValue=Create Quote;
}


Sync Triggers

Pulsar currently supports running custom Pulsar Settings Language upon completion of a successful sync. This can be useful for recording the sync time, counting records, or alerting the user to new information.

...

Name:  After Sync Trigger 
Key:     pulsar.sync.AfterSyncTrigger
ValuePulsar Settings Language

Code Block
DEFAULT{
Action=SetVar;
VarName=LastSync;
VarValue=@@LastSyncTime;
|
Action=Alert;
Message=Last successful sync time: %%LastSync%%;
}

...