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 FLO Design Considerations

To implement a “Bi-Directional Sync” process, you should focus on severaly key setup and FLO 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 FLO?

This depends on the system but, in short, you may receive an error because the file may be inaccessible to the FLO. This could then result in a race condition, so as a FLOGRAMMER 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 FLO reaches out to an application - a webhook is a real-time event that will initiate your FLO. 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 FLOs.

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

Going back to the Webhook topic from just a moment ago - you can also enhance your FLOs 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 FLO progress.

3 - Where to Store External IDs

If you’re working to synchronize two or more different data sources, External IDs are a commony 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.