Data Sync Settings

Max Sync Waves

pulsar.sync.maxWaves

A Positive Number

24

A sync wave is generally equivalent to one month of history, and with this numeric setting you may specify how many months into the past (in terms of active records) that the algorithm should look back and fetch them. Pulsar determines active records by using the LastModifiedDate, SystemModStamp, or another datetime field (if overridden with the pulsar.sync.objects.lastModifiedDateField Pulsar Setting).

To guarantee that a user should initially sync a specific number of months of historical data, you will need to add one or two to your number depending on how you’ve configured the final wave. For example, for a minimum of two years worth of data, you can specify 26 (with the full history wave enabled) or 25 (with the full history wave disabled).

Enable Full History Wave

pulsar.sync.enableFullHistoryWave

TRUE / FALSE

TRUE

See pulsar.sync.maxWaves above for general wave information. By default, the final wave performed for an object will attempt to sync not just one month’s worth of data but all data since January 1, 1980 sorted by LastModifiedDate in descending order. This is done to optimistically download as much data as possible for the user. Since this date range is large, all or part of the request may not succeed. If it does not succeed, Pulsar does not consider this an error and continues to integrate the records it was able to retrieve.

Specifying ‘FALSE’ for this setting, will make that final wave behave similarly to the other waves and only retrieve a month’s worth of data. In this configuration, the final wave is expected to succeed or Pulsar will report a sync error.

Object History In Months

pulsar.sync.objectHistoryInMonths

List of the pairs in the format Object API Name:Number of months (e.g:  Lead:12, Account:24, Contact:24)

24

This setting lets you control each individual object history in terms of months. 

The value should be lower than the value specified for Max Sync Waves setting. 

Objects that are subject to a stale record cleanup (due to changes in record accessibility/permissions)

pulsar.sync.recordReachability.objects

A list of object api names separated by new line, or comma. 

This setting allows you to specify which objects are eligible to scan and remove stale records from. Stale records are identified as existing records that exist on the client device but do not have a corresponding server record.  

If this setting is not specified or has an empty value, then all synced objects are eligible.

Frequency of stale record cleanup (due to changes in record accessibility/permissions)

pulsar.sync.recordReachability.intervalDays

A number greater than zero indicates that the cleanup stage should run after that many days since the last time it successfully ran. Note, to disable set to 0 or a negative number. 

0.0

This setting allows you to set the interval (as a number of days) when to perform a cleanup of potentially stale records on your device. The interval refers to the number of days since the last successful run of this cleanup stage.  This setting accepts fractional days (e.g. to specify 36 hours, you would enter 1.5). There is another frequency setting below, however, if both are specified this one takes precedence.  Note, stale records can occur in a local database if record permissions are altered after a user has performed a sync such that a user no longer has read access to a record.

Frequency of stale record cleanup (due to changes in record accessibility/permissions)

pulsar.sync.recordReachability.frequency

A number greater than zero indicates that the cleanup stage should run after that many successful syncs.  Note, to disable set to 0 or a negative number. 

0

This setting allows you to set the interval when to perform a cleanup of potentially stale records on your device. The interval refers to the number of successful syncs performed. For example, if you set it to 10, this will run every 10 successful syncs. Note, stale records can occur in a local database if record permissions are altered after a user has performed a sync such that a user no longer has read access to a record.

Force the stale record cleanup stage to run on the user's next sync

pulsar.sync.recordReachability.runOnNextSync

TRUE / FALSE

FALSE

For a description of the stale record cleanup stage, see the above setting for "pulsar.sync.recordReachability.intervalDays". If this setting is set to TRUE, all users will run this cleanup stage during their next sync (only once). The cleanup stage will not trigger again for this user unless you've specified this stage to run periodically via one of the other 'recordReachability' settings. In order to reactivate this setting for a subsequent use, make sure the value is still set to TRUE, and re-save the record to update its last modified date.

Enable Reachability on Subsequent Passes

pulsar.sync.recordReachability.enableOnOtherPasses

TRUE / FALSE

FALSE

Specifying this setting as TRUE will enable reachability to run on the second pass (in addition to the first pass) only if local changes were pushed during the first pass.

Initiating a sync means that Pulsar will have at least one pass through all the sync stages. However, another pass will be performed if, during the first pass, updates were either downloaded or local changes pushed to SFDC. Since the reachability stage can be a time consuming stage, it will normally only run during the first pass.

Also, the reachability stage runs before the stage where Pulsar pushes local changes to SFDC. Therefore, if those changes might render some records unreachable, they will remain on the local device until the next time reachability runs.

Object Filter Limit

pulsar.sync.initialFilterLimit

ObjectAPIName:Number

Default:50000

Object_API_Name:Number

This setting determines the number of records Pulsar fetches for each table (e.g., Lead, Account, Contact, etc.). By default, the application limits the sync to 50,000 records per object. However, administrators can increase this limit as needed.

