How Are Unique Identifiers Organised (Email, etc.)?

Within the integration between Salesforce and Azavista, unique identifiers are organised in a fixed, system-defined hierarchy to ensure accurate record matching, prevent duplication, and maintain referential integrity.

Important:
Identifier logic is not configurable. Users cannot select or modify which fields are used for identification. The structure described below is automatically enforced by the integration.

1. Overall Identifier Hierarchy

Unique identifiers are organised in the following priority order:

1. Salesforce Record ID (Primary Identifier)
2. Email (Fallback – Contacts only)
3. New record creation (if no match found)

This hierarchy is fixed and applies consistently across synchronization scenarios.

2. Primary Identifier: Salesforce Record ID

Each object in Salesforce (Contact, Account, Event, Campaign Event, or managed package object) has a system-generated Salesforce Record ID (15/18-character ID).

How it is organised in the integration:

• The Salesforce Record ID is stored inside Azavista (visible in the Inspect tab).
• It is the authoritative technical identifier.
• It is used for all update operations.
• It overrides all other matching logic when present.
• It cannot be modified or replaced.

Practical effect:

If a Salesforce Record ID exists:

→ The system performs strict ID-based matching
→ The existing record is updated
→ Email matching is not used

This applies to Contacts, Organisations (Accounts), Events, and Members.

3. Email as a Fallback Identifier (Contacts Only)

Email is organised as a secondary, fallback identifier and applies only to Contacts/Participants.

When is Email used?

Email is used only if:

• No Salesforce Record ID has yet been stored.

In that case:

→ The system attempts to match by Email
→ If a match is found, the Salesforce ID is stored
→ If no match is found, a new record is created

Once the Salesforce Record ID is stored, it becomes the permanent sync anchor.

Important Clarification

• Email is not a configurable unique identifier.
• It does not override an existing Salesforce ID.
• It is only used during initial matching scenarios.

4. Organisation (Account) Identifier Organisation

For Organisations:

• Matching is based on the Salesforce Account Record ID.
• Account Name is not used as a guaranteed unique identifier.
• Custom External ID fields are not used by the integration for matching.

There is no configurable identifier selection for Accounts.

5. Event Identifier Organisation

For Events or Campaign Events:

• Matching is based on the relevant Salesforce Record ID.
• The Record ID ensures correct linking between events and participants.
• There is no alternative identifier logic.

6. Member (Participation) Identifier Organisation

Participation records (Members) are organised using:

• The Salesforce Record ID of the participation object
• System-managed linkage between Contact ID and Event ID

This ensures:

• A Contact can participate in multiple events
• Each participation record remains distinct
• Referential integrity is maintained

7. Clarification on “External ID”

In this integration context:

“External ID” refers to the Salesforce Record ID stored inside Azavista.

It does not refer to:

• A configurable Salesforce Custom External ID field
• A user-defined identifier
• A selectable matching option

The identifier structure is fixed and not user-configurable.

Summary: How Identifiers Are Organised

Final Answer

Unique identifiers in the Salesforce–Azavista integration are organised in a fixed priority model:

• Salesforce Record ID is always the primary and authoritative identifier.
• Email is used only as a fallback for Contacts when no Salesforce ID exists.
• There is no configurable identifier framework.