Salesforce integration: setup and best-practice guide

This guide explains how Delekit connects to Salesforce, how field and object mapping works, the campaign and account architecture we recommend, and how to prepare your org.

It is written for Salesforce administrators and CRM teams. Each section also works as a checklist item when you prepare an integration. Where a choice is yours to make, we mark it Decision.

1. How the integration works

The data model

Delekit maps events and attendees onto the standard Salesforce objects your team already uses for event marketing:

• Campaign. One Salesforce Campaign represents one Delekit event. Delekit records all attendee participation against it.
• Contact (or Lead). Delekit matches each attendee to a person record, or creates one. See section 3 to choose between them.
• CampaignMember. This links a person to a Campaign. It holds participation, status and event-specific fields. A CampaignMember can link to either a Contact or a Lead.

This is the standard Salesforce pattern for "person X is participating in event Y", so the data Delekit writes flows into your existing campaign reporting and automation.

Contact matching uses the Salesforce ID, not email

When Delekit reconciles an attendee with Salesforce, it matches on the Salesforce record ID, not the email address. Email changes when people switch jobs, correct typos, or use aliases, so it creates duplicates and mis-links when you use it as a long-term join key. The record ID never changes.

On first contact, Delekit looks the person up by email to avoid creating a duplicate. It then stores the returned Salesforce ID and uses that ID for all future synchronisation.

Duplicate prevention. Before Delekit creates any record, it searches for an existing match by email. If a match exists, Delekit reuses it and links it to the campaign. Delekit never creates a second record for someone already in your org. It creates only genuinely new people, and it always populates Salesforce required fields such as Last Name.

Synchronisation direction

Every mapped field has a direction, so you control what moves and where:

For Both fields, Delekit reconciles by timestamp. It treats the more recently modified side as authoritative, so the two systems converge without a fixed master. Pulls are incremental, so Delekit reads only records changed since the last successful sync. This keeps API usage low and predictable.

How and when data moves

• Scheduled sync runs on a regular interval, usually every 1 to 2 minutes. It pulls changed records into Delekit, pushes status and attendance back, and optionally pushes newly confirmed attendees to Salesforce.
• Push on confirm (optional). When an attendee confirms, Delekit sends them to Salesforce on the next sync. It matches or creates the person and links them to the campaign with their mapped fields.
• Atomic runs. Each event's sync commits as a unit. If a stage fails, Delekit does not advance the sync cursor, so nothing is half-applied and the next run retries safely.

2. Field and object mapping best practices

You configure mapping per event. Each row maps a Salesforce object and field to a Delekit field, with a direction. There are two kinds of mapping target:

• Core attendee fields. First name, last name, email, registration type, registration status, check-in.
• Attendee properties. The custom questions you collect at registration, such as dietary needs, session choices and consents. These map to any Salesforce field.

Recommendation 1: match field directions to ownership

Map each field in the direction of whichever system owns that data:

Recommendation 2: start in a sandbox and map incrementally

• Validate the mapping in a Salesforce sandbox before you touch production.
• Start with the essential fields (name, email, status). Add attendee properties once you verify the core flow.
• Confirm custom-field API names up front. Delekit maps to the API name, not the label.

Recommendation 3: agree picklist values exactly

Where Delekit writes to a Salesforce picklist, for example the custom Registration Status field, the values must match exactly in spelling and case. Salesforce rejects picklist values it does not recognise. Agree the value set on both sides before go-live.

What Delekit will never do. Delekit reads and writes only the fields you map. It does not modify unmapped fields, delete records, or alter your campaign settings, automation or picklist definitions. Deletion handling stays conservative. See section 5.

3. Recommended campaign and account architecture

One campaign per event

Create one Salesforce Campaign per Delekit event and link it in the integration settings. This gives you clean per-event reporting and a natural home for CampaignMember records.

Contacts vs Leads for new registrants (Decision)

When someone registers who is not already in Salesforce, decide whether to create them as a Contact or a Lead:

• Lead is Salesforce's object for a person who has shown interest but is not yet tied to an Account. Leads carry a plain Company text field, need no Account, and convert to a Contact and Account when qualified. This is usually the right choice for unknown registrants, because it avoids creating Contacts with no Account.
• Contact suits events that engage people already associated with Accounts, for example existing customers, or orgs whose process does not use Leads.

A CampaignMember can link to either a Lead or a Contact, so Delekit records event participation correctly either way. You set the create-as behaviour per integration. Where someone already exists, Delekit matches and reuses them regardless of the setting, and existing Contacts take precedence over Leads.

Account roll-up

When attendees are Contacts linked to Accounts, event participation associates with their Account, so you can report on event engagement by company. This needs no extra Delekit configuration. It follows from the standard Contact to Account relationship.

Architecture summary

• Event maps to one Campaign, with a parent and child hierarchy for sessions or days.
• Attendee maps to a matched or created Contact or Lead.
• Participation maps to a CampaignMember that holds status, check-in and event fields.

4. Pre-integration checklist

Work through this with your Salesforce administrator before the build. Items marked Decision are choices only your team can make.

Access and environment

• Identify a Salesforce integration user. A dedicated API user works better than a named individual.
• Confirm permissions on Contact, Lead, Campaign and CampaignMember for read, create and edit as needed.
• Provide a sandbox for initial setup and validation before production.
• Note any org-wide duplicate rules or validation rules that could affect record create and update.

Campaign architecture

• Create the Campaign
• Confirm the Member Status values on the campaign, and leave the standard Status for your own use.

Person records

• Decide whether Delekit creates unknown registrants as Leads or Contacts (Decision).

Field mapping

• Configure the attendee properties to sync and their target Salesforce fields (Decision).
• Agree the direction of each field (Decision): Pull, Push or Both.
• Agree exact picklist values on both sides where Delekit writes to a picklist.

Behaviour and governance

• Decide whether to enable push on confirm (Decision).
• Review deletion and cancellation handling and agree the behaviour you want (see section 5).
• Validate end-to-end in sandbox: create, match, status push, property sync.

5. Data governance, deletion and safety

What Delekit touches

Delekit reads and writes only the fields you map, on the person record and CampaignMember, for the campaigns you link. It does not alter unmapped fields, other objects, automation, or org configuration.

Deletion handling

Delekit's sync is additive and conservative. It does not delete records or remove CampaignMembers automatically, in either direction. This is a safety choice. Incremental sync cannot reliably tell "deleted" apart from "temporarily not returned", and automatic deletion based on that guess is dangerous.

For cancellations and declines, represent them as a status change, for example Registration Status to Cancelled, that flows through the normal field mapping rather than deleting records. This preserves history and reporting on both sides. If your governance requires propagated deletes, you can design an explicit, bounded reconciliation step using Salesforce's deleted-records mechanisms. Keep it opt-in and rate-limited so a transient error cannot cascade.

Reliability and security

• Atomic per-event sync. A failed stage does not advance the cursor, so runs retry cleanly.
• Incremental reads keep API consumption low and within limits.
• Credential handling. Delekit stores credentials securely and never exposes them in the application or logs.

6. Getting help with your mapping

You do not have to work through the mapping exercise alone. The Delekit technical support team fully supports Salesforce integration mapping. They can discuss your setup and work through the field and object mapping with you over a call.

To arrange a technical call, reach out to your account manager.