Auto Sync Setting

pulsar.sync.enableAutoSync

TRUE / FALSE

TRUE

This particular setting dictates how the app would run the sync process. If the value is set to true, the app will automatically perform a bi-directional sync without requiring the user to initiate the sync. If this is set to be false, the user will have to manually choose to Sync in order reflect the changes on the device and the server appropriately. The manual sync can be initiated by tapping on the blue ‘Sync Now’ button on the Settings page as well as by clicking on the circle that appears on the bottom toolbar, which then will display a popup window with the blue ‘Sync Now’ button.

Allow/Deny Sync through 3G/4G

pulsar.sync.enable3GAutoSync

TRUE / FALSE

TRUE

This option would permit or not permit auto sync to run when the device is connected to the data network. Some companies might want to restrict the data usage and in those cases, the admins can use this setting to control the sync behavior.

Force a Layout Sync

pulsar.sync.enableOneTimeSessionRefresh

TRUE / FALSE

FALSE

In order to save API calls, the catch-up sync does not sync the layout changes every time. Layout sync only runs if the user clicked the 'Refresh Settings' button from the Settings page. Or, if you would like to force a layout sync, enable this setting after making layout changes to the org.  When Pulsar next performs a sync on users devices, this will including syncing the layout changes. This forced metadata sync only happens once for each user after this setting is created/updated. 

Auto Sync Time Interval

pulsar.sync.autoSyncIntervalMinutes

Number of minutes

120

Some customers asked us to allow a sync interval time as opposed to running the sync every time the app comes to foreground. For example with the below setting, the sync algorithm will check to see if there was a successful sync in the last X minutes and if there was one, it will not initiate the sync process. If X minutes indeed have passed since the last successful sync, it will initiate sync.

Sync Data Filter using a "Where" Clause

pulsar.<sobject type>.syncFilter

A SOQL format where clause (without the 'Where' keyword).

This is a per-object sync filter to further control which records get synced. Note, it is technically possible to create/edit a record that would not get subsequently picked up due to the object's sync filter.  We would pick up the server delete, but not any server update.

Since the UserInfo SOQL syntax for obtaining the current user's id is not available outside of APEX, you can instead use this Pulsar defined constant:  @@CurrentUserId

Example: 

K: pulsar.Account.syncFilter

V: Account.Name = 'Apple'

Allow Base 64 Download

pulsar.sync.base64download.enabledObjects

Comma or New Line separate list of object API names  (e.g: Attachment, StaticResource)

Pulsar by default doesn't fetch the Body field (the actual data that constitutes the file) of Attachment, StaticResource, and other similar objects during the sync process. This setting enables that explicitly. Customers using this should know that there could be quite a lot of data and advise users to use a WIFI connections for the initial sync.

NOTE that without this setting specified, Pulsar will still download the data on an individual basis when attempting to view attachments (while online).

Allow Sync and display of Rich Text Field Images 

pulsar.sync.images.richtextimagefields

Comma or New Line separate list of objectAPI:FieldAPI Names  (e.g: Lead:UploadImageTest__c)

Pulsar by default doesn't display images supported by the Rich Text Field data type. This is a feature that could come in handy when you are implementing a field survey or maintenance log. User can upload an image right into the field that is displayed as part of the record. 

Sync Objects - Last Modified Date Field Override

pulsar.sync.objects.lastModifiedDateField

A list of objects separated by newlines where each line has the object api name and the name of the DateTime field to use instead of LastModifiedDate in this format:  <object API name>:<field API name> 

By default, the LastModifiedDate field is selected as the DateTime field that is used to determine when a record has been modified.  This is a built-in Salesforce field that is updated automatically for your organization, and is used by Pulsar to download new and updated records.  Although not recommended, you may override this field per object with your custom DateTime field if necessary.  One possible reason you may want to do this is because your organization runs batch jobs that frequently update many records and result in the LastModifiedDate field getting updated.  In this scenario, you may decide that you don't want all the records updated in this fashion to be considered 'modified' and consequently re-downloaded by Pulsar in the next sync.  Perhaps you only want to refresh only those records where a subset of fields are updated.  One way you might do this is by creating a workflow rule that updates a custom DateTime field when specific fields are updated.  If you implement this setting, please keep in mind that you are responsible for maintaining when and how your custom DateTime field gets updated.

Account:My_Self_Managed_LastModifiedDate__c
Contact:My_Self_Managed_LastModifiedDate__c 

Pulsar Sync Object List

pulsar.sync.objects

A list of objects separated by commas or newlines

Add the names of the objects you want to sync to this list and then copy/paste that into the PulsarSettings Page.

Important Note: If a relationship directive setting is also found, this setting will be ignored as the other one takes precedence.

The list of objects to sync can be separated by comma, semicolon or newline. Also note that, you need to include the standard objects along with the additional objects. In other words, this is the absolute master list Pulsar honors and syncs the objects you specified here

