Concurrency best practices

General guidelines

We recommend that you follow these best practices for team collaboration:

• Create a separate version for development: Use the Save As option to create a separate version based on the published version. Use the new version for development.
• Compare only with the published version: Compare and integrate your version with the published version, because you cannot compare and integrate your version with other versions.
• Save frequently, avoid multiple versions for the same project: Save your changes frequently to the new version with the Save option, not Save As. Creating multiple new versions during development will result in confusion when it is time to reconcile your changes to the published version and then publish them.
• Make small changes, publish often: Keep your development version changes small and publish often to reduce the impact on your peers. This will make it easier to troubleshoot any errors and revert changes.
• Your changes supersede the changes of others: If your changes and the latest published version modify the same item, publishing your version replaces the existing items in the published version with yours.
• Coordinate with your team: Communicate your plans between your teams. Identify any potential issues of overlap early to prevent teams from inadvertently saving over each other’s changes to common elements.
• Integrate the published version: Any time your current version is behind the published version, integrate the published version into your version. This will make it easier to publish your changes later. The profile switcher and the Save/Publish dialog contain a status message that you can use to compare your version’s changes to the currently published version:
  • You are ahead of the published version
    Your current version includes changes that are not in the currently published version.
  • You are up to date
    Your current version and the currently published version match.
  • You are behind the published version
    The currently published version includes changes that are not in your current version. To view those changes, click View latest published changes. For more about these status messages and how to use them, see About Server-Side Saving and Publishing.

Example workflows

In the following examples, an organization has two users working on the server-side platform. User 1 is working on a connector while User 2 is working on a data source.

Concurrent saves to same version

In the following example, both users are working together on the same version.

The diagram above shows each action performed.

1. We begin with a single version A1 currently published. When visitors go to the site or app, they use version A1.
2. User 1 adds a connector.
3. User 2 adds a data source.
4. User 1 saves changes to version A1. User 2 receives a notification that User 1 has updated this version.
5. User 2 saves changes to version A1, integrating User 1’s changes (the new connector). User 1 receives a notification that User 2 has updated this version.
6. User 1 loads version A1 and receives User 2’s changes (the new data source).
7. User 1 publishes version A1. User 2 receives a notification that User 1 has published this version. User 1 and User 2 are up to date.
8. When visitors go to the site or app, they use version A1 with the new connector and data source.

Concurrent saves to multiple versions

In the following example, each user is working on their own version.

The diagram above shows each action performed.

1. We begin with a single version Start currently published. When visitors go to the site or app, they use version Start.
   • Start: You are up to date.
2. User 1 creates a new version of Start named Project 1.
   • Project 1: You are up to date.
3. User 2 creates a new version Start named Project 2.
   • Project 2: You are up to date.
4. User 1 adds a connector to version Project 1 and saves.
   • Project 1: You are ahead of the published version.
5. User 2 adds a data source to version Project 2 and saves.
   • Project 2: You are ahead of the published version.
6. User 1 publishes version Project 1 and receives a notification that version Project 1 has been published. When visitors go to the site or app, they use version Project 1 with the new connector.
   • Project 1: You are up to date
   • Project 2: You are behind the published version.
7. Project 1 is complete.
8. User 2 saves changes to version Project 2, using the Include latest published changes option to integrate changes from version Project 1 (the new connector).
   • Project 2: You are ahead of the published version.
9. User 2 publishes version Project 2. When visitors go to the site or app, they use version Project 2 with the new connector and the new data source.
   • Project 1: You are behind the published version.
   • Project 2: You are up to date.
10. Project 2 is complete.