Publish Gate Guide
The 15 minutes between "event over" and "sales has the leads." The Publish Gate is where you review attendance, filter out the noise, and push clean data to Salesforce—before your team even gets to the airport.
Why the Publish Gate Exists
Not every check-in should trigger a sales follow-up. The intern who used their Gmail? The competitor who snuck in? The attendee who registered with a typo'd email? You need a chance to review before that data hits your CRM and potentially wastes sales time.
The Publish Gate gives you that control.
- See everyone who checked in
- Apply filters (we call them guardrails)
- Choose who gets published
- Push to Salesforce with one click
- Undo if you make a mistake
Getting to the Publish Dashboard
- Open pass.eventkarma.ai
- Navigate to Publish in the menu
- Select your event (if not pre-selected)
You'll see a dashboard with stats at the top and an attendee list below.
Understanding the Dashboard
The Numbers That Matter
| Metric | What It Tells You |
|---|---|
| Checked In | Total scans recorded during the event |
| Ready to Publish | Passes your guardrails, ready for Salesforce |
| Already Published | Already pushed to Salesforce (previous publishes) |
| Would MQL | Estimate of leads that would route to sales |
This estimates how many leads would trigger your MQL routing based on your Salesforce rules. It's not exact (we don't know your routing logic), but it gives you a sense of the sales impact.
The Attendee List
Each row shows:
- Name and company — who they are
- Email — for verification
- Check-in time — when they scanned
- Current status — what Salesforce shows now
- Guardrail icons — pass/fail indicators
Look for red X icons—those are people who failed a guardrail and might need manual review.
Guardrails: Your Safety Net
Guardrails are filters that prevent certain attendees from being published automatically. They don't delete anyone—they just flag them for your review.
Available Guardrails
| Guardrail | What It Does | Why You'd Use It |
|---|---|---|
| Business Email | Flags Gmail, Yahoo, Hotmail, etc. | Prevent personal emails from triggering MQL routing |
| Session Count | Requires minimum sessions attended | For multi-track events where attendance depth matters |
| Allowed Domains | Only specific company domains | For account-based events with target companies |
Setting Up Guardrails
- Go to your event's Check-in Settings in the admin portal
- Enable the guardrails you want
- Configure thresholds (e.g., "minimum 2 sessions")
- Save
Guardrails apply at publish time, so you can adjust them after the event.
Enable this for almost every event. It catches the personal Gmail registrations that would otherwise route to sales and waste their time. Those attendees still get checked in—they just don't automatically trigger follow-up.
Publishing Options
What Happens When You Publish
Publishing updates the Campaign Member Status in Salesforce. Depending on your Salesforce configuration, this might:
- Update the status to "Checked-In" or "Attended"
- Set
HasRespondedto true - Trigger lead routing rules
- Add to nurture campaigns
- Update lead scores
Publish Modes
| Option | Salesforce Status | Typical Trigger |
|---|---|---|
| Checked-In | Sets status to "Checked-In" | Usually does NOT trigger MQL routing |
| Attended | Sets status to "Attended" | Usually DOES trigger lead routing |
Before publishing, understand what "Attended" status triggers in your org. If it routes leads to sales, be thoughtful about who gets that status. Use "Checked-In" if you want manual control over MQL timing.
Selective Publishing
Want to be picky? You can:
- Review the attendee list
- Uncheck anyone you don't want to publish
- Click Publish Selected
Only the checked attendees get pushed to Salesforce.
Bulk Publishing
Ready to push everyone who passed guardrails? Click Publish All.
Promoting to MQL Status (New!)
Want attendees to trigger lead scoring after they've already checked in? The new "Promote Checked-In Attendees" feature lets you update attendees from "Checked-In" to a status that triggers MQL routing.
When to Use This
You might use two-stage publishing:
- During the event: Publish as "Checked-In" (no MQL trigger)
- After event review: Promote to "Responded - Attended" (triggers MQL)
This gives your MOPs team time to:
- Review attendee quality
- Check for competitors/disqualified leads
- Verify survey responses
- Coordinate with sales on timing
How to Promote Attendees
- Go to your event's Check-in tab
- Scroll to Promote Checked-In Attendees section
- See how many attendees are ready to promote
- Click Update Status
- Choose your target status:
- Responded - Attended (recommended - triggers MQL in most orgs)
- Attended (standard status)
- Responded (generic)
- Custom (enter your org's specific status)
- Review the warning about lead routing
- Click Update All Checked-In
Target Status Options
| Status | Typical Result | When to Use |
|---|---|---|
| Responded - Attended | Triggers MQL scoring | Most common choice |
| Attended | Standard attendance flag | If your org routes on "Attended" |
| Responded | Generic response status | For conservative orgs |
| Custom | Your org's status | If you have custom picklist values |
Before promoting, confirm with your Salesforce admin which status triggers MQL routing in your org. Different organizations have different configurations.
Promotion vs Publishing
| Action | What It Does | Sales Impact |
|---|---|---|
| Publish (Checked-In) | Marks attendance in Salesforce | Usually no routing |
| Publish (Attended) | Marks + triggers routing | Immediate |
| Promote | Changes existing status | You control timing |
The promote feature is perfect when you want to:
- Publish attendance quickly (so data is in Salesforce)
- Wait before routing to sales (give yourself time to review)
- Trigger MQL scoring when you're ready
The Publishing Flow
Right After the Event (Recommended)
- Open the Publish dashboard
- Review the stats—does the number look right?
- Scroll through flagged attendees (red icons)
- Decide: keep or uncheck them
- Click Publish All or Publish Selected
- Verify in Salesforce (spot-check 2-3 records)
The Next Morning (Also Fine)
If you're exhausted after the event, publishing the next morning is totally fine. The data doesn't expire. Just don't wait more than 24-48 hours—your sales team's follow-up becomes less effective as time passes.
If you have 10 minutes before heading to dinner or the airport, do a quick publish. Sales will have the leads before you land, and you'll look like a hero.
After You Publish
What Happens in Salesforce
For each published attendee:
- Campaign Member Status updates to your selected status
- HasResponded flag sets to
true - If configured, an Activity is logged
- Your lead routing rules may trigger
Verification Checklist
After publishing, spot-check in Salesforce:
- Open the Campaign
- Check 2-3 Campaign Members you recognize
- Verify their status updated correctly
- Confirm any notes appear as Tasks
If something looks wrong, you can undo (see below).
The Undo Feature
Made a mistake? Published someone who shouldn't have been? We've got you.
How to Undo
- Go to Publish History in the Publish dashboard
- Find the publish operation you want to reverse
- Click Undo
- Confirm
The Campaign Member statuses revert to their previous values.
Undo reverts Salesforce statuses, but it can't:
- Un-route leads that already entered sales queues
- Delete Tasks that were created
- Reverse scoring changes in your marketing automation
The sooner you catch a mistake, the easier it is to fix. That's why spot-checking matters.
Best Practices
Timing
| When | What to Do |
|---|---|
| During event | Optional: publish periodically for real-time sales visibility |
| Right after | Recommended: do your main publish while it's fresh |
| Within 24 hours | Must-do: don't let data get stale |
| Before next event | Verify: ensure all data from previous events is published |
Quality Over Speed
It's better to take 5 extra minutes reviewing the list than to clean up routing mistakes later. Use guardrails, eyeball the flagged attendees, and publish with confidence.
Communication with Sales
When you publish, consider a quick Slack message:
"Just published [X] attendees from [Event Name]. Notes from conversations are attached to Contact records. Hot leads flagged. Happy hunting!"
Your sales team will appreciate the heads-up—and they'll know to check their queue.
Troubleshooting
Publish button is grayed out
Cause: No attendees selected, or everyone is already published. Fix: Check your selection. If everyone shows "Already Published," there's nothing new to push.
Attendee shows "Failed" but should publish
Cause: They failed a guardrail. Fix: Either adjust your guardrail settings, or manually check them back in the list to include them.
Status didn't update in Salesforce
Cause: Sync delay or permission issue. Fix: Wait 30 seconds and refresh Salesforce. If still not updated, check the sync logs in Settings > Integrations.
Wrong status was set
Cause: You published with the wrong mode selected. Fix: Use Undo to revert, then republish with the correct status.
FAQ
Q: Can I publish the same person twice? A: Yes, but it just updates their status again. No duplicate records are created.
Q: What if someone checked in twice (duplicate scans)? A: Event Karma handles this. They appear once in the publish list.
Q: Can I publish to a different Campaign? A: No—check-ins are tied to a specific Campaign. Each event publishes to its linked Campaign.
Q: How do I know if MQL routing triggered? A: Check your Salesforce lead routing queues, or ask your Salesforce admin how "Attended" status affects routing.
Q: What if I don't want anything to trigger automatically? A: Use "Checked-In" status instead of "Attended." Then manually update to "Attended" in Salesforce for the leads you want to route.
Next Steps
After publishing:
- Verify in Salesforce — Spot-check a few records
- Notify your team — Let sales know leads are ready
- Review event performance — Check attendance vs. registration rate
- Prepare for next event — What worked? What to improve?
Need help with email templates? Check out the Email Integration Guide for platform-specific setup.