InEvent + Marketing Cloud Account Engagement (Pardot) Integration

2.0 Data Model & Field Mapping

The foundation of the integration is the accurate mapping of the InEvent Attendee object to the Pardot Prospect object. This section details the data schema and conflict resolution logic.

2.1 Unique Identifier and AMPSEA

Pardot utilizes AMPSEA (Allow Multiple Prospects with Same Email Address). However, for the purpose of this integration, the Email Address serves as the primary deduction key.

• Logic: When InEvent pushes a record, it queries the Pardot database by Email.

• Conflict Resolution: If multiple Prospects share an email (e.g., duplicates exist in Pardot), the integration will update the Prospect record with the most recent activity timestamp. To maintain data integrity, it is highly recommended to perform a database hygiene exercise to merge duplicate Prospects prior to enabling the sync.
  
  

2.2 Standard Field Mapping

The following table defines the required mapping between InEvent Standard Fields and Pardot Default Fields. These mappings must be configured in the InEvent Integration Dashboard.

Note on Sync Behavior: Setting the behavior to "Use Salesforce Value" ensures that if a Prospect registers for an event with a slightly different job title (e.g., "VP Marketing" vs "Vice President of Marketing"), the trusted data in the CRM is not overwritten by potentially casual data entry during event registration. If the goal is to enrich data, change this setting to "Use the most recently updated record."

2.3 Custom Field Mapping (Registration Questions)

Event registration forms often capture data points that do not exist in the standard Pardot schema (e.g., "Dietary Restrictions," "T-Shirt Size," or "Purchasing Authority").

Configuration Steps:

1. Create Field in Pardot: Navigate to Pardot Settings > Object and Field Configuration > Prospect Fields. Create a Custom Field (e.g., Event_Dietary_Preference).

2. Map in InEvent: In the InEvent integration settings, map the specific Registration Form Question to the Event_Dietary_Preference API name.

3. Data Type Validation: Ensure strict data type alignment. If the Pardot field is a "Dropdown" (Picklist), the InEvent registration form must utilize a "Selection" input with identical values. A mismatch (e.g., sending "Vegan" to a field that only accepts "Plant-Based") will result in a Sync Error and the record may fail to update.
   
   

2.4 Handling Null Values

The connector is configured to ignore null values by default. If a field in InEvent is empty, it will not overwrite an existing value in Pardot with a null. This protects the integrity of enriched prospect profiles. However, if "Overwrite" is explicitly enabled in the API configuration, an empty string sent from InEvent will wipe the data in Pardot. This setting should be disabled for all production environments.

3.0 Engagement Studio Architecture

Pardot’s Engagement Studio is the orchestration engine for event lifecycle communications. The InEvent integration fuels this engine by providing the necessary triggers and decision points.

3.1 Entry Triggers (List Membership)

The most robust method for initiating an Engagement Studio Program is List Membership.

• Process: When a user registers in InEvent, the integration adds the Prospect to a specific Pardot Static List (e.g., "Event_2024_London_Registrants").

• Studio Configuration: The Engagement Studio Program uses this list as the Recipient List. As soon as the API adds the Prospect to the list, they enter the program flow immediately (or according to business hours settings).
  
  

3.2 Dynamic Segmentation (Rule-Based Lists)

For more complex segmentation, use Dynamic Lists based on custom field values synced from InEvent.

• Example: A Dynamic List named "VIP Registrants" can be configured with the logic:

• Prospect List is member of Event_2024_Global

• AND

• Prospect Custom Field [Ticket_Type] is VIP

• Usage: This Dynamic List can feed a separate "VIP Experience" track within Engagement Studio, ensuring high-value attendees receive specialized communications without manual sorting.
  
  

3.3 Branching Logic and Decision Nodes

Once inside the Engagement Studio, the integration enables behavioral branching based on the attendee's lifecycle state. Since "Status" is a dynamic field, we often use "Tags" or "List Membership" to denote state changes.

Technical Example: Post-Event Follow-Up Flow

1. Trigger: Prospect enters program via Event_Registration_List.

2. Action: Send Email 1: "Know Before You Go."

3. Wait Step: Wait until Specific Date (Event Start Date).

4. Wait Step: Wait 2 days (Allow for data sync post-event).

5. Rule (Decision Node): Check List Membership.

• Condition: Is Prospect a member of Event_Attendance_List? (This list is populated by the integration upon physical check-in or virtual login).

6. Branch YES (Attended):

• Action: Send Email 2: "Thank You for Attending / Slide Deck."

• Action: Adjust Score +50.

• Action: Notify Assigned User (Salesforce Task).

7. Branch NO (No-Show):

• Action: Send Email 3: "Sorry We Missed You / On-Demand Link."

• Action: Add to Nurture Program "General Webinars."
  
  

3.4 Suppression Logic

To prevent communication fatigue, the integration should manage suppression lists automatically.

