Architecting for Flexible Automation Execution

Salesforce automation tools provide a powerful way to simplify manual processes and streamline business operations. Automation tools can be declarative or programmatic, from Flows to Apex triggers. One of the biggest challenges in implementing well-architected automation, however, is efficiency. Specifically, how do you build automations that execute efficiently while retaining fine-grained control over when they should fire and when they should not?

Why is execution control important?

When building well-architected automations it’s important to clearly document all execution paths to ensure your operational logic is effective. But once you’ve documented it, what’s next? Execution control allows you to put the brakes on — or bypass — any and all automations as needed, whether it’s for data adjustments and migrations, testing, or even to deploy automation in a stealth mode for your pilot groups.

There are two common approaches to designing for execution control:

• Custom metadata types
• Custom permissions

These approaches provide a way to store configuration information and access it directly in Apex code, Lightning Web Components, and declarative automation tools like validation rules and Flow.

Setting up execution control can be a bit daunting, so it helps to have a solid understanding of your options. This post contrasts both approaches, and provides examples of global and object-specific execution controls, so you can select the optimal execution control approach for your Salesforce environment.

Exploring the different options

Custom metadata types

A custom metadata type is metadata that is used to define the structure for application metadata. The fields of custom metadata types, and the values in the fields, consist only of metadata. The records of custom metadata types are also metadata, not data. Using metadata is pretty handy because it can be imported into Salesforce, modified in the interface, and manipulated using the Metadata API. Instead of storing hard-coded data, custom metadata types let you configure apps by building reusable functionality that determines the behavior based on metadata. You can do much of this customization work using declarative tools.

Global execution control example

1. Create a custom metadata type and add appropriate fields.

Note: Trigger Context is a specific field for Apex automation. It’s purpose is to give admins/developers the ability to control which granular trigger operations will be skipped.

2. Create the custom metadata type record.

Record detail page for the custom metadatatype record.

3. Add the custom metadata type control reference to your automations in Flow or Apex.

Referencing the custom metadata type in Flow
To reference your custom metadata type in Flow, first use the Get Records element to retrieve the control information.

Then, add a decision element to check if the control is active.

Here’s what the flow with execution control looks like:

Referencing the custom metadata type in Apex

Because custom metadata type records are stored in memory, they are very efficient to reference in Apex code. Further, accessing custom metadata type records does not count towards SOQL governor limits. To access custom metadata type records in Apex, use the syntax below, which is described in greater detail in Access Custom Metadata Type Records Using Static Methods.

In this example, the Apex code retrieves the Global instance of the custom metadata type record associated with this specific organization.

Object-specific execution control example for Apex

1. Create a custom metadata type and add appropriate fields.

With these fields, this custom metadata type is extensible in several ways:

• You can specify if the control is object-specific using the sObject API field.
• You can use the Trigger Context field within Apex to control which operations will be skipped.

2. Create the custom metadata type record.

3. Add the custom metadata type control reference to your Apex code.

Object-specific execution control example for Flow

1. Create a custom metadata type and add appropriate fields.

You can specify if the control is object-specific using the sObject API field.

2. Create the custom metadata type record.

3. Add the custom metadata type control reference to your Flow.

To reference your custom metadata type in Flow, first use the Get Records element to retrieve the control information.

Then, add a decision element to check if the control is active.

Here’s what the flow using object-specific execution control might look like:

Pros to consider when using custom metadata types

✅ Custom metadata type records are metadata, therefore:

• They can easily be referenced in unit tests.
• They can be deployed and accessed via Metadata API.
• They will be automatically copied to all sandboxes.
• They can be stored and tracked in a version control system.

✅ Salesforce is invested in enhancing and maintaining custom metadata types.

✅ You can build custom fields and relationships for custom metadata types, making this a highly customizable approach.

✅ You can use Apex methods to retrieve custom metadata types.

Cons to consider when using custom metadata types

⛔️ Custom metadata types are not easily made accessible to end users to manage and typically must be maintained by an admin or developer with elevated permissions.

⛔️ Custom metadata type records are not hierarchical so understanding user context for the execution control may involve more complex logic.

⛔️ Your automation must reference specific custom metadata type records, so deleting records can potentially break your automations.

Custom permissions

