Advanced Automation with Flows and Custom Metadata Types Webinar Recap

In the Salesforce Admins Webinar: “Advanced Automation with Flows and Custom Metadata Types,” I described what custom metadata types were, their benefits, and why #AwesomeAdmins should use them in their configuration. I also presented a real-life use case for automatically assigning and removing users to a public group based on profile, and walked through the advanced configuration using custom metadata types, process and flow.

Take a look at the recording:

Webinar Summary:

Declarative Automation Tools are Awesome!

Lightning Flow is the product that brings #AwesomeAdmins the ability to declaratively automate processes via Process Builder and Cloud Flow Designer. Process Builder is used to build processes and Cloud Flow Designer to build flows.
Some of the Flow use cases include the following:

• Business processes requiring input from internal or community users or provides a guided wizard to users
• Adding automation directly on your record pages
• Setting up automated tasks and processes
• Building once, re-using it many times

Custom Metadata Types are Awesome Too!

Many of you have installed apps from the AppExchange. Chances are, the ISV is using custom metadata types to customize, package and deploy their app to customers. Developers reference custom metadata types in code to maintain their app data.

If you’ve ever created a custom object, then you already know how to create a custom metadata type. They look very similar, but they do have differences.

Some of the use cases for custom metadata types include the ability to reference and manage app/org data referenced in multiple components in one place. They also have the ability to manage information such as IDs, instructional text that is subject to change outside of code or flow, store information of similar structure, or store mappings or environment variables.

Now, Admins can use custom metadata types in configuration items, such as flow, validation rules (new as of Summer ’18) and coming in Winter ’19, formulas.

A Real Life Use Case: Automate Public Group Assignments by Profile

In this webinar, I walked Admins through a real-life use case where I had to automate the assignment/remove of users from a public group based on the user’s profile. Public Groups are often used as a security means for granting access to things such as reports, dashboards, queues, etc. If a user is not part of a group that they should be, they cannot access or perform tasks needed for their jobs. And vice versa: if a user is still part of a group that they should not be, this can cause an even greater security issue when a user still has access to restricted data that they should not.

Here’s the process that I automated using declarative solutions, public groups, Process Builder, Cloud Flow Designer, custom metadata types and a user object custom field to store the profile name.

The #AwesomeAdmin Declarative Solution

• First, I created three public groups to assign the users to.
• I created two custom metadata types:
  • (1) holds the Salesforce IDs for the three public groups*
  • (2) holds the profile to public group mapping.
• Then, I created a custom formula field (Profile.Name) on the user object to reference the user’s profile name.
• After, I created a flow using Cloud Flow Designer that does the following:

1. 1. Perform a Record Lookup on the public group ID custom metadata type to store the 3 public group IDs in three variables.
   2. Perform a Record Lookup on the Group Member object (junction object between the Group and User objects that stores the group and user assignment) to look up the current user and the three group IDs and store the GroupId in a variable.
   3. Perform a Decision to determine whether the user belongs to a group. If the variable in the previous step has a value, then this means the user was already previously assigned to a group. Otherwise, this user had no previous profile-public group assignment.
   4. If a public group is found, then perform a Record Delete on the Group Member object where the ID is the current user’s ID and the group ID is that stored in the variable from Step 2. This removes the previous group assignment.
   5. If no public group is found or after the Record Delete, perform a Record Lookup on the profile-public group mapping using the user’s profile name and storing the profile’s public group assignment in three variables.
   6. Lastly, perform a Record Create on the Group Member object where we assign the user to the new group.

• Finally, I created a process using Process Builder that initiates the process when a new user record or a change is made to an existing user record to change the user’s profile. When this criterion is met, then the process will invoke the flow for the public group assignment automation. The user’s ID and user’s Profile Name are variables passed from the process into the flow.

For step-by-step configuration on a similar use case, visit my blog: jenwlee.wordpress.com.

*If you are creating records new to the org, the IDs will never be the same between sandboxes and production. Rather than hardcoding ID references (considered a bad practice!), I reference the IDs in a custom metadata type.

Looking for more amazing webinar content? Visit the Salesforce Admins Webinars Group on the Trailblazer Community.