Caveat:
Pardot was recently renamed ‘Marketing Cloud Account Engagement’ but that’s a mouthful and hard to search, so I use the name ‘Pardot’ in this post.
Second Caveat:
This is a technical article highlighting an interesting solution we found to a moderately common pain point for organizations using Pardot.
Pursuing the least technical solution is, in our experience, more frequently the correct call. It reduces the chance of errors and time to build/troubleshoot. In this case, there are several other options for setting up notifications from Pardot that are less technically complicated (Slack connector, groups, Pardot email notifications…). That said, sometimes a technical solution is what’s required and the goal of this post is to document how to create Chatter posts using the standard Pardot connector when all other means won’t cut it.
The Trouble With Chatter
Someone takes action in Pardot (form submission, hits a scoring threshold): time to notify users.
Although there are several ways to handle this, one option that seems obvious—a chatter post—doesn’t appear to be an option within Pardot automation rules, completion actions, or engagement studio. This is a bummer because posting to a chatter group is a great way to easily send notifications out to a group of users with a clickable link to that record in Salesforce.
For savvy admins, if you dig a little deeper and try to set up a Flow to create a chatter post triggered by a Task or update made by the B2BMA Integration User, you’d run into a strange error:
“Only internal users can set visibility to InternalUsers”
This means the B2BMA Integration User—which is the default connector user between Salesforce and Pardot—doesn’t support posts to Chatter, period. Even if you set up separate automation (Flow) it still runs in the context of the B2BMA user and thus triggers an error.
Is it possible to force Salesforce to post to chatter as another user, in a mostly-declarative way?
Platform Events to the Rescue
Platform Events are essentially like records whose sole purpose is to trigger other things. There is plenty of developer documentation if you want to learn more about them, but for our purposes, the key thing to realize is that Apex Triggers on Platform Events will run as the Automated Process User, NOT as the user who created the event.
This means that a Platform Event triggering a chatter post will post as the Automated Process User, which does not have the same technical limitations as the B2BMA Integration User.
Solution Design
This architecture was designed to be as admin-friendly as possible, and require the bare minimum Apex to build and maintain. We have limited the scope of Apex to the one thing it needs to do: change the user context in which automation runs. Although Flows can be triggered by Platform Events, they do not change the context of the running user! The first iteration simply used Flow to create a Platform Event, and another Flow to listen for it—this will not suffice. It’s unclear whether this difference was an intentional decision made by Salesforce or not, but it’s key to this whole operation.
