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 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 have to use the processing steps).
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.

Admins can use Pulsar Settings to implement validation rules and triggers for the following execution points:

BeforeView (available in 14.0+)
BeforeEdit
BeforeSave
BeforeDelete
OnCreate
OnSave
OnDelete
onBarcodeScan
AfterSave (similar to OnSave, but is only run when the online save has been successfully pushed to Salesforce)
AfterLogin

Validation Rules and Trigger execution points are composed of four "post-action" execution points, OnCreate, OnSave, AfterSave, and OnDelete, where the create, save, or delete action has occurred or is certain to occur, and four "pre-action" execution points, BeforeView, 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.

A Note about Save Triggers

To avoid issues with saving your data, we recommend using the SyncNow action only with the AfterSave trigger and not with the BeforeSave or OnSave triggers. In fact, the primary use case for the AfterSave trigger is to be able to run a SyncNow action.

The difference between OnSave and AfterSave is that OnSave executes after a successful local write and always executes. The AfterSave trigger only executes after Pulsar sends the record create/update via an online write and has received a success response from Salesforce.

Usage

Pulsar Setting Format

The Validation Rules and Triggers are defined using Pulsar Settings Language (PSL). The general format for such a setting is as follows:

Name: <Object Type> – <execution point>
Key: pulsar.<executionPoint>.<ObjectAPIName>
Value: Pulsar Settings Language

Note, besides this single object format, the AfterLogin and OnCreate settings have alternative formats. See sections below for more information.

AfterLogin Trigger

The AfterLogin trigger executes upon navigating to the home screen after signing in or tapping the username to start your session.

Setting Format:

Name: After Login Trigger
Key: pulsar.afterLogin
Value: Pulsar Settings Language

Here is an example setting that displays an alert after the user signs in indicating whether the last sync performed was successful or not.

DEFAULT{
Action=SetVar;
VarName=X;
VarValue=@@LastSyncSuccess;
|
Action=SqlQuery;
QueryString=select case when '%%X%%' = 'TRUE' then 1 else 0 end as Success;
QueryReturnFields=Success;
QueryTest=%%Success%%==1;
QueryTestTrue=Success;
|
Action=Alert;
Message=Your last sync failed, please try to sync again. If this continues, please contact your administrator;
}

Success{
Action=Alert;
Message=Last sync was successful!;
}

OnCreate Triggers

The OnCreate trigger executes whenever the plus button is tapped. There are two separate execution points that override the plus button on the listviews or on a specific child related list (see below for these two formats). When this setting is specified, the standard behavior to show the object in create mode is overridden with custom PSL code. This means that the PSL must ultimately handle how to respond to the plus button tap. For example, if the standard behavior is needed, the 'CreateAndMapFields' PSL action should be called as the last action in the custom PSL.

Single object setting (to override plus button action on the object’s listviews)

Setting Format :

Name: <Object Type> – <execution point>
Key: pulsar.onCreate.<Object API Name>
Value: Pulsar Settings Language

The PSL context for the single object format is the newly initialized object itself (in memory only). Please note that specifying this setting does not imply a default for any of the object’s related lists. To override the standard plus button action there, the parent/child settings must also be explicitly specified.

Parent/Child object setting (to override plus button action for a child related list)

Setting Format:

Name: <Parent>/<Child> – <execution point>
Key: pulsar.onCreate.<Parent Object API Name>.<Child Object API Name>
Value: Pulsar Settings Language

The PSL context for the parent/child format is the parent of the object to create.

Validation Rule Examples

beforeEdit

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.

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 
{ 
}

beforeView (available in Pulsar 14.0+)

Name: Service Appointment - Before View
Key: pulsar.beforeView.<Object API Name> (e.g. pulsar.beforeView.ServiceAppointment)
Value: This setting executes when a user tries to view a record. PSL can be used to implement business rule validations to determine if the current user can or cannot view an object.

DEFAULT{ 
Action=SetResult;
Result=Service Appointment viewing access denied.;
ResultValid=false;
}

Example of pulsar.beforeView.ServiceAppointment in an FSL org

