About SFDC-to-Max Sync Configuration
Selected Salesforce objects are migrated to Max during the initial sync phase of the implementation process. The Initial Sync Action object stores sync configuration settings used to migrate data from Salesforce to Service Board. Each record captures one step or one set of records for a source-target object pair to synchronize. Each record includes the relative URL and SOQL query parameters used to retrieve records from Salesforce. The full set of active Initial Sync Action records represent the overall initial sync process.
For both initial and real-time sync, the Transform Template object captures field mappings and transformations between Service Board and Max objects and Salesforce objects. Each template includes Salesforce-to-Max field mappings, and both predefined and custom fields are supported.
During real-time sync, the Salesforce objects that were migrated to Max during initial sync are updated to reflect any changes made in Salesforce. Objects that are unique to Max are included in real-time sync to Salesforce as read-only, and some objects can be created and edited on both platforms.
|
Max Object
|
Data Updates and Sync
|
Initial Salesforce-to-Max Sync
|
Salesforce-to-Max Real-Time Sync
|
Max-to-Salesforce Real-Time Sync
|
|---|---|---|---|---|
|
Access Hours
|
Editable on Max and Salesforce.
|
Y
|
N
|
N
|
|
Account
|
Read-only on Max.
|
Y
|
Y
|
N
|
|
Appointment
|
Editable on Max and Salesforce.
|
Y
|
Y
|
Y
|
|
Credential
|
Partial mapping to Salesforce Skill object.
|
Y
|
Y
|
N
|
|
Credential Category
|
No sync. Max-only object.
|
N
|
N
|
N
|
|
Crew
|
Read-only on Salesforce.
|
N
|
N
|
Y
|
|
Crew Resource
|
Read-only on Salesforce.
|
N
|
N
|
Y
|
|
Dispatcher Access
|
Read-only on Max.
|
Y
|
Y
|
N/A
|
|
Event
|
Editable on Max and Salesforce.
|
Y
|
Y
|
Y
|
|
Holiday
|
Editable on Max and Salesforce.
|
Y
|
N
|
N
|
|
Installed Product
|
Read-only on Max.
|
Y
|
Y
|
N
|
|
Job
|
Editable on Max and Salesforce.
|
Y
|
Y
|
Y
|
|
Job Requirement
|
Partial mapping to Skill Set field of Salesforce Work Order object.
|
Y
|
Y
|
N
|
|
Location
|
Read-only on Max.
|
Y
|
Y
|
N
|
|
Product
|
Read-only on Max.
|
Y
|
Y
|
N
|
|
Qualification
|
Partial mapping to Expertise object.
|
Y
|
Y
|
N
|
|
Resource
|
Read-only on Max.
|
Y
|
Y
|
N
|
|
Resource Preference
|
Read-only on Max.
|
Y
|
Y
|
N
|
|
Service Team
|
Editable on Max after initial sync.
|
Y
|
Y
|
N
|
|
Territory
|
Read-only on Max.
|
Y
|
Y
|
N
|
|
User/User Parameter
|
Max-specific data is editable on Max.
|
Y
|
Y
|
N
|
|
View
|
Queues for Salesforce Work Order object are mapped to Max View object.
|
Y
|
Y
|
N
|
To support real-time sync from Salesforce to Service Board, Salesforce is registered as an external application with Max. Processes publish record create/update/delete events as platform events to which Service Board subscribes. When mapped fields are updated, platform events are published and the associated records are updated based on the related transform template definition. Failures are logged in the Salesforce Outbound Queue table with error codes and details, so that system administrators can address data issues as needed and manually retry sync operations.
 |
By default, platform event behavior is configured to Publish After Commit. Changing this value to Publish Immediately triggers errors and causes real-time sync failures.
|
To support real-time sync from Service Board to Salesforce, Service Board and Max are registered as connected apps with Salesforce. You can configure which records to synchronize back to Salesforce by defining Transform Templates that contain mappings between Max objects and Salesforce records. Additionally, you can configure HTTP Notification Request records to define conditions that specify the state changes for which field changes are to be included in the payload and synched back to Salesforce. Record create/update/delete events are queued in the Max HTTP Notification table, and a system job intelligently syncs events to Salesforce via REST APIs over an HTTPS connection. Data validation and other errors appear in the Service Board UI with guidance on next steps to resolve the errors. After the relevant records are updated, a system job automatically resends events that failed with data-validation errors (HTTP 400). Otherwise, system administrators must manually retry sync operations.
|
|
By default, the maximum number of HTTP notifications that can be sent per hour is 3,000. After that limit is reached, sync stops until you reconfigure the Maximum HTTP Notifications Per Hour value in the active System Setting record. For more information, see Configuring System Settings.
|
To avoid creating loops between Salesforce and Service Board, changes triggered by updates made in Salesforce are not synched back from Service Board to Salesforce in cases where the currently logged-in user is an integration user. However, there are some exceptions where changes are synced back to Salesforce, even if the updates originated from Salesforce.
Transactions have a context flag that you can set to bypass the integration user check, which means the context is available only for record in the same transaction. Changes triggered by After event handlers are not affected, since these are always new transactions. The integration user check is bypassed and changes in transactions are synced back to Salesforce in the following cases.
• When state conversions are triggered, state changes are caused in target records. For example, when Appointment status is changed by template mappings in Salesforce, status changes also are made in the related Job record. In this scenario, both the Appointment and Job changes are synced back to Salesforce. Although travel time calculation takes place during After event handler execution, values are not synced back to Salesforce, even if travel times are updated.
• When Appointment status changes, and causes updates to the order status of the related Job, both Appointment and Job changes are synced back to Salesforce.
• When Resources are removed in Salesforce, and the Delete Aborted Appointments setting is enabled, the related Appointments are deleted on the Service Board side, and changes are synced back to Salesforce.
• During real-time sync, when the Enable Real-Time Sync for Schedule Duration setting is enabled, and schedule duration for at least one Job record is recalculated, changes are synced back to Salesforce.
• When updates to Appointment records originate on the Salesforce side, and status changes are triggered by the related transform template, a flag is added to the transaction so that changes are synced back to Salesforce.
|
|
For all records, when the io_external_id value is updated, changes are not synched back to Salesforce.
|
For more information: