Work.com Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
Extend Work.com with Custom Solutions
Set Up Your Work.com Development Org
Develop a Workplace Command Center Solution
Package and License a Workplace Command Center Component
Understand the Work.com Data Model
Work with Employee Data
Link Employee with Other Objects
Synchronize Work.com Data Between Orgs
Authenticate Between Work.com and Other Orgs
Understand Location Data
Command Center Data Triggers
Understand Logging
Standard Objects Used by Work.com
Custom Objects and Fields Used by Work.com
Custom Metadata Types Used by Work.com
Model Workplace Reopening with Shift Management
Evaluate When to Open or Close Locations with Workplace Strategy Planner
Add a Support App to Employee Workspace with Employee Concierge
Implement a Queue Management Visitor Experience
PDF

Synchronize Work.com Data Between Orgs

Users are encouraged to install and use Work.com in an org dedicated to Work.com. This may result in scenarios where data in an existing org has to be migrated or kept in synch with a new Work.com org.

When keeping orgs in synch, avoid using bi-directional synchronization, as manual conflict management between org data will be required. Instead, we recommend having a single “source of truth” org. If a data change occurs in a different org, use Salesforce APIs to make the change in the “source of truth” org first, and then synchronize the change back to the org where the change initially occurred.

If other orgs only need read-only access to Work.com org data, use Salesforce Connect to display the Work.com org data in the other orgs. If Salesforce Connect won’t work for your scenario, you can use Salesforce API calls to query the Work.com org. For example, you could use on-demand API calls in your Lightning Web Components to query your Work.com org data, and display the data in your component.

Consider doing initial data synchs followed by smaller incremental data synchs. A strategy might work as follows:

  • Run an initial data load job to move data to the new org.
  • Run nightly or hourly incremental data load jobs to keep orgs in synch.
  • If a record is updated in the new org, use Salesforce APIs to update the existing org first, and then migrate that incremental change back to the new org. This avoids unnecessary data conflicts.

Data synchronization middleware tools might help with this process.