• Configuration: Create a Static List named Event_Cancelled.

• Logic: If a user cancels their registration in InEvent, the integration should (via API) add them to the Event_Cancelled list and remove them from the Event_Registrants list.

4.0 Scoring & Grading Configuration

Pardot divides lead qualification into two distinct axes: Scoring (Implied Interest based on activity) and Grading (Explicit Fit based on demographics). The InEvent integration enriches both.

4.1 Scoring Configuration (Behavioral)

InEvent activities must be translated into Pardot Score increments. Because the native API does not typically allow arbitrary writing to the distinct "Score" integer field directly (to prevent data corruption), we utilize Automation Rules triggered by the integration's signals.

Method A: Page Actions (Virtual Events)

• Mechanism: If the event is virtual, InEvent pages (Lobby, Auditorium, Booths) can be tagged with Pardot Tracking Code.

• Configuration: In Pardot > Automation > Page Actions.

• Page URL: https://event.inevent.com/my-event/auditorium* (Wildcard).

• Score Change: +10 points.

• Priority Page: Check this to flag the activity in Salesforce Lead History.

• Result: Every time a Prospect navigates to a session, their score increases automatically based on native web tracking.

Method B: Automation Rules (Hybrid/Physical Events)

For physical check-ins, there is no "Page View." We rely on the List Membership change or Custom Field update synced by the connector.

• Rule Name: Event Scoring - Checked In.

• Rules:

• Prospect List :: is member of :: Event_Name_CheckIn.

• Actions:

• Adjust Prospect Score :: by :: +50.

• Apply Tags :: Event-Attended.

• Repeat Rule: Enable "Repeat Rule" only if you want to score for multiple days (e.g., +50 for Day 1, +50 for Day 2). Ensure the "Days before eligible to repeat" setting matches the event duration to prevent loop scoring.
  
  

4.2 Grading Configuration (Profile Fit)

Grading automates the qualification of leads based on the data captured during the InEvent registration process.

Scenario: A Prospect registers with the Job Title "Chief Marketing Officer."

1. Sync: InEvent writes "Chief Marketing Officer" to the Pardot Job Title field.

2. Profile: The Prospect is assigned to the "Default Profile" (or a specific Executive Profile).

3. Automation Rule:

• Rule Name: Grading - C-Level Execs.

• Rules: Prospect Job Title :: contains :: Chief OR CMO OR CEO.

• Actions: Change Profile Criteria :: Default Profile :: Job Title :: Matches.

4. Result: The Prospect's Grade increases (e.g., from D to B+), signalling to the Sales team that this attendee matches the Ideal Customer Profile (ICP), regardless of their score.

6.0 Implementation & Setup (Standard Operating Procedure)

This Standard Operating Procedure (SOP) outlines the execution steps for a Salesforce Admin to configure the connection.

Prerequisites:

• Pardot Administrator Access.

• Salesforce System Administrator Access.

• InEvent Organization Admin Access.

• Pardot Business Unit ID (for v5 API).

Step 1: Install and Authenticate

1. Navigate to InEvent > Account > Integrations.

2. Select Salesforce / Pardot.

3. Choose Connector Type:

• Select "Salesforce" if you rely on the Salesforce Connector for Pardot (Recommended).

• Select "Pardot Native" only if connecting directly to Pardot standalone.

4. Click Link Account. You will be redirected to the Salesforce OAuth login screen.

5. Log in with a dedicated Integration User (Best Practice: Do not use a personal user account to prevent disconnection if that employee leaves).

6. Grant "Allow Access" permissions.

Step 2: Business Unit Configuration (Pardot Native Only)

1. If using the Direct Pardot API, you must specify the Business Unit ID.

2. In Salesforce, navigate to Pardot Account Setup.

3. Copy the Business Unit ID (starts with 0Uv...).

4. Paste this ID into the InEvent Integration settings field.

Step 3: Configure Campaign Alignment

1. In InEvent, navigate to the specific Event level.

2. Go to Integrations > Settings.

3. Locate Campaign Linking.

4. Select the Salesforce/Pardot Campaign designated for this event.

5. Validation: Ensure the Campaign is "Active" in Salesforce, otherwise, the API call to add members will fail.

Step 4: Map Fields

1. In the InEvent Integration tab, open Field Mapping.

2. Map Standard Fields first (Email, First Name, Last Name, Company).

3. Map Custom Fields (Registration Questions). Ensure the API Names in Pardot exactly match the selection in InEvent.

4. Enable "Update Empty Fields Only" if you wish to preserve existing CRM data, or "Overwrite" if InEvent should be the source of truth for this event.

Step 5: Define Triggers and Lists

1. Configure the List Logic.

• "Add Registrants to List:" Select the Pardot Static List (e.g., Event_Registrants).

• "Add Attendees to List:" Select the Pardot Static List (e.g., Event_Attendees).

