Data Sync Settings




 
 
NameMax Sync Waves

Key

pulsar.sync.maxWaves

Value

A Positive Number

Default Value (if any)

24
Compatibility
  • iOS
  • Windows
  • Android

Description

This is a numeric setting that dictates how many months into the past in terms of active records should the algorithm look back and fetch them.  

Notes/Comments(Fetch all records that were modified in the past two years).



 
 
NameActivity Max Sync Waves

Key

pulsar.sync.activityMaxWaves

Value

A Positive Number

Default Value (if any)

6
Compatibility
  • iOS
  • Windows
  • Android

Description

This is a numeric setting that dictates how many months into the past in terms of active Event, EventRelation, Task, and Note records should the algorithm look back and fetch them.  

Notes/Comments(Fetch all records that were modified in the past 6 months).




 
 
NameObject History In Months

Key

pulsar.sync.objectHistoryInMonths

Value

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

Default Value (if any)

24
Compatibility
  • iOS
  • Windows
  • Android

Description

This setting lets you control each individual object history in terms of months. 
Notes/CommentsThe value should be lower than the value specified for Max Sync Waves setting. 




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

Key

pulsar.sync.recordReachability.objects

Value

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

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android

Description

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.  
Notes/CommentsIf this setting is not specified or has an empty value, then all synced objects are eligible.




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

Key

pulsar.sync.recordReachability.intervalDays

Value

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. 

Default Value (if any)

0.0
Compatibility
  • iOS
  • Windows
  • Android

Description

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.
Notes/Comments




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

Key

pulsar.sync.recordReachability.frequency

Value

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. 

Default Value (if any)

0
Compatibility
  • iOS
  • Windows
  • Android

Description

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.
Notes/Comments





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

Key

pulsar.sync.recordReachability.runOnNextSync

Value

TRUE / FALSE

Default Value (if any)

FALSE
Compatibility
  • iOS
  • Windows
  • Android

Description

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.
Notes/Comments





 
Name Enable Reachability on Subsequent Passes

Key

pulsar.sync.recordReachability.enableOnOtherPasses

Value

TRUE / FALSE

Default Value (if any)

FALSE
Compatibility
  • iOS
  • Windows
  • Android

Description

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.
Notes/Comments

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.



 
 
NameObject Filter Limit

Key

pulsar.sync.initialFilterLimit

Value

ObjectAPIName:Number

Default Value (if any)

Default:50000

Object_API_Name:Number

Compatibility
  • iOS
  • Windows
  • Android

Description

This is a setting that dictates how many records Pulsar should fetch for each table (e.g: Lead, Account, Contact etc.). By default, the app caps at 50,000 records for each of the objects it syncs and the admins can increase the limits if they see fit.
Notes/Comments



 
 
NameAuto Sync Setting

Key

pulsar.sync.enableAutoSync

Value

TRUE / FALSE

Default Value (if any)

TRUE
Compatibility
  • iOS
  • Windows
  • Android

Description

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.
Notes/Comments




 
 
NameAllow/Deny Sync through 3G/4G

Key

pulsar.sync.enable3GAutoSync

Value

TRUE / FALSE

Default Value (if any)

TRUE
Compatibility
  • iOS
  • Windows
  • Android

Description

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.
Notes/Comments




 
 
NameForce a Layout Sync

Key

pulsar.sync.enableOneTimeSessionRefresh

Value

TRUE / FALSE

Default Value (if any)

FALSE
Compatibility
  • iOS
  • Windows
  • Android

Description

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. 
Notes/Comments




 
 
NameAuto Sync Time Interval

Key

pulsar.sync.autoSyncIntervalMinutes

Value

Number of minutes

Default Value (if any)

120
Compatibility
  • iOS
  • Windows
  • Android

Description

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.
Notes/Comments




 
 
NameSync Data Filter using a "Where" Clause

Key

pulsar.<sobject type>.syncFilter

Value

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

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android

Description

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.
Notes/Comments

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'



 
 
NameAllow Base 64 Download

Key

pulsar.sync.base64download.enabledObjects

Value

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

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android

Description

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

Notes/Comments



 
 
Name Allow Sync and display of Rich Text Field Images 

Key

pulsar.sync.images.richtextimagefields

Value

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

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android

Description

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. 
Notes/Comments

 
 
NameSync Objects - Last Modified Date Field Override

Key

pulsar.sync.objects.lastModifiedDateField

Value

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> 

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android

Description

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.
Notes/Comments

Account:My_Self_Managed_LastModifiedDate__c
Contact:My_Self_Managed_LastModifiedDate__c 



 
 