Custom permissions provide a granular means to control access to Apex classes, Lightning Web Components, and declarative automation like Flow and validation rules. You can create a custom permission and assign it to a profile or permission set. Then, in your Apex code or declarative automation, you can check if the current user has been assigned the custom permission before executing. By doing this, you can control automation logic for users who do not have the custom permission assigned.

Global execution control example

1. Create a custom permission.

2. Add the custom permission control reference to your automations.

Referencing the custom permission in Flow
To reference your custom permission in Flow, simply add a decision element to check if the control is active.

If the user has a profile or permission set assigned that contains the custom permission, the criteria will evaluate to true.

Here’s what global execution control using a custom permission looks like in Flow Builder:

Referencing the custom permission in Apex

Custom permissions use context variables and can be accessed via built-in functions as shown below. The return value of the checkPermission method is a Boolean variable that indicates if the running user has the queried custom permission. For more details refer to Custom Permissions.

Object-specific execution control example for Apex

1. Create a custom permission.

2. Add the custom permission control reference to your Apex code.

3. Assign the custom permission to a permission set.

4. Assign that permission set to a user.

Object-specific execution control example for Flow

1. Create a custom permission.

2. Add the custom permission control reference to your flow.

3. Add a decision element to check if the control is active.

If the user has a profile or permission set assigned that contains the custom permission, the criteria will evaluate to true.

4. Assign the custom permission to a permission set.

5. Assign that permission set to a user.

Pros to consider when using custom permissions

✅ Custom permissions can be assigned and managed through permission sets and/or profiles; no strings of IDs or complex queries are required.

✅ You can grant time-based, session-based, license-based, and grouped execution control via permission set functionality.

✅ Custom permissions can be used to skip a wide variety of Salesforce automation, including validation rules, Apex triggers, and other types of automation.

Cons to consider when using custom permissions

⛔️ Permission assignment can be complex. Should you use profiles, permission sets, or permission set groups? Depending on the granularity you need (global vs. specific) you may require a significant number of permission sets and groups. Assignment may potentially be manual and difficult to maintain. Or, it may require building out custom code and UX to automate and manage execution control assignments.

⛔️ This approach is not easy to customize. Custom permissions contain a label and that is it. No additional fields or relationships can be built. When referencing these execution controls in Apex there is no place to indicate the trigger context or other parameters, and that reduces flexibility.

Comparing the approaches

Conclusion

Architecting well-designed automations using Salesforce gives you the scalability to drive business outcomes and the flexibility to control their execution according to your business needs. This post covered how to implement execution controls of different types and levels of flexibility. It provided examples for two broad approaches of the many available. You can use the examples as a guide on what to think about when selecting an execution control approach:

1. Identify the Salesforce automations you want to include in your execution control (for example: Flow, Apex, validation rules).
2. Review this post and choose the best approach based on your specific requirements.
3. Determine the structure of your execution control. Is it global or object level? Is it specific to a single automation or does it apply to multiple automations?

Finally, take some time to read Well-Architected — Automated for additional guidance on how to build healthy automations.

References

1. Trailhead: Custom Metadata Types Basics: https://trailhead.salesforce.com/content/learn/modules/custom_metadata_types_dec
2. Salesforce Help: Custom Metadata Types: https://help.salesforce.com/s/articleView?id=sf.custommetadatatypes_overview.htm&type=5
3. Apex Reference Guide: Custom Metadata Types Methods: https://developer.salesforce.com/docs/atlas.en-us.Apexref.meta/Apexref/Apex_methods_system_custom_metadata_types.htm
4. Salesforce Security Guide: Custom Permissions: https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/custom_perms_overview.htm

About the Authors

Maya Peterson, Lead Technical Architect
Since 2014 Maya has been delivering high value solutions for customers and clients ranging from small business to enterprise and spanning across multiple industries. She is passionate about designing and implementing system architecture for scalability, repeatability, and efficiency. When she’s not going full ‘force’ you’ll find her creating art, backpacking, cooking, or volunteering in her community.

Stefan Zepeda, Principal Technical Architect
Stefan Zepeda helps customers design well-architected solutions using Salesforce in his role as a Principal Technical Architect. He is an expert in different platform topics like integration, automation and security in Salesforce. Before his time at Salesforce, Stefan was a Solutions Architect, Developer and Admin for 7 years at a large Salesforce customer focused deploying the platform at scale.