Account
Case
Contact
CurrencyType
Event
Lead
Opportunity
OpportunityContactRole
OpportunityCompetitor
OpportunityStage
RecordType
Task
TaskStatus
User

[Add list of additional objects like Product and Custom objects at the end of the above list] 

for eg: 

TestCustomObject__c (add the api name of the object)

Pulsar Sync Objects - Relationship Directives

pulsar.sync.relationship.directives

Look at the Notes section for a sample setting

None

Specify this setting to indicate that you would like Pulsar to sync your data using object relationships. You define relationship 'directives' where each directive tells Pulsar what object to sync and how to sync it. Each directive is defined as having a depth number starting at 0 and increments by 1. This depth represents both the order that the directive will be synced (0 is first) but also the dependency involved. For example directives defined at depth 2 depend on the objects synced at depth 1 which in turn depend on the objects synced at depth 0. Depth 0 has no dependencies. Additionally, directives at depths greater than 0 are required to define the dependency from the prior depth (object and field name). 

There are two forms for specifying directives (see below) for depth 0 objects and for other depths.

Delimiters used in parsing this setting:

1st level delimiter | (pipe) separates distinct query directives
2nd level delimiter ; (semicolon) separates a directives components
3rd level delimiter : (colon) separates components into subcomponents

Format for starting directives (depth 0):

0 ; <object type that we're syncing> ; <optional SOQL where clause> ; <optional sync window usage>

Format for all other directives (defines the dependency at the previous depth):

<depth greater than 0 > ; <target object type that we're syncing> : <optional target field name (default Id)> ; <source object type from previous depth> : <optional source field name (default Id)> ; <optional target SOQL where clause>

Limits and caveats:

• This setting takes precedence over the pulsar.sync.objects setting if both are specified.

• You may specify up to 32 depths of directives, however, we've rarely seen more than a few depths needed at most.

• Currently, any time this setting changes (regardless of the significance of the change), Pulsar will perform a longer sync similar to an initial sync to make sure any data on the user's device is valid under the new relationship hierarchy defined by this setting.

• By default, the application limits synchronization to 50,000 records per object, or to the value specified in the pulsar.sync.initialFilterLimit setting. Beginning with Release 16.0.0, this limit is strictly enforced during relationship syncs.

Content File Directives:

• To sync content file objects (Content Version, Content Document, Content Document Link), we recommend you follow the best practices in our Enable Salesforce Files page.

• While you can explicitly specify Content object directives, we don't recommend it at this time, with the exception of including them at depth 0.

0 ; ServiceAppointment ;
Id IN (Select ServiceAppointmentId from AssignedResource WHERE ServiceResource.RelatedRecordId = '@@CurrentUser.Id') AND
SchedStartTime <= NEXT_N_DAYS:45 AND
SchedEndTime >= LAST_N_DAYS:45 AND
Status NOT IN ('New', 'Scheduled','Canceled') ; NoSyncWindow
|
0 ; Account ; Primary_Address_Country__c='@@CurrentUser.Country'
|
0 ; Lead ; Lead.OwnerId = '@@CurrentUserId'
|
0 ; Case ; OwnerId='@@CurrentUserId'
|
0 ; AppExtension
|
0 ; FieldServiceMobileSettings
|
0 ; MobileSettingsAssignment
|
0 ; Organization
|
0 ; Product2 ; CID__c != '' and CID__c != null
|
0 ; WorkOrderStatus|0 ; WorkOrderLineItemStatus|0 ; ServiceResource ; RelatedRecordId = '@@CurrentUser.Id'|1 ; AssignedResource:ServiceAppointmentId ; ServiceAppointment |1 ; WorkOrder ; ServiceAppointment:ParentRecordId|1 ; WorkOrderLineItem ; ServiceAppointment:ParentRecordId |1 ; Account ; ServiceAppointment:ParentRecordId|1 ; Account ; ServiceAppointment:AccountId|1 ; ServiceTerritoryMember:ServiceResourceId ; ServiceResource|2 ; Asset ; WorkOrder:AssetId|2 ; Asset ; WorkOrderLineItem:AssetId|2 ; ServiceResource ; AssignedResource:ServiceResourceId |2 ; Location ; WorkOrder:LocationId|2 ; Location ; WorkOrderLineItem:LocationId|2 ; WorkOrderLineItem:WorkOrderId ; WorkOrder|2 ; Account ; WorkOrder:AccountId |2 ; ServiceTerritory ; ServiceTerritoryMember:ServiceTerritoryId|3 ; Location:RootLocationId ; Location:RootLocationId|3 ; Product2 ; Asset:Product2Id|3 ; ServiceTerritoryLocation:ServiceTerritoryId ; ServiceTerritory|4 ; Location ; ServiceTerritoryLocation:LocationId|5 ; ProductItem:LocationId ; Location