Name Pulsar Sync Object List

Key

pulsar.sync.objects

Value

A list of objects separated by commas or newlines

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android

Description

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.

Notes/Comments

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)


 
 
NamePulsar Sync Objects - Relationship Directives

Key

pulsar.sync.relationship.directives

Value

Look at the Notes section for a sample setting

Default Value (if any)

None
Compatibility
  • iOS
  • Windows
  • Android

Description

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>

By default the directive will use sync windows as this is the typical use case. Using sync windows means that when Pulsar queries for these records, results will be limited to only those records updated since your last sync. If you would not like to apply the sync window criteria, you may specify the text 'NoSyncWindow' as the 4th parameter. Pulsar uses sync windows to avoid repeatedly downloading records that have not changed on the server.

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.
Notes/Comments

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




NameSync In Progress Banner

Key

pulsar.sync.enableSyncInProgressBanner

Value

TRUE / FALSE

Default Value (if any)

TRUE
Compatibility
  • iOS
  • Windows
  • Android

Description

When enabled, a red banner appears over all screens when a sync is in progress advising the user not to leave the app until sync has completed.  
Notes/Comments

The banner is shown by default because sync can only run while the app is the foreground app.




 
 
Name Enable Field Service Sync Setting

Key

pulsar.sync.enableFieldService

Value

TRUE / FALSE

Default Value (if any)

FALSE
Compatibility
  • iOS
  • Windows
  • Android

Description

When enabled, Pulsar will sync all Service Report Templates (ServiceReportLayout) available to the user. These templates are available to the Pulsar Platform developer through the Pulsar javascript API.
Notes/Comments

 
 
Name

 Forced Work Offline Mode (with Sync Enabled) Setting

Key

pulsar.sync.enableForceOfflinePermanently

Value

TRUE / FALSE

Default Value (if any)

FALSE
Compatibility
  • iOS
  • Windows
  • Android

Description

When enabled, Pulsar will remain in "Forced Offline" mode, with the following exceptions:

  • manual and automatic sync will still be available.
  • Users will not have the option to control the offline/online status or the autosync status from within the app. These must be controlled via settings.
Notes/Comments
 
 
NameDisable syncing listviews for certain object types.

Key

pulsar.sync.listViews.disabledObjects

Value

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

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android

Description

This setting allows Pulsar to skip syncing the listviews for the specified object types. When an organization has a large number of listviews for a particular object type (e.g., 1000+), this can significantly slow down sync. Without this setting, all available listviews for object types in the sync objects setting are synced.

Notes/Comments
 
 
NameRemind users to sync periodically

Key

pulsar.sync.notification.remindMeInXMinutes

Value

Number of minutes

Default Value (if any)

1440
Compatibility
  • iOS
  • Windows
  • Android

Description

This setting allows Pulsar to use device notification feature to remind users to sync Pulsar to make sure their local data stays in sync with the server.

Notes/CommentsYou can specify 0 in the value field to turn off sync reminder notifications. 
 
 
Name

 Enable Content Document Direct Sync

Key

pulsar.sync.contentDocument.enableDirectSync

Value

TRUE / FALSE

Default Value (if any)

FALSE
Compatibility
  • iOS
  • Windows
  • Android

Description

If syncing the content document object, specifying TRUE for this setting will query/sync the ContentDocument (CD) object directly as part of the sync object list.  Otherwise, only CD records that are associated with a previously synced ContentDocumentLink object will be downloaded.

Notes/Comments
 
 
Name

 Enable Chronological Changes

Key

pulsar.sync.enableChronoChanges

Value

TRUE / FALSE

Default Value (if any)

FALSE
Compatibility
  • iOS
  • Windows
  • Android

Description

When disabled, all local changes are sent to the server in 'standard order' which is Pulsar's historic way of recording and transmitting changes. This means that when syncing, Pulsar will push all local deletes first, followed by all local creates, followed by all local updates. Note, that when multiple updates to a particular record are performed, the changes are all captured together into a single record and then sent to the server as a single update request.

When enabled, all offline creates, updates, and deletes are recorded and sent to the server chronologically (i.e., in the order they were input into Pulsar). When multiple updates to a particular record are performed, each update is captured and sent separately. 

Notes/CommentsThe benefit of enabling this setting is that Pulsar can mimic exactly how a user would have entered the data and properly handle certain business dependency/sequence logic that may exist on the server.  However, this may result in additional sync time when sending the local changes to the server as Pulsar potentially now has to send multiple updates instead of one update per record. 
 
 
Name

 Configure Conflict Resolve Policy (Global)

