End System (or "System")
End System refers to any application or service that has been connected to your Sync integration. A marketing system, sales application, or enterprise resource platform would all be examples of End Systems.
Connectors represent the link between Sync and your End Systems for the purpose of granting access and configuring permissions. You will install and configure Connectors for each System you would like included in your integration. Authenticating Connectors is usually quick and easy, but the process varies depending on your End Systems.
An application-programming interface (API) is a set of programming instructions and standards for accessing a Web-based software application. Companies release their API to the public so that other software developers can design products that work with their system.
End Systems contain various “Objects”, of which Sync supports the following:
Depending on the Systems you’re integrating you may see other terms used interchangeably with these universal terms but the objects they represent are the same. These objects define the meaningful attributes that represent people (Contacts), business entities (Companies), upcoming potential revenue-generating events or activities (Opportunities), and End System users (Owners).
An additional object that exists in some End Systems is the “Owner” Object, which represents an internal user within the System such as sales or marketing staff. Sync will not create or update Owner information, but that information may be included in other aspects of your integration.
While Objects define the attributes for the entities above, “Records” are where the data representing any unique instances of those Objects is stored. Records are stored with a unique identifier in each System and matching records between those Systems is a key step in the Sync process.
Once matching records within your End Systems have been identified, Sync will “Index” those records together to facilitate the process of keeping those records synchronized during future updates.
Representing associations between records of different Object types in your End Systems, such as an associated Contact or Owner of a Company, is accomplished through the use of "Relationships". Matching and preserving Relationships across systems is one of the more advanced functionalities handled by your Sync integration.
"Fields" store the data that represents the various properties that describe an Object type. Reading the values stored in these Fields and comparing them to the values stored in your other End Systems is another key step in the Sync process.
Fields on a Record can be configured to store different types of Field data. Some examples and common terms used to describe these different "Field Types" are:
- Text Fields
- Text Area
- Select Fields
- Single-Select (Radio Buttons)
- Multi-Select (Checkboxes)
- Dropdown Select
- Date / Time Fields
- Number Fields
- Boolean Fields
- Single Checkbox
- True / False
- Yes / No
Your End Systems may use different Field Types to represent the same data; for example, End System A might use a Select Field for the Country in an address, whereas End System B might use a Text Field. Depending on your configuration this may require some alignments to Fields or data within your End Systems, which is covered in the Pre-Integration Requirements section of the guide.
The method Sync utilizes to match Records across systems is DeDuplication. Depending on the Object being matched, properties that are reliably unique and consistent across platforms are used to build a DeDuplication Key and index records together.
Each Object type has a pre-defined DeDuplication Key that represents a combination of properties that are reliably unique and consistently available for these Objects in various Systems. A detailed list of the properties used for each Object type can be found in our How Does Formstack Sync DeDuplicate... article.
Duplicate Records refers to multiple records with matching DeDuplication Keys existing within a single End System. When Sync detects duplicate records, no further steps will be taken to process those records until one of the records is merged or deleted.
After records have been DeDuplicated, the meaningful Fields from each System are aligned through the use of "Mappings". You’ll configure mappings for Objects, Fields, and Relationships (if applicable).
Object Mappings are the first that you’ll configure within your Sync account. In doing so, you’ll define the specific Object types that Sync will have access to within your integration.
While Object Mappings define the specific Object types synchronized by your integration, Field Mappings define the specific data you’d like synchronized for each of those Objects. If a field is not mapped, Sync will not include that Field in evaluations to determine whether a meaningful update has occurred or include that field information in any updates that are processed through your integration.
When synchronizing data via your integration, Relationship Mappings preserve the native associations that exist between Objects of different types. If supported by the Connectors for your End Systems, Owner relationships can also be mapped to preserve record assignments.
A key step within your Sync integration is configuring the End System that should be given priority for a particular Field Mapping or Relationship. The System of Record will always be respected and Sync will never remove or overwrite existing data in that System.
Within the context of your Field Mappings, "Read-Only" is a configuration that can be set to limit the ability of Sync to write data to a Field. Your End Systems may also allow for designating fields as Read-Only, in which case Sync will reflect that setting in the mapping for that field automatically.
Some use cases require that Objects are processed in different ways based on specific criteria (such as qualifying a Contact as a Lead or a Customer based on some data that exists on the record). In these cases, "Object Mapping Conditions" allow for defining the criteria that will tell Sync the appropriate Object Mapping to use for processing that Record.
Use cases that require granular control over the field data included as part of their Sync runs are able to do so by utilizing "Field Mapping Filters". These filters are configured within individual Field Mappings and allow for defining the logic that Sync should use to determine whether a particular Field will be included when Sync handles a Record.
After all data from your End Systems has been read into Sync and evaluated, that data is processed according to the "Workflows" defined within your integration. Workflows provide a variety of options for defining the logical criteria that must be met for an entire Record to pass through Sync into your End Systems, as well as any additional actions that should be included in that process (such as adding records to a specific list within an End System).
To view the next article in the Sync Set Up Guide, click here: Pre-Integration Requirements: Duplicate Record Clean Up