CRM Integration - Salesforce

This integration is designed for organizations that need to regularly synchronize CRM data between Administrate and Salesforce. The integration provides a one-way sync from Salesforce to Administrate for Accounts and Contacts.

Integration overview

• Accounts and Contacts are pulled from Salesforce into Administrate.
• Supports standard and custom fields on Accounts and Contacts.
• Administrators can review integration logs to audit and verify sync status.

Setup

Contact Support to enable and configure the Salesforce integration. During setup, you will confirm which Account and Contact fields should be synchronized.

Sync frequency

When the Salesforce integration is first configured, an initial sync pulls the defined Accounts and Contacts into Administrate.

After the initial sync completes, subsequent updates are pulled on a near real-time basis.

Account names and duplicate accounts

Administrate requires every account to have a unique name. Salesforce does not: Account Name is not a unique field in Salesforce, so a Salesforce org can hold several accounts with the same name. When the integration tries to create an account whose name already exists in Administrate, Administrate rejects it with the error "an Account already exists with the same name", and that account does not sync until its name is made unique.

Duplicate account names are not always bad data. There are two distinct causes, and they call for different responses:

• Genuine duplicates. The same real account entered more than once in the CRM. These are best cleaned up (merged or deleted) in Salesforce, which is the system of record.
• Legitimately distinct accounts that share a name. Common with account hierarchies, where a global parent account has separate child accounts per country or region that are distinct legal entities, or where the same legal name is registered by unrelated companies in different states. These are real, separate accounts that happen to share a name, and cannot simply be removed.

How uniqueness is enforced in the integration

Because the Salesforce integration is configured for each customer, account name uniqueness is built into that configuration. Agree which of these two approaches to use with Support during setup:

1. Map the Administrate account name to a dedicated unique Salesforce field. Create an "Account Name Alias" (or similarly named) field on the Salesforce Account object, keep it unique, and map that field to the Administrate account name. You maintain this field without changing the account's display name in Salesforce, so your downstream Salesforce processes are unaffected.
2. Append a differentiating value to the name. Configure the integration to combine the account name with one or more Salesforce fields so the result is unique, with no change in Salesforce. You choose whichever field or combination of fields best distinguishes your accounts, for example: - the Salesforce Account ID, which is always unique: Acme Corporation (0015000000XXXXXAAA) - a region or country: Acme Corporation (UK), Acme Corporation (Germany) - a state or billing city: Acme Corporation (Austin, TX) - an account number or other reference: Acme Corporation (AC-10482) - a combination of fields: Acme Corporation (Germany, AC-10482)

Pick the field or combination that is most meaningful to your team. If a single field might not be unique on its own (two same-named accounts could share a region, for example), combine it with another field, or add the Salesforce Account ID, which is always unique.

You do not need to change the account's display name in Salesforce for either approach to work.

Matching is by External ID, not by name

The integration recognizes accounts by their Salesforce ID (the External ID), not by their name. This is what makes the approaches above safe:

• Aliasing or appending to the name does not break the link between the Salesforce and Administrate records.
• Re-syncing an account that already exists updates it in place; it does not create a duplicate.

Loading data alongside the sync

If you load accounts or contacts into Administrate directly (for example, a data migration) as well as running the sync, include the Salesforce External ID on every record. The integration then recognizes and updates those records instead of creating duplicates. Loading without External IDs is the most common cause of duplicate accounts when a CRM sync is in place. See Importing when other systems are connected.

Limiting which accounts sync

If your Salesforce uses account hierarchies where parent accounts exist only to group child accounts together, you may not want those parent accounts in Administrate at all. During setup, discuss with Support which Salesforce accounts should be in scope, for example limiting the sync to a specific Account Record Type, so grouping accounts and unnecessary duplicates are left out.

Monitoring and conflict resolution

Administrators can monitor sync activity by navigating to:

Settings → Integration Logs → Salesforce Integration

You can open individual log entries to review details, including whether the sync was successful and any error messages returned.

If a sync fails, review the payload and error details to identify the issue. After correcting the problem, click Retry to reprocess failed records.