Versions Compared

Key

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

...

Admins can use Pulsar Settings to implement Validation Rules and Triggers for the following execution points:

1. OnCreate BeforeConvert (currently only valid for lead conversion)

2. BeforeEdit

3. BeforeSave

4. OnSaveBeforeDelete

5. BeforeDelete OnCreate

6. OnSave

7. OnDelete

78. onBarcodeScan  onBarcodeScan (future release) 

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 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. 

...

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.

...