Skip to main content

Element ID and Slate ID: Managing Identifiers Across Element451 and Slate

Use the Element ID field in Technolutions Slate and the Slate ID identity in Element451 to keep records matched, deduplicated, and in sync across both systems.

Written by Kootayba Chihabi

Overview

A reliable Slate integration rests on two identifiers, one stored in each system. Set these up before you configure either sync direction. They are what let every import and export match records deterministically, prevent duplicates, and attach conversation Interactions to the right people.

Identifier

Lives in

Holds

Used for

Element ID

Slate (custom field you create)

The record's unique Element451 identifier

Matching on every Element451-to-Slate import, attaching Interactions, dupe prevention

Slate ID

Element451 (built-in identity type)

The record's Slate identifier

Matching on every Slate-to-Element451 import, persistent identity between systems

Setting up Element ID in Slate

  1. In Slate, create a person-scoped custom field named Element ID. This field stores the unique identifier generated by Element451 and is used to match conversation records to the correct person, attach future interactions to the same record, and prevent duplicate person creation.

  2. Populate it during the lead import (see Element451 to Slate: Syncing Bolt Outputs Back to Your CRM). Conversation imports reference the same value.

  3. We also recommend a second custom field, Element Created Date, recording when the contact was first created in Element451. It is optional, but it helps with reporting, understanding inquiry timing, and troubleshooting imports.

Recommended: flag Element ID as Unique for Merging

Consider configuring the Element ID field as Unique for Merging in Slate. When a field carries that flag, Slate can use its value as a secondary identifier during import matching. That protects the sync when records are merged or internal identifiers change inside Slate. For example, if two person records are merged and the original Slate ID changes, the Element ID still matches incoming Element451 data to the correct record.

During imports, Slate typically attempts matching in this order: Slate ID first, then other configured matching criteria, then fields marked Unique for Merging. Using Element ID as a unique merge field improves long-term synchronization reliability.

Slate documentation: Unique for Merging and Matching Criteria for Person Records.

Setting up Slate ID in Element451

Element451 includes Slate ID as an identity type. Identity fields participate in matching the same way email does.

  1. In your inbound import task (see Slate to Element451: Setting Up the Inbound Data Sync), map the Slate ID column to the Slate ID identity field on the Mapping tab.

  2. On the Configuration tab, include Slate ID in your Matching settings alongside Email (an external ID field also works). This ensures existing records are updated instead of duplicated.

📌 Note: When multiple matching fields are selected, Element451 uses them together. If two fields match two different existing profiles, the row is skipped rather than guessed. Skipped rows appear in Run History with the reason. This is by design and protects you from silent mismatches. See Creating Imports for full matching behavior.

How the round trip stays keyed

  1. Slate exports records including the Slate ID. Element451 stores it as the Slate ID identity on each person.

  2. Element451 exports records including the Element ID. Slate stores it in your Element ID custom field.

  3. From then on, each direction matches on its counterpart identifier first, with email, name, and birth date as supporting evidence for dedupe.

New records need one full cycle to become fully keyed. A brand-new inquiry captured by a Bolt agent arrives in Slate with an Element ID but no Slate ID yet. Once Slate creates the record, your next inbound export carries its new Slate ID back to Element451, closing the loop.

Practical rules

  • Use Element ID as the primary cross-system identifier, and flag it Unique for Merging

  • Include birth date in both directions where available. Slate's dedupe (first + last + email + DOB) is markedly more reliable with it

  • Never repurpose or hand-edit the identifier fields. Treat them as system-owned

  • If you bulk-merge or purge records in either system, expect some identifier pairs to break, and re-key via the next sync cycle. The Unique for Merging flag limits the damage on the Slate side

Related Articles
Did this answer your question?