Key

pulsar.sync.conflictResolvePolicy

Value

USER_DECIDES / SERVER_WINS / CLIENT_WINS

Default Value (if any)

USER_DECIDES
Compatibility
  • iOS
  • Windows
  • Android

Description

A sync conflict occurs when the user makes a change to a field in a record while offline and that same record's field is updated to a different value on the server since the user's last successful sync.  When the user next performs a sync, they are notified that a sync conflict exists and is asked to choose between the local device's value or the server's value before completing sync.  Once the user selects the value, that is the value that will ultimately be set for both local and server values for this field.

By default, the user will be prompted for every record's field that is in conflict.  This setting can be specified to override this default behavior (USER_DECIDES) and automatically select either the local device's value (CLIENT_WINS) or the server's value (SERVER_WINS) for all fields in conflict.

Notes/CommentsIf your organization requires more fine-tuned control, please use the object/field specific version of this setting.  Please note that when both settings are used, this global setting applies as the default and is overridden by the specific object/field setting.
 
 
Name

 Configure Conflict Resolve Policy (Object/Field Specific)

Key

pulsar.sync.conflictResolvePolicy.<object type>

Value

A list where each line has a field name followed by a colon, followed by the conflict resolve policy string.  For example:

Field_1__c : CLIENT_WINS
Field_2__c : SERVER_WINS
Field_3__c : USER_DECIDES

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android

Description

Please see the global conflict resolve policy setting for a general description.

Available with version 13.0+

You may also specify the text 'Default' in place of a field name to indicate that all fields except those explicitly identified should adhere to the defined conflict resolve policy. 

For example, to specify an object level policy regardless of which fields are in conflict, define the setting value with the 'Default' as the only option:

Default : SERVER_WINS

This example shows that we want to always accept the client's changes when in conflict except for one specific field which should always accept the server's change:

Default : CLIENT_WINS
Field_1__c : SERVER_WINS

Notes/Comments
 
 
Name

 Configure Duplicates Policy

Key

pulsar.sync.create.allowDuplicates

pulsar.sync.update.allowDuplicates

Value

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

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android

Description

These will allow the duplicate to be created/saved even if alerts are enabled via duplicate rules on the Salesforce server, without displaying any alerts or interrupting sync on the Pulsar side. The setting is a blanket policy for each object in the list. If you have set up duplicate rules on Salesforce, and you have not set up this setting, Salesforce will return errors on save or sync when it encounters a duplicate via configured matching rules.

Notes/CommentsPlease Note: This setting will not merge any records. 
 
 
Name

 Enable Composite API

Key

pulsar.sync.enableCompositeAPI

Value

TRUE / FALSE

Default Value (if any)

FALSE
Compatibility
  • iOS
  • Windows
  • Android

Description

Please see Composite Graph API below for more details as they are very similar. This API has a significantly lower maximum operations per request than the graph API, but it is recommended if there are any implicit dependencies between objects in your org. This is because only this API can guarantee that the order of execution matches the order of the requests sent.  Typically, implicit dependencies are created via server side triggers.

Composite API differences from Composite Graph API:

  • Maximum of 25 operations per request
  • Guarantees sequential processing
Notes/Comments

If both Composite and Composite Graph API are enabled at the same time, Composite API takes precedence.

 
 
Name

 Enable Composite Graph API

Key

pulsar.sync.enableCompositeGraphAPI

Value

TRUE / FALSE

Default Value (if any)

FALSE
Compatibility
  • iOS
  • Windows
  • Android

Description

When enabled, Pulsar uses the Composite Graph API to send as many local changes as possible in one request to the server. When this setting is disabled, Pulsar sends creates, updates, and deletes one change at a time per request.  The benefits of composite graph include fewer API calls and faster times to send changes.  

However, not all changes are eligible for a graph request. Here are some of the known SFDC limitations per graph request:

  • A maximum of 500 operations per request
  • Some objects require headers that are not available with graph requests, so these must use the SOAP API and be sent separately
    • Case, Event, EventRelation, Task
  • The maximum number of different object types is 15
  • The maximum number of updates per record is 12

In addition to the previous limitations, there are also a few Pulsar limitations at this time due to the special handling required around certain objects. For example, Pulsar will mark the following as graph ineligible: 

  • File object types: ContentDocument, ContentVersion, ContentDocumentLink
  • Chatter object types: FeedItem, FeedComment
  • Any object create containing a base64 field
  • Any object create/update containing a pending base64 upload within a rich text field
  • If using Pulsar Setting, duplicateCreateCheckField, graphs will be constructed to avoid mixing object creates that supported duplicate checking with those that do not. The first object create encountered by a graph is what determines what that graph will allow. Subsequent graphs will then alternate as necessary.

