Skip to Content

Three Ways Salesforce Architects Plan For Automation Limits

By Gokul Seshadri October 29, 2019

A sample business process that can be automated using Salesforce tools
A sample business process that can be automated using Salesforce tools

In our first post of this automation series, Salesforce experts documented key best practices for planning automated processes in your org. Next, our experts provided detailed steps to implement four common automations that can help your org run smoother. In this final post of the series, we will explore three critical usage considerations to avoid bottlenecks in your automation processing.

Because Salesforce is a shared multi-tenant platform, it’s important to plan your automations accordingly. While this is more relevant to large organizations with a significant number of process automations, all orgs should be aware of these limits and be able to manage them.

1. Limits on Automated Business Processes

AstroDepending upon the type of automation, Salesforce places certain limits on the total number of business processes that can be defined per customer org. For example, the total number of approval processes in a given customer org cannot exceed 1,000. Similarly, the total number of Workflow rules that can be defined per customer org cannot be more than 2,000. There are similar limits applicable to Process builder and Flow builder processes as well.

2. Evaluate the Number of Actions Performed with Your Automation

AstroLimits are applicable to various actions/updates or database transactions that are expected to be performed as a part of automation. Some of these limits are applicable per transaction level (enforced by Apex limits), while the rest are applicable per process instance. For example, there is a limit on Process builder with respect to the number of SQL queries that can be performed per transaction: 100. Similarly, the total number of DML statements that can be issued (insert / updates) per transaction is limited to 150.

Whenever these limits are exceeded, Salesforce issues warnings/errors such as “Too many SQL Queries:101” exceptions. One of the most common situations in which SQL query limits are exceeded is when queries are placed inside for loops in APEX classes and the number of iterations vary at runtime.

If there are business situations that exceed this limit, other options can be considered. For example, one can consider using backend Bulk API / Scheduled APEX jobs which can do large data processing (inserts / updates) in an asynchronous manner and these offer higher limits.

A sample process built using Flow Builder
A sample process built using Flow Builder

3. Design with Object Limits in Mind

Astro worksIn Salesforce, each object represents a specific piece of data. There are standard objects predefined at the platform level and custom objects defined by you. Limits on process automation tools are sometimes applicable at a per object level. For example, the total number of active workflow rules per object cannot exceed 50. Similarly the total number of approval processes per object cannot be more than 300.

For most business use cases, these limits are sufficient. But if a solution or requirement seems to challenge these limits, then the overall architecture and design needs to be reconsidered and other options / innovative solutions need to be thought of. Having 50+ workflow rules per object introduces many other complexities in the solution and is not just a governor limits problem.

While many of these limits and numbers may not raise red flags immediately, they can easily become a bottleneck. This is especially true when automations are used for some of the most frequently executed mundane processes, such as checking triggers and frequently updating the backend. Be sure to check the resources below for further guidance and information.

This blog is part three of a three part series on Using Process Automation, and part of our larger “Ask an Architect” content series. Watch the recording of our October 2019 Architect-led Process Automation webinar. Last but not least, don’t forget to download our latest whitepaper on the topic.

To learn more about engaging a Customer Success Architect in your organization, please contact your Account Executive.

About the Author
Gokul SeshadriGokul Seshadri is a Senior Principal Customer Success Architect at based in the U.S. He helps higher ed and nonprofit customers to succeed in their multi-channel marketing, digital transformation, and customer 360 initiatives using Nonprofit Cloud, Education Cloud, and other related technologies.