From 82355473f8ba7e15961676d0baf03b3d1ce434bb Mon Sep 17 00:00:00 2001 From: johnjeremiah Date: Tue, 10 Mar 2026 13:27:25 -0400 Subject: [PATCH] Adding Eventbrite-SFDC connection details (#41336) Adds section about how to integrate Eventbrite to sfdc campaigns with clay --- handbook/marketing/event-execution.md | 93 ++++++++++++++++++++++++++- 1 file changed, 92 insertions(+), 1 deletion(-) diff --git a/handbook/marketing/event-execution.md b/handbook/marketing/event-execution.md index 26ca8bb8e1..3c4a623872 100644 --- a/handbook/marketing/event-execution.md +++ b/handbook/marketing/event-execution.md @@ -124,6 +124,8 @@ We use GitHub labels to organize the difference between overall event issues and | **:mktg-event:YYMM-eventname-city** | Salmon | \#FA8072 | 5th color custom lable for specific events | | **:mktg-event:YYMM-eventname-city** | Brick | \#B91C1C | 6th color custom lable for specific events | + + ### **Event plans** We utilize two general event plans, which act as templates depending on the scale and type of the event: @@ -131,7 +133,6 @@ We utilize two general event plans, which act as templates depending on the scal 1. **Conference:** Used for large conferences and events where we have a booth, speaking slots, lead scanning, and other major logistical needs. 2. **Workshop/Happy hour:** Used for our GitOps workshop series (which often includes happy hours). This smaller template can be used for the full workshop or for bespoke, standalone happy hours. - ### **Execution process** Once an event is approved, a Marketing directly responsible individual (DRI) is assigned. From there, the process is divided between the Marketing DRI and the Onsite DRI. @@ -771,6 +772,96 @@ create_sub_issue "6. Post-Mortem & Follow-Up" echo "Done." ``` +## **Connecting Eventbrite Registrations to Salesforce Campaigns (Event ID Key)** + +#### **Purpose** + +We need a reliable, repeatable way to associate each Eventbrite registration with the correct Salesforce Campaign **without adding any visible fields to the attendee experience**. This approach uses the Eventbrite **Event ID** as the canonical key to map registrations to Campaigns in Salesforce. + +#### **Core Idea** + +Each Eventbrite event has a unique identifier (`event_id`). We store that identifier on the corresponding Salesforce Campaign. When a new registration occurs, our integration (e.g., Clay) reads the `event_id` from the registration payload, finds the matching Campaign, then creates/updates the Campaign Member. + +This creates a clean 1:1 relationship: + +**1 Eventbrite Event → 1 Salesforce Campaign → Many Campaign Members (registrants)** + +#### **Why This Approach** + +* **Invisible to attendees:** No hidden checkout questions or user-facing “tags.” +* **Stable and unambiguous:** Event IDs are unique and don’t depend on event names. +* **Easy to operationalize:** Simple to document and enforce as a process. +* **Scalable to other platforms:** The same pattern could be extended to Lu.ma later using a platform-specific ID or key (if we ever want to use Lu.ma) + +### **Data Model (Salesforce)** + +#### **Campaign Fields** + +Add the following field to **Campaign**: + +* **Event Key** (Text) \= composite key of the platform and event id: + * `eventbrite:{event_id}` + * `luma:{event_id}` + +The composite key pattern lets us use one matching field across platforms and avoid collisions if we ever want to use [Lu.ma](http://Lu.ma) or others. + + +### **Operational Workflow** + +##### **1\) Capture the Eventbrite Event ID** + +The Event ID can be sourced from: + +* Eventbrite event page URL (contains the ID), or +* Event settings / Event details in Eventbrite, or +* Eventbrite API / integration payload + +**Important:** Do not use event name as a key (names can change and are not guaranteed unique). + +##### **2\) Create the Salesforce Campaign** + +* Create a Campaign for the event. +* Set: + * **Event Key** `eventbrite:{event_id}` + +##### **3\) Integration Logic (Clay)** + +When Clay receives a new Eventbrite registration/attendee record: + +1. **Extract** `event_id` from the Eventbrite payload + * Clay knows it’s coming from Eventbrite, so it looks up the event\_id and then is able to create the composite key “eventbrite:{event\_id}” +2. **Find Campaign** in Salesforce where: + * *`Event Key = eventbrite:{event_id}`* +3. **Create/update Person Record** + * Match/Create the Contact +4. **Create/Update Campaign Member** + * Add the person as a Campaign Member on the matched Campaign + * Optionally set Campaign Member Status (e.g., `Registered`, `Attended`, `No Show`) if we later sync those states + + +### **Assumptions / Scope** +* **One ticket type per Campaign** (i.e., we do not need ticket-type-level mapping). +* **One event maps to exactly one Salesforce Campaign**. +* We are focusing on **registrations** (Campaign Members). + +### **Governance & Quality Controls** +To keep the system clean and prevent broken mappings: + +* **Required fields:** Ensure Campaigns intended for Eventbrite syncing have `Event Key` populated. +* **Uniqueness guardrails:** Prevent multiple Campaigns from sharing the same Event Key (via process, reporting, or validation rules). +* **Monitoring:** Have a Clay/Salesforce report for “registrations received with no matching Campaign” to catch missing IDs early. + +### **(FUTURE) Extending This to Lu.ma (Future)** +If we adopt Lu.ma later, we can follow the same model: + +* Store Lu.ma’s stable event identifier (ID or slug) on the Salesforce Campaign. +* Use `Event Key` to map inbound registrations to the correct Campaign. +* No attendee-visible fields required. + +### **Summary** + +This approach “connects” Eventbrite to Salesforce Campaigns by using the **Eventbrite Event ID as the system-of-record key**. Salesforce Campaigns store that key, and Clay uses it to automatically route registrations to the right Campaign and create/update Campaign Members—cleanly, invisibly, and in a way that can later support additional event platforms. +