Example Triggers

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. This update is committed to the database when this setting executes, and this change will be pushed to the server upon the next sync. Note that this Trigger setting does not include any failure states (Alert actions).

Name: After Save - Service Report

Key: pulsar.afterSave.servicereport
Value: See the code below. The following example executes a single object sync in order to refresh the object and it’s related objects from Salesforce.

Special File Meta Object Usage for beforeSave and onSave

There is a special "FILE" meta object concept available as of Pulsar 9.0. It encapsulates and makes available data on all 3 content objects (ContentDocument, ContentVersion, and ContentDocumentLink), within a single PSL beforeSave Validation Rule or PSL onSave Trigger, when saving files or attachments on other objects. For example, you could define a pulsar.beforeSave.File validation rule to restrict file types being added to Account Related Files.

The Full list of data available in pulsar.beforeSave.File or pulsar.onSave.File PSL follows:

ContentDocument	ContentVersion	ContentDocumentLink

ContentDocument	ContentVersion	ContentDocumentLink
ContentDocument_Id	ContentVersion_Id	ContentDocumentLink_ContentDocumentId	or	ContentDocumentId
ContentDocument_FileExtension	ContentVersion_ContentDocumentId	ContentDocumentLink_LinkedEntityId	or	LinkedEntityId
ContentDocument_FileMimeType	ContentVersion_FileExtension	ContentDocumentLink_SystemModstamp	or	SystemModstamp
ContentDocument_ContentSize	ContentVersion_FileMimeType	ContentDocumentLink_ShareType	or	ShareType
ContentDocument_ContentSizeMB	ContentVersion_ContentSize	ContentDocumentLink_Visibility	or	Visibility
ContentDocument_Base64ContentSize	ContentVersion_ContentSizeMB
ContentDocument_Base64ContentSizeMB	ContentVersion_Base64ContentSize
ContentDocument_Title	ContentVersion_Base64ContentSizeMB
ContentDocument_Description	ContentVersion_Title
	ContentVersion_Description
	ContentVersion_Origin
	ContentVersion_PathOnClient

Example of data available in PSL:

Datum	Example Value	Notes

Datum	Example Value	Notes
ContentDocument_Id	0695e000007oQsJAAU	will be empty in beforeSave
ContentDocument_FileExtension	mp4
ContentDocument_FileMimeType	video/mp4
ContentDocument_ContentSize	12207543
ContentDocument_ContentSizeMB	11.64
ContentDocument_Base64ContentSize	16236032
ContentDocument_Base64ContentSizeMB	15.48
ContentDocument_Title	example.mp4
ContentDocument_Description	Example MP4 Video
ContentVersion_Id	0685e000007xDBQAA2	will be empty in beforeSave
ContentVersion_ContentDocumentId	0695e000007oQsJAAU	will be empty in beforeSave
ContentVersion_FileExtension	mp4
ContentVersion_FileMimeType	video/mp4
ContentVersion_ContentSize	12207543
ContentVersion_ContentSizeMB	11.64
ContentVersion_Base64ContentSize	16236032
ContentVersion_Base64ContentSizeMB	15.48
ContentVersion_Title	example.mp4
ContentVersion_Description	Example MP4 Video
ContentVersion_Origin	C
ContentVersion_PathOnClient	example.mp4
ContentDocumentLink_ContentDocumentId	0695e000007oQsJAAU	will be empty in beforeSave
ContentDocumentLink_LinkedEntityId	0016A00000oCv1dQAC
ContentDocumentLink_SystemModstamp	2022-05-18T16:27:20.149+0000
ContentDocumentLink_ShareType	V
ContentDocumentLink_Visibility	AllUsers

Example pulsar.beforeSave.File

The pulsar.beforeSave.File validation rule can be used with custom logic to prevent an end user from saving files. The example below restricts by file extension as well as size of the file.

Example pulsar.onSave.File

The pulsar.onSave.File trigger can be used to perform custom logic after a file has been saved. The below example outputs some basic information to the log upon saving an Attachment or File on an object such as an Account or Contact object.

Field Triggers

Currently we only support the 'After Update' trigger type for reference fields only. 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.