When one of these limitations is found within your local changes, we send the graph request with the eligible changes found up to that point.  After that, we send that ineligible change separately. The process is then repeated until all your changes have been sent.

Notes/Comments

SFDC treats the changes in the graph itself as an all-or-none type of request.  This means that if one change fails, then the entire set of changes in that graph are rolled back.  Pulsar will subsequently prompt the user to correct the issue and, when corrected, a subsequent sync resends a newly calculated graph of changes.  This process repeats until all changes are successfully sent.

*Composite Graph guarantees order of execution in the group of pushed changes only for explicit dependencies. If there is no explicit dependency, then it's possible that SFDC might execute some those requests out of order to improve performance.  If your org has created implicit dependencies via triggers, please use the Composite API instead.

 
 
Name

 Maximum Updates Per Object

Key

pulsar.sync.maxUpdatesMap

Value

ObjectAPIName:Number

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android

Description

With this setting, organizations using relationship directives can specify a maximum number of updates per object during a catch-up sync. If an object is found to have exceeded this number, then the object is marked for re-sync. What this means is that the normal catch-up queries are not run and instead only relationship queries are run for this object type using the initial sync window criteria.  This can be beneficial to organizations that sometimes have an extraordinary amount of changes to a particular object that do not necessarily apply to the user's relationship directive hierarchy. Consider using this setting to improve sync performance if your organization is seeing catch-up syncs that are exceeding initial sync times.

Notes/CommentsThis setting is currently only intended to be used with relationship sync enabled orgs and applies only to objects with directives at depths greater than 0.  Also, with this setting specified, Pulsar issues a count() query on SFDC only for those specific objects to determine how many updates will be downloaded during the current sync run.


 
 
NameConnect Timeout Seconds

Key

pulsar.sync.connectTimeoutSeconds

Value

A positive number

Default Value (if any)

60
Compatibility
  • iOS
  • Windows
  • Android

Description

The time in seconds Pulsar will wait for connection acknowledgement from Salesforce servers.  This is not the total time to send back all query data, just the time it takes to connect/begin getting the data.

Generally, on 3G or better networks that are not overloaded you can expect an initial response to a Salesforce query in under 10 seconds.

Most organizations will not need to change this setting.

Notes/Comments

For organizations that do exceptionally complex queries, the Salesforce servers themselves may take a long (> 1 minute) timeframe to respond.

If you see the Pulsar data sync process repeatedly fail with timeout errors for multiple users across different networks (home/work/field), consider increasing this number.


 
 
Name Prevent Duplicate Creates 

Key

pulsar.sync.duplicateCreateCheckField

Value

The field api name you want to use to have Pulsar check before attempting to re-send a create that may have already succeeded. The field identified here should be a text field supporting at least 30 characters and be marked as an 'External Id' to have Salesforce automatically index this field.

Default Value (if any)


Compatibility
  • iOS
  • Windows
  • Android
Description

After Pulsar succeeds in sending an offline created record to the server, Pulsar typically gets a success response that includes the real Salesforce Id that is used to replace the temporary Id used throughout the local databases.  Occasionally, however, the success confirmation (along with the Id) is not sent.  This is typically due to a server timeout, but can also be caused by any interruption at this stage. When resuming a sync where that interruption happened, Pulsar does not know whether that last create was successful and assumes it was not to avoid loss of data. The consequence of this is that a duplicate may be created when sending the same data again.

To mitigate this, this setting automatically stores the temporary Id into the field specified by this setting (must also exist on the object) and sends the record create to Salesforce. If there is an interruption at this point, the subsequent sync will first query Salesforce for that temporary Id. If a record is found, Pulsar will not re-send the create and will continue as if the record was just successfully sent. 

Notes/Comments

To enable create duplicate checking and handling, you must:

  • Specify this setting with a valid field api name
  • Add the field identified by this setting to one or more objects that you want to guard against duplicates
    • We recommend that you create a text field containing 30 characters and mark as an external Id

Composite API Setting Usage

When using this feature with compositeAPI or compositeGraphAPI settings to push batches of changes, the batch groups will be automatically created such that supported and unsupported object creates are not mixed together.  An unsupported create refers to an object create that does not have a duplicate check field.  Pulsar does this in order to be able to resend a batch group containing unsupported creates if necessary or to check for duplicates for an entire batch group containing supported creates as a single unit.