[Note: This use case/solution can be implemented in both Classic and Lightning Experience.]

While process builder has the ability to post to chatter, its capabilities are a bit simplistic. In process builder, you can post to a user, a chatter group or the record. There is no ability to @mention multiple users dynamically. Users can only be @mentioned if they are associated users to the record via the merge user lookup reference. There is no ability to reference custom labels or use formulas in the chatter post. So, the system administrator is constrained to “hardcoding” @mentions in the process builder. Now, hardcoding @mentions should be considered a “no-no” especially, in the situation of individual users as we know users come and go, or perhaps more need to be added in the future, with every change in the @mentions, that is another version of the process builder that needs to be created. What a maintenance nightmare! You should be able to maintain the @mentions outside of process builder.

When process builder reaches its limitations, that’s when we call on process builder’s older brother, flow.

Here are a few lessons learned from implementing this use case:

• Learn how to invoke flow from process builder.
• Perform lookups in flow to avoid hardcoding information that is subject to change over time, which will remove the need to deploy a new version of flow every time the information needs to change.
• Build componentized flows that can be leveraged in multiple processes, rather than builder the same, slightly different flows over and over, which would increase maintenance over time.
• Provide descriptions, where provided, in Salesforce. This may be tedious step, I know, but your future self will thank you when you are trying to remember what you configured or assist other/future admins when troubleshooting or enhancing what was built. This includes variables, the purpose of a flow, what each flow element does, etc.

Business Use Case:  Addison Dogster is the system administrator at Universal Containers. Steven Moon is the Director of Operations. Every time an opportunity is closed won, he would like a chatter post to be posted and specific people @mentioned. He does not want the post to be addressed to a chatter group as not everyone chatter notifications for the group is set to the user’s preference and he wants everyone to be notified once posted. Steven also noted those to get the chatter post and the message itself is subject to change over time and he manages the list of those who should be notified.

Solution: Being the #AwesomeAdmin that Addison is, she was able to solution this declaratively using process builder and flow. To avoid “hardcoding” @mention references or the chatter message and the need to clone, update and deploy new versions of the process or flow with each change, Addison created a custom metadata type to hold the chatter message and a public group to manage the @mention list. Lastly, Addison caught wind that there may be other similar use cases where the business would like to automate chatter posts as well. So, rather than build the same solution, with some tweaks, over and over, she decided to genericized her solution for re-use.

View image full screen

Quick Steps: 

1. Create a public group to manage the users who will be @mentioned in the chatter post. In Classic, you will find this under Manage Users | Public Groups. Lightning Experience, you will find this under Users | Public Groups.

2. Create a custom metadata type manage the chatter message. In Classic, you will find this under Develop | Custom Metadata Types. Lightning Experience, you will find this under Custom Code | Custom Metadata Types.

Create a new custom text field called Message Text:

Click on Manage Messages button. Then click the New button to create a record to store the chatter message.

3. Let’s create a visual workflow to handle the person account creation and associate the person account to the case, which will be invoked from process builder.

In Classic, you will find this under Create | Workflow & Approvals | Flows. Lightning Experience, you will find this under Platform Tools | Process Automation | Flows.

A. First, let’s set up the resources that we will use in this flow.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this record create and resources are used for.

This text variable will store the @mention user that will be referenced in the chatter post.

This text variable stores the chatter message that is pulled from the custom metadata type record created in Step 2.

This text variable stores the message custom metadata type label passed from process builder to flow. The Input/Output Type needs to be Input Only so you can set the variable in process builder.

This text variable stores the API name of the public group that is passed from process builder to flow. The Input/Output Type needs to be Input Only so you can set the variable in process builder.

This is a text variable that stores the groupID.

This stores the recordID that is passed from process builder. The Input/Output Type needs to be Input Only so you can set the variable in process builder.

This is a sObject collection variable for the GroupMember object that stores the members of the public group.

This is a sObject variable that will hold information about the single group member on the GroupMember object.

This is a text template that @mentions the user in the public group.

This is a text template that references the users who are @mentioned from the public group and the chatter message.

