Relate a Campaign to an Event Registration

[jimhubert]

Use Case: Many organizations send event email invitations (through tools such as Pardot or Marketing Cloud) that are associated with a Campaign, and they need to track the effectiveness of the Campaign by knowing how many people registered for the event based on that email. By having a Campaign associated with these Event Registrations analytics such as Campaign Hierarchy/Campaign Influence/Attribution are also possible.

Overview of proposed solution:

• Define Campaign value on the Summit Events object
• Display the Campaign value from the Summit Events object on the Summit Events Instance record, and provide ability to add an "override" Campaign value if the marketer desires to have separate Campaign ID's for each instance
• Build automation logic (probably with a Flow that is in a package or metadata that outside the core package for licensing and dependency reasons) that syncs values of Campaign values on the Summit Events Instance record with the Summit Events Registration record.
• Could also build automation that updates Campaign Member records (including status value) when the Summit Events Registration record has a Campaign value added. (field that defines the value that indicates the person has "Registered" on the Campaign Member record)

Object parallels:

• Summit Events Instance paired with Campaign Summit Events Registration paired with Campaign Member
  • Should status values on these two objects be the same/synced?

FYI @brandelle-unkrich

September 24 solution, that we decided in February 2021 sprint only solved the "invite" use case and had problems with URL value passing, so we are not doing this: On September 24 @jimhubert spoke with @tcdahlberg about this use case. Thad identified a solution to this issue that he thought would be fairly simple to implement. This solution involve adding a Campaign lookup field to the Summit Events Registration object, writing documentation on how to add a Campaign ID to the event registration URL sent in emails, and then adding a section of code to populate the Campaign ID field from the event registration URL

[ustkgh]

Some notes from the Slack thread, @jimhubert:

Katie DECIDED: We can ignore the need to help people automate against Event Registration create/update occurrences where the Event Registration is not pointed to a Contact, since they couldn't become a Campaign Member anyway

Katie DECIDED: Whatever we do with respect to Campaign & Campaign Member, we need to make sure that Summit Events proper doesn't get any hard-coded references to the existence of such objects embedded into it (licensing issues).

Katie Instead, we would want to make a secondary add-on package.

Katie Discussed: We don't necessarily need to do "magic 18-digit text fields passed in by magic URL" rather than "Campaign" or "Campaign Member" lookup fields on Event/EventInstance/EventRegistration (whichever level we pick) as a way of wiring up a C/CM object to an E/EI/ER record ... we just need to make sure that those fields are in our "auxiliary package," not the main "Summit Events."

Katie Discussed: Yes, this is worth doing, even though Pardot can see custom objects like Event Registration (and Event / Instance details can be surfaced to ER via formula fields), because maybe people are mailing with ConstantContact, maybe with MailChimp, etc. etc. etc.

Katie Discussed: Maybe we do some sort of "override" structure where the Campaign lookup can be done at Event, or at Instance if you prefer, or at Registration if you prefer, etc.

Katie DECIDED: Event Instance is definitely a great place to add a Lookup field to Campaign, even if there are also other places. (Katie's thoughts: if we make one thing today & tomorrow, maybe we learn to make an auxiliary package that comes w/ a single custom field of just a "hello world.") (David Reed says to do this Trailhead and to play w/ 1GP MP's, 2GP MP's, & 2GP UP's, and to ignore 1GP UP's & 2GP OrgP's. He favors managed packages "w/ well-defined configuration interfaces, preferably either through Custom Metadata or customized UI." He said unlocked 2GP's can be a reasonable way to deliver certain example metadata. They can even potentially go into a "secondary MetaDeploy installer plan" that's only able to install into sandboxes, not production orgs, alongside Summit Event's main installer plan.)

Katie DECIDED: We're scrapping the "magic URL" idea unless we get stuck and need to reintroduce it.

[JohnnyMac99]

Summary of Proposed Solution as I documented it during Day 1 Sprint:

This solution will be done outside the main package to eliminate any dependence on the Campaign object which would introduce licensing and community issues.

The total solution should include:

Documentation:

• Prerequisites

1. Must be using Contact Matching. Orphan registrations are not supported as Campaign Members require a Contact ID
2. There is no support for Leads in Summit Events so only Contacts will be used

• How to implement the add-on functionality

1. This may include manually adding the Campaign ID field to Event Instance and optionally to Event
2. Enabling the Flow(s) as required

• Flows

1. Flow 1: Summit Events Instance-Record Triggered Flow-When a Record Is Created * If Event.Campaign ID <> Null, default the Campaign ID
2. Flow 2: Summit Events Registration-Record Triggered Flow-When a Record Is Created or Updated * Upon Save of Registration, create/update Campaign Member Record * Lots of conditions: * Does campaign ID exist * Does Contat exists as Campaign Member * Does Campaign member Status exist for Resgitsration.Status * Full documentation for flow still to be developed.

[rdblake21]

@walt0019 and @rdblake21 are going to tackle this has create a 2GP Unlocked package to include the elements above. This will be shared when it becomes available and referenced in the documentation.

This is a request from St. Thomas, so we're going to build it out and testing as a dependency post SEA Install.

[rdblake21]

Created the POC in a Flow and it functions as follows:

• Campaign can be on Event Record

Event Registration will relate to Campaign If a Contact record, Campaign Member will be created

• Campaign Override on Instance

Event Registration will relate to the Override if it exists If a Contact record, will relate to this campaign

• If there is a Campaign for the invitation, that Campaign can relate to the Event or Instance. Should an invitee register for the event and the Contact Matches, it'll update the existing Campaign Member from Sent to Responded.

I have this in a forked branch as we don't want the flow in the main package - https://github.com/rdblake21/Summit-Events-App/tree/CampaignPOC

Still cleaning up the branch as it pulled down ALL Campaign and Campaign Member fields, which I don't want.

[rdblake21]

This will be an option install during the MetaDeploy process.

[rdblake21]

Testing as an unlocked package - https://github.com/rdblake21/Summit-Events-App-Campaign-Recipe

[rdblake21]

Completed the documentation and tested the recipe. This is an unlocked packaged so users can install and update to meet their business requirements. Should follow everything mentioned above.

https://sfdo-community-sprints.github.io/summit-events-app-documentation/docs/Recipes/associate-campaigns/