Integration Platform as a Service tools are often valuable to organizations seeking to “sync” information between different applications.
For example, perhaps you have a SharePoint instance and want to put that information in a database or other platform. What best practices would help keep things working smoothly?
In this brief module we share some guidelines to keep your bi-directional sync processes working great …
Course Material
Integration Platform as a Service tools are often valuable to organizations seeking to “sync” information between different applications.
For example, perhaps you have a SharePoint instance and want to put that information in a database or other platform. What best practices would help keep things working smoothly?
In this brief module we share some guidelines to keep your bi-directional sync processes working great …
Setup and Flow Design Considerations
To implement a “Bi-Directional Sync” process, you should focus on several key setup and Flow design considerations.
1 - Handling Race Conditions
A race condition occurs where the output is dependent on the sequence or timing of other uncontrollable events.
Example:
Imagine you have a process that is editing a file. You may have multiple processes accessing the same file. For a particular system, if you edit a file, that file may be put into a “locked” state. If this occurs, what happens to your Flow?
This depends on the system but, in short, you may receive an error because the file may be inaccessible to the Flow. This could then result in a race condition, so as a Flowgrammer you will want to anticipate race conditions and use error handling to avoid any issues.
Webhooks are something that can help you avoid race conditions, so whenever you can you should try to leverage webhooks instead of standard polling-style connectors. We discussed this in Module 201 (Event Types) - unlike polling methods where your Flow reaches out to an application - a webhook is a real-time event that will initiate your Flow. Again, webhooks aren’t always an option, but if the application being used offers them - take advantage!
2 - Use Integration-Dedicated Accounts with All Systems
Using Integration-Dedicated accounts Will make your life easier when building Flows.
Why is this?
Commonly you will want the account being used for the integration to have appropriate rights (admin rights, for example). Additionally, you may also have to associate a particular “tier” or profile that grants that account the right level of access.
An Integration Account is also much better than a personal account because it can be set to expire less frequently and isn’t subject to common problems where an individual account owner leaves your organization, breaking your Flows.
Going back to the Webhook topic from just a moment ago - you can also enhance your Flows to execute only if these Integration Accounts are being used. For example, you can leverage a “Continue If”. If the User Account ID is not equal to your Integration Account user - you can stop Flow progress.
3 - Where to Store External IDs
If you’re working to synchronize two or more different data sources, External IDs are a common technique that allow you to map information between systems.
Example: Syncing Records between Two (or more) Salesforce Instances
Salesforce gives unique identifiers for all records … something like “0016A00000NvEq9”. Usually a 15-18 character string.
Were you to sync between two systems, you’d leverage External IDs to map between them.
In context of our application - Tables are really great for this - you can leverage a table to map between different systems
4 - What Fields to Update?
Ultimately, you’ll need to figure out what fields you want to update (and in each system). That may also require some consideration of application-based permissions - depending on the system
Summary
Affecting a great bi-directional sync strategy is, of course, complicated so we hope that this module has helped give you a valuable place to begin.