B. To avoid hardcoding the public group ID in the flow, we will perform a Record Lookup using the API name passed in the variable varPublicGroupAPIName in process builder. Store the Id in the variable varPublicGroupID.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this record create and resources are used for.

C. Now, let’s create the Fast Lookup flow element to lookup the users in the public group where the GroupID equals the variable varPublicGroupID in the Group Member object. We will store the records found in the sObject collection variable sObjCollGroupMembers, saving the UserOrGroupId field.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this record create and resources are used for.

D. Let’s now use a Decision flow element to determine whether group members were found. The Members Found outcome is determined whether the sObjCollGroupMembers variable collection is null false, which means the collection has a value.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this record create and resources are used for.

E. Now, we will perform a Loop with the records in the sObjCollGroupMembers and  assign the value to a loop sObject variable varSingleGroupMember.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this record create and resources are used for.

F. Let’s configure an Assignment flow element. We will add the text template tt_GroupMemberUserID to the variable varAtMentionUser.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this record create and resources are used for.

G. Next, we will use a Record Lookup to pull the chatter message that is stored in the Messages custom metadata type created in Step 2 by its MasterLabel that was passed in the variable varChatterMessageMasterLabel from process builder. Then, flow will take the Message_Text field and store it in the variable varChatterMessage.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this record create and resources are used for.

H. In the last flow element, we will use the Post to Chatter flow element.

Configure the inputs:

• Target name or ID: {!varRecordID}
• Message: {!ChatterPostTextTemplate}.

Click on outputs and the trash can to delete the output value.

See the animated gif for configuration steps.

View image full screen

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this record create and resources are used for.

I. Add the subflow Send Flow Fault Email. For instructions on how to create this, go to Step 2 of blog post: Maximize Maintainability With Process Builder and Componentized Visual Workflow.

J. Set your flow starting point. And connect the flow elements and the fault connectors to match the below…

K. Save as and provide the following properties.

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

L. Click the “Close” button.

M. On the flows screen, activate the flow.

4. Lastly, we need to create the process builder that will execute the process when an opportunity is closed won.

Create a process builder (Create | Workflows & Approvals | Process Builder in Salesforce Classic or Process Automation | Process Builder in Lightning Experience).

A. Set the process builder properties. We will call this process “Take Action on New/Existing Opportunities”, provide it a description and select this process to start when “A record changes.”

View image full screen

Best practice tips: Don’t forget to provide a description so you and other/future admins know what this process is used for.

B. We need to select “Opportunity” as the object and we want our process to run when a record is created or edited, click the “Save” button.

C. We need to specify the criteria node that needs to be met to then execute the flow. Let’s call out criteria “Opp is Closed Won” which will execute when “conditions are met” where the opportunity stage equals Closed Won and the opportunity stage is changed.

D. Next, we want to set the immediate action to invoke the flow created in Step 3.

Set the immediate action to the below.

• Action Type: Flows
• Action Name: InvokeFlow
• Flow: Send Chatter Post to Members of a Public Group
• Set the flow variables to the following:
  • varRecordID Reference [Opportunity].Id
  • varChatterMessageMasterLabel String MessageTestClosedWon [Note: This is the message custom metadata record]
  • varPublicGroupAPIName String ChatterGroup1 [Note: This is the API name for the public group you want to @mention]

You can reuse the same flow in Step 3 in other scenarios by using the same variables above. For the varRecordID, you would reference the Id of the record that started the process.

Save the immediate action.

The end result looks like this…

E. Click on the “Activate” button to activate the process

Congrats, you made it to the end! You’ve implemented a process to automatically create a post that at mentions several users when an opportunity is closed won.

Now, before you deploy the changes to Production, don’t forget to test your configuration changes.

1. Submit a new email to case.
2. Verify that a new person account is created with the email address as the person account’s last name and email address.
3. Verify that the person account is associated to the case.

Deployment Notes/Tips:

• The process builder, flow and custom label can be deployed to Production in a change set (or can be deployed using a tool such as Dreamfactory’s Snapshot).
• You will find the process builder and flow component in a change set under the Flow Definition component type.
• Update the custom label with the ID of your person account record type ID.
• Activate process builder and flow as they are deployed as inactive in Production.