/
Pulsar Settings Language - Overview

Pulsar Settings Language - Overview

Definition

Pulsar Settings Language (PSL) is a domain-specific scripting language for creating custom behavior within the Pulsar environment. This provides Pulsar admins with functionality similar to that provided by validation rules, triggers, and formulas within the Salesforce environment. Your custom PSL is typed directly into the 'value' field for a Pulsar Setting that supports it.

PSL is supported for a subset of Pulsar Settings where a potentially complicated calculation, workflow, or validation is necessary. These are the settings where PSL is used.

  • Field default values

  • Field formulas

  • Object validations and triggers (beforeConvert, beforeEdit, beforeSave, beforeDelete, onSave, onCreate, onDelete)

    • Note about onCreate. It is most useful when you use it with preInit argument. This will give you a chance to pass values from the parent to the child. 

  • Custom buttons

At the core of PSL is an 'Action' that is executed by Pulsar.  There are several types of actions you may choose from, but any action first needs to be included within a 'block'.  

Blocks

A PSL setting is made up of one or more 'blocks', and your PSL must contain at least one block.  A block is a group of sequential actions to perform where each action is separated by the vertical bar (pipe) character, "|". A block may only contain Actions and not other blocks. Generally, each action within the block will be executed in order until the end of the block is reached.  

Block Syntax

Block names must be in all CAPS and must not contain any spaces.  The block name is then followed by the left curly brace "{", and after the actions are specified, is completed with the right curly brach "}".  Here is an example of the standard 'DEFAULT' block containing two actions.
DEFAULT{
<Action 1>;
|
<Action 2>;
} 

Standard Blocks

Standard blocks are used to define the entry point into your PSL. Although other standard blocks exist, we recommend that you use the 'DEFAULT' block as it can be used for both simple and complicated settings.   

Custom Blocks

You may define your own blocks of actions using any block name you would like.  However, please keep in mind that you will still need your 'DEFAULT' block in order to start your setting off. From your DEFAULT block, you can then branch to your custom blocks.

Actions

An action consists of a few statements, the most important of which is the 'Action' statement which defines what type of action to do.

Action Syntax

Each action is made up one or more lines each containing a 'key=value' pair terminated by a semicolon.  The first line should be the 'Action=' text followed by the Action Type (see below for a list of action types):  
Action=<ActionType>;

Subsequent 'key=value' pairs on this action are documented on the Action itself. Below is a reference to the most popular language actions:

Action=<Execute Another Block>

To specify that the flow should go to another block, specify the block name using a prefix of two underscores "__".  Typically, you would have this action as the last action in the block as it will stop executing any remaining actions in the current block. There are no additional keys for this action type.

Example (Execute a block named 'BLOCK_2'):

Action=__BLOCK_2;

Action=Alert

To display an alert to the user. This is useful for communicating validation messages to the user and for debugging the setting itself (by printing out variables). 

Additional Parameters:
Message  = <Required; A text message; You may include newlines, white space, and variables>;

AlertType = <Not Required> 

Values supported:

DismissAlert - The default single-button OK alert.  (Same as not specifying an AlertType parameter).  NOTE: this will by default invalidate the PSL trigger, which you can change via additional action param:

  • AlertShouldValidate = TRUE or (default FALSE). Use this to change the validation behavior.

DismissCurrentWindow - Use this wisely because you would not want to dismiss an edit window but perhaps upon successful execution of a setting, e.g.: onBarcodeScan setting. (Upon successfully executing the setting, you would want to dismiss the underlying camera screen at that point, saving the user an extra click). Additional action param:

  • AlertShouldValidate = FALSE or (default TRUE). Use this to change the validation behavior.

BranchChoice - This alert will present the user with two choices (as buttons). For each choice you should specify both the title and the name of the action block taken. This type of alert should be the last action in a block since no matter which choice is selected, it will not continue executing actions on the current block. Refer to example 2 below.
Here are the additional action parameters expected for this alert type:

  • YesButtonTitle = a string that is displayed on the one of the alert buttons.  Note, the string does not need to be associated with a 'Yes' to a question posed by the alert; it only needs to correspond with the 'YesButtonAction' below.

  • NoButtonTitle = a string that is displayed on the one of the alert buttons.  Note, the string does not need to be associated with a 'No' to a question posed by the alert; it only needs to correspond with the 'NoButtonAction' below.

  • YesButtonAction = the name of the block in your setting that should be executed if the user selected the corresponding choice indicated by the YesButtonTitle parameter.

  • NoButtonAction = the name of the block in your setting that should be executed if the user selected the corresponding choice indicated by the NoButtonTitle parameter.

ChoiceAlert - This will present the user two choices (as Yes/No buttons). For each choice you should specify the title of the buttons if they will be different than 'Yes'/'No'.  If the user selects the Yes button, actions will continue to execute on the block, otherwise, execution on the current block will stop.  Refer to example 3 below.  This example block would be executing inside a 'beforeSave' setting.  Here we prompt the user to confirm they want to save the record. Clicking on the Yes button will save the record. Clicking on the No button will continue to display the edit window giving the user a chance to change the values. 
Addition parameters you could use if you are using the ChoiceAlert: 

  • YesButtonTitle = a string relevant to your environment to replace the default string 'Yes' on the choice alert.

  • NoButtonTitle = a string relevant to your environment to replace the default string 'No' on the choice alert.

Example:

DEFAULT{ Action=Alert; Message=This is how the Alert works. Pretty neat! Huh?; }

Example 2:

DEFAULT { Action=Alert; Message=What is 2+2?; AlertType=BranchChoice; YesButtonTitle=4; NoButtonTitle=6; YesButtonAction=CORRECT; NoButtonAction=INCORRECT; } CORRECT { Action=Alert; Message=Well done! 2+2 does = 4; } BLOCK_TWO { Action=Alert; Message=Erm.... You might want to try again; }

Example 3:

Action=Alert; Message=Minimum order amount should be greater than $50. Are you sure you want to save the order?; AlertType=ChoiceAlert; YesButtonTitle=Yes, Save; NoButtonTitle=No, Let me Edit;

Action=CloneCurrentObject

To show an object in create mode pre-populated with values from the current object. Please note that this action is not intended to be used on an object that's currently in edit or create mode. A good location for this action would be a custom button.

Additional Keys:
ExcludeFields = <Optional; A comma separated list of field API names to not copy to new object>;

Example:

Action=CloneCurrentObject; ExcludeFields=Description,Completed_Date__c;