Connecting CRM, HCP identity, and consent

Use this pattern when Veeva, Salesforce, or another customer system owns HCP identities, consent status, or upstream event approval. The customer system remains the system of record; Onomi uses synchronized identifiers and statuses to run event work.

Define the ownership rule before mapping fields. A value should have one authoritative source and a documented direction when it is synchronized.

Define the records and directions

A typical CRM connection has four flows:

• Event intake creates or updates an Onomi event from an event approved upstream.
• Registrant synchronization reconciles selected participant and registration fields for workspace-backed events.
• Engagement write-back sends permitted attendance and engagement results to the HCP timeline in the CRM.
• Meeting record sync, outbound sends the meeting record and its attendees to the CRM, including the record-only lane.

Not every deployment uses every flow. Record the enabled flows, their filters, and their system-of-record rules in the deployment solution architecture.

Match HCP identities

Use a stable customer identifier as the primary match key whenever one exists. Email address can support a match but should not silently replace a missing master identifier because addresses change and may not be unique across sources.

Agree what happens when a record is missing its identifier, matches several HCPs, or conflicts with an existing link. Put unresolved records into a visible exception process instead of selecting a person automatically.

Onomi stores the resolved reference needed for event work. The CRM or master-data platform continues to own the HCP profile and the process used to merge or correct duplicate identities.

Keep consent in the customer system of record

The customer's consent-management platform, master-data platform, or CRM remains authoritative for consent. Core Onomi event capabilities may capture a consent response and send it to that system; Onomi 360 may display the synchronized status or reference needed for an event decision.

Define each consent purpose, market, effective period, and source reference in the customer data contract. Do not reduce several purposes or country-specific statuses to one general consent flag unless the customer system already defines that interpretation.

Before an outbound engagement update, apply the consent gate agreed for that destination. A blocked update remains visible for investigation and does not erase the event-side attendance or engagement record.

The connection should record enough information to explain why an update was sent, withheld, retried, or rejected. The customer system remains authoritative if the two sides disagree.

Receive events approved upstream

An event approved in Veeva CRM Events Management, Veeva CRM Medical Events, Salesforce, or another upstream process can arrive already Approved. It does not pass through the Onomi request approval rules, compliance gate, auto-approval, or request-time hospitality check.

Map at least the upstream reference, request category, dates, budget band and currency, geography, business unit, and any therapeutic area or brand used for scope or reporting. The category selects the same event-creation behavior used for a portal request.

If the category value matches no active category, Onomi creates no event. The arrival appears under Event requests > Held arrivals, where an organization administrator can see the source reference, arrival time, and value that failed.

Correct the connector mapping or add the required request category, verify its event-creation behavior, and send the source record again. Held arrivals are retained for 30 days.

See From approval to execution and auditing requests for the full upstream-event behavior.

Synchronize participant and engagement data

For a workspace-backed event, the participant connection can reconcile the selected identity, registration, and status fields defined in the mapping. Attendance, questions, survey answers, or other engagement results are written back only when the enabled flow, consent rule, and destination mapping permit them.

A record-only meeting has no workspace registration journey. Its meeting record and attendees can synchronize outbound through the agreed meeting-record flow, but later lifecycle changes are sent only if the connector contract explicitly includes them.

If Salesforce is the HCP master, the mapping can associate synchronized people with the customer's Contact and Account records. Customer-specific objects, field names, and ownership rules remain part of the deployment mapping.

Filter the synchronized population

Use connector filters to limit synchronization to the intended organizations, business units, markets, event types, or other documented attributes. Apply the same filter logic in sandbox and production unless the difference is deliberate and recorded.

A record outside the filter remains in its source system and is not a connector failure. Report filtered, failed, and unresolved records separately so support teams can tell those states apart.

Define retry and support ownership

For every flow, document:

• the source and destination identifiers;
• fields and direction of ownership;
• create, update, and duplicate behavior;
• consent and filtering rules;
• retry and dead-letter handling;
• monitoring and reconciliation reports; and
• the team that corrects each kind of exception.

Test a create, an update, an unresolved identity, a refused consent update, an unmapped category, and a retry before production activation. Keep the test records synthetic and verify the audit history on both sides.

For the other integration families, see Integration patterns: connecting Onomi to your enterprise systems.

* Onomi 360 MeetingsEQ exclusive capabilities.