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.
The final automation sequence, mapped using Elements.cloud
Note that we could have created a chatter post within the Apex Trigger itself and avoided step 4. Savvy developers can certainly go this route, but the advantage here is that all the logic around whether or not to post to Chatter and the contents of that post reside in admin-friendly Flow.
1. Create Task
I decided to use Tasks created by the B2BMA user as my trigger for posting a notification to a chatter group in Salesforce. Note that Pardot cannot assign Tasks to Queues, and furthermore, assigning a Task to a Queue in Salesforce will NOT notify Queue members that a new Task was created although this works for other objects. In other works, Tasks need to be treated carefully which is one of the reasons why a chatter notification to alert a group of users makes sense.
2. Flow #1 Creates Platform Event
You’ll first need to define a Platform Event which is very easy, just like creating a custom object. Setup > Platform Events > New Platform Event. I named the event ‘New Pardot Task’ and added a text field to hold the Id of the Task. I used ‘Record Id’ although ‘Task Id’ is probably more appropriate in retrospect.
Creating the actual event itself is handled by Flow. I have set it to trigger only on Tasks created by the B2BMA user. Here’s how that Flow looks:
The Flow that creates the Platform Event. Simple!
The only thing I need to add to the Platform Event is the Id of the Task record so I can find it later.
3. Listen for the Platform Event with a Trigger
This is where the magic takes place.
I’m using a Trigger to listen for a Platform Event to be created, and then update the Task that triggered it with a field change—I chose to use a checkbox called ‘Create Chatter Post’. That field change can then be referenced in Flow to do anything you want, but the key is that the subsequent Flow will run as the Automated Process User.
*A note about unit testing: Flow #1 must be active for it to work! The test relies on the Flow creating the Platform Event. Also note that it runs in the context of the B2BMA user as otherwise, that Flow wouldn’t fire due to the entry criteria.
4. Flow #2 Posts to Chatter
The final step is setting up the second Flow which should trigger when the custom field updated by the Platform Event Trigger is changed. I’ve chosen to create a Chatter Group called ‘Pardot Notifications’ so that it’s easy to add/remove users as well as let them decide how to receive notifications.
Note that I am also confirming the existence of a WhoId on the Task so that the chatter post won’t fail if Pardot happens to create a Task not related to a Lead or a Contact.
Another simple flow, this one handles the chatter post
The Group ‘Pardot Notifications’ receives a chatter post from the Automated Process User
Wrap Up
For many organizations the complexity of this solution is overkill. That said, it’s an interesting use case for Platform Events and was a fun technical challenge to solve.