Sync Triggers

Sync Triggers

Pulsar supports running custom Pulsar Settings Language (PSL) before and after the start of the sync process.

Sync triggers can be useful for:

  • recording the start of sync

  • recording the end of sync

  • recording the sync duration

  • counting records synced

  • alerting the user to information before or after the sync

These triggers are tied to when the sync process runs, and any data that is configured to be collected during this setting execution will be pushed to the Salesforce server.  Note: This sync stat data will be pushed even if the user is forced offline permanently via settings.

For both triggers (before and after), the process is the same. Use the appropriate key and enter your trigger logic (a PSL script) as the value. Refer to the following sections for the keys and value examples:

For more information about writing trigger logic, refer to the following articles:

Tips for Smooth Execution

Sync All Objects Used in the Trigger

Any object your trigger depends on must be available on the device. This applies whether the trigger references the object directly or through a relationship. This is especially true if you use SFCreate or SFUpdate to write to an object, because Pulsar must have that object’s schema. Making these objects available ensures Pulsar can evaluate the conditions offline and produce consistent results. To ensure your sync trigger runs as expected, add every object referenced in your trigger logic to the list of synced objects. See Pulsar Sync Object List or Pulsar Sync Object List – Relationship Directives for more information about synced object lists.

Reducing the number of records downloaded

Even if users do not need access to the records in that object, Pulsar still needs the schema to create or update records. You can prevent the records themselves from downloading by applying a sync filter like: Id = null. This keeps all record data off the device while still allowing Pulsar to write to the object. Read more about Sync Data Filters for more information.

Alternatively, when a trigger only needs a small portion of information in an object, you do not need to sync all the data in an entire object. Instead, you can create a custom object that contains only the fields and records needed for the trigger logic. Populate this custom object with a minimal dataset and point the trigger to it. Syncing this custom object gives Pulsar everything it needs to run the trigger, without downloading large volumes of unrelated records.

You can further reduce the number of records downloaded in the objects referenced by your trigger by using the Max Sync Waves setting to reduce the record history that is downloaded to the device. If you set it at 1, a minimal amount of history will be downloaded. Read more about the Max Sync Waves setting for more information. Other options include setting Enable Full History Wave setting to False, to further limit the amount of data downloaded.

Why These Options Matter

Adding required objects, using custom objects for lightweight evaluation, and filtering out record data help promote seamless trigger execution while controlling sync duration. Admins can retain full control over trigger logic and write operations while reducing unnecessary downloads. This keeps sync time down, provides users with the necessary information, and lets teams focus on their workflows with fewer interruptions.