• "Add Absentees to List:" Select the Pardot Static List (e.g., Event_NoShows).

2. Save the configuration.

Step 6: Test Synchronization (Dry Run)

1. Open the InEvent Registration Page.

2. Register a Test Prospect (e.g., testing.user+01@domain.com).

3. Wait 2–5 minutes.

4. Check Pardot:

• Search for the Prospect.

• Verify the record exists.

• Verify they are a member of the mapped Static List.

• Verify Custom Fields are populated.

5. Simulate Attendance: In InEvent, manually mark the user as "Checked In."

6. Wait 5–10 minutes.

7. Check Pardot: Verify the Prospect is now in the "Attendee" list and/or their Campaign Member Status in Salesforce has updated to "Attended."

7.0 Technical FAQ

1. What is the sync latency?

A:

• Form Handlers (Web): Real-time. When a form is submitted, the data is posted immediately.

• Direct API (Metadata): Near real-time (1-5 minutes).

• Salesforce Connector: If syncing via Salesforce, the latency is determined by the Salesforce-Pardot connector polling interval, which is typically 2 to 10 minutes depending on the connector queue load.

• Activity/Engagement History: Non-critical metadata may be batched and synced every 10-15 minutes.
  
  

2. How do we handle Form Handlers if we don't use the API?

A: If your security policy restricts API access, you can use Pardot Form Handlers.

1. Create a Form Handler in Pardot.

2. Map the fields (Email, FName, LName).

3. Copy the Endpoint URL (http://go.pardot.com/l/123/2023-01-01/xyz).

4. In InEvent, configure the "Custom Integration" or "Webhook" to POST the registration payload to this Endpoint URL.

5. Critical: Form Handlers require a "Success Location" and "Error Location." Ensure InEvent is configured to handle the 302 Redirect response from Pardot, or use a silent post method (server-side submission) to avoid redirecting the user's browser away from the event lobby.

3. Does the integration support Salesforce Custom Objects?

A: Yes, but primarily via the Salesforce Connector pathway. InEvent writes the data to a Salesforce Custom Object (e.g., InEvent_Session_Log__c). You must then configure Custom Object Sync in Pardot Settings.

1. In Pardot, go to Admin > Custom Objects.

2. Add the Custom Object.

3. This allows you to run Automation Rules in Pardot based on the Custom Object data (e.g., InEvent_Session_Log__c :: Duration :: greater than :: 30).

4. How are "Hard Bounces" handled?

A: Sync is bi-directional regarding email deliverability status in specific configurations.

• Pardot to InEvent: If a Prospect is marked as "Hard Bounced" or "Do Not Email" in Pardot, the integration can flag this user in InEvent to suppress operational emails, though this usually requires a custom webhook setup.

• InEvent to Pardot: If an invite sent from InEvent bounces, InEvent does not natively write to the Pardot "Hard Bounce" field (which is system protected). It will, however, update a custom field (e.g., Event_Email_Status = Bounced) which you can use to trigger an Automation Rule to mark the Prospect as "Do Not Email."

5. What happens if the API Limit is reached?

A: Pardot/Salesforce imposes daily API limits. The InEvent connector utilizes bulk endpoints where possible to minimize calls. If the limit is reached, the sync will pause and queue the requests. It will retry automatically once the API quota resets (rolling 24-hour window). Critical errors (Authentication failures) will trigger an alert to the Admin email address on file in the InEvent integration settings.

6. Can we sync to multiple Pardot Business Units (PBUs)?

A: The native connector typically links to a single Business Unit associated with the authenticated user. If you are operating in an Enterprise environment with multiple PBUs (e.g., distinct geos), you should utilize the Salesforce Connector pathway.

• Logic: InEvent syncs to Salesforce Lead/Contact.

• Routing: Salesforce "Marketing Data Sharing" (MDS) rules determine which PBU the lead syncs to based on criteria (e.g., If Region = EMEA, sync to EMEA PBU). This delegates the routing logic to Salesforce, which is the architectural best practice.

7. How do we handle GDPR "Right to be Forgotten"?

A: Deletion is not automatically cascaded to prevent accidental data loss.

• Process: If a user requests deletion in InEvent, an email alert can be sent to the Data Privacy Officer. The DPO must manually delete the Prospect in Pardot/Salesforce.

• Reverse: If a Prospect is deleted in Pardot, they are NOT automatically deleted in InEvent (they may still need access to the event for legal or financial receipt reasons). Synchronization will simply stop for that record.

Appendix A: Error Code Reference

Appendix B: Security & Compliance

The integration adheres to OAuth 2.0 standards. InEvent does not store Salesforce/Pardot passwords. Access tokens are encrypted at rest using AES-256 encryption. All data transmission occurs over HTTPS (TLS 1.2+). The application is subject to periodic penetration testing and security audits.