top of page

Salesforce Automation – Updating Records

Architecting for Success

A legacy is what we leave behind for others, but a legacy does not just happen overnight. It takes planning. As Norman Foster once said, “As an architect you design for the present, with an awareness of the past, for a future which is essentially unknown.” The Pons Fabricius is a bridge that was built in 62 BC and is still used today, making it the oldest working bridge in Rome. How has it lasted for over 2,000 years? Was it from limiting its use? Obviously, it has a solid foundation and was built using durable materials as directed by its architects.

As Administrators, Developers, and Architects we all hope to leave behind an environment that is stable, scalable, and will last at least a decade beyond our retirement. The reality, however, is that most times what is left behind is a staggering amount of technical debt. So, how do we avoid the debt and leave behind something that will last beyond our careers? David Chipperfield said it best when he said “the difference between good and bad architecture is the time you spend on it.”

Therefore, as we begin designing any automation that is intended to update records in Salesforce let us consider a few of key concerns for field updates. First, be mindful of the governor limits. Second, understand the types of automation available from Salesforce and their limitations. Finally, remember the Order of Execution that we recommended in a previous article, and keep your existing automation in mind.

Automation Types

Workflow Rules

Workflow rules are easy to implement and useful, but also limited and outdated. The primary advantage to using Workflow over any other type of automation for updating fields is that it does not execute any SOQL or DML statements, so it does not apply to any governor limits. It also allows you to reuse any updates or emails that you create as part of the workflow with other workflow rules or approval processes.

Aside from its limited features, the greatest limitations of Workflow Rules are:

  • You have no real control over the order in which the rules execute if you have more than one rule on the same object.

  • There is no native versioning support, making iterations a little more difficult to manage (which is not an issue if you are using proper version control, but that is a different conversation…)

  • Unless you have a master-detail relationship established, you can only update the record that triggered the rule.

Process Builder

Enter Process Builder. With built-in versioning, Process Builder allows you to update records, update records that are related to the record, create new records, call Apex code, launch other flows and processes…sounds all-encompassing, right?

Not exactly. There are some things that Process Builder cannot do, and if you are editing records beyond the record that initiated the process Salesforce’s governor limits apply. You cannot execute Process Builder against Delete actions. And while you have the benefit of ordering your processes in a single Process Builder, the logic is still simple.

The good news is that you can combine Process Builder and Flows or even call Apex to accomplish the more complex functionality that it may not be able to do on its own.


Flows allow you to do quite a bit more than Process Builder, especially when complex logic and data-driven design are required. However, since Flows and Processes both share the same governor limits, make sure that you are aware of your existing automation to avoid causing exceeding the limits.

Unlike Process Builder, Flows can delete records and submit related records for Approval, delete records, and relate several records together. Like Process Builder, however, Flows cannot execute for a Delete action.


When you cannot do it with Flows and Process Builder, use an Apex Trigger. Apex can perform more complex logic than Flow or Process Builder and gives you more control over performance but requires someone with a developer’s skillset to implement the automation that you are looking for.

Additionally, Apex is currently the only way to execute logic related to a Delete action.

Looking at the Requirements

So, as we look at the various options for updating fields in Salesforce, keep the requirements in mind.

Why are you updating?

Why are you updating the field? There are 3 primary reasons to update a field on a record using automation.

One, you want to ensure data quality/accuracy. For example: updating the status on all child Cases when the Parent case is closed.

The second reason that you generally hear for field updates is to replicate data across related records to keep data persistent. This may seem like it is the same as the first reason, but the difference is generally in the fact that the data is edited only at the parent level. In the case of the Case Status, child Cases may be closed out individually, but if the parent case is updated, all children are updated to reflect that status. For the ‘persistent data’ requirement, consider the underlying need of the request. If the need is to include the data in list views you should use a formula field instead of updating a field. If the users are trying to include the field in reports and dashboards, it may be worth looking into training for users or a custom report. If it is for displaying data from the parent on a child records in the UI, add the field to the Mini Layout. The bottom line: avoid data replication for replication’s sake.

The third reason that I have seen for updating fields is to update state on a parent record. This is a slippery slope. Many times, this requirement is to provide reports or to drive additional automation. If the requirement is to provide insights through reporting, consider training users on different reporting options instead. If the automation request is around driving additional automation based on that state, consider architecting your solution so that the automation is triggered directly rather than updating a field to trigger further automation in a domino effect which can lead to performance issues.

What are you updating?

After you have determined that you need to do an update, consider where the field sits in the data model. Is it an update to the same record, or to a related record? Are you updating a child object, or a related object? Or are you updating a record that is completely unrelated?

Do you need additional data? For example, are you looking to assign a record to a user based on custom capacity rules and current record assignment? Are you setting values based on data elsewhere in Salesforce?

Flows and Process Builder can feasibly solve these situations, but you may see some issues with performance, especially as you begin working with larger data volumes. Also, error handling is not the most elegant with Process Builder or Flows.

Are you trying to execute the logic when a Delete occurs? Are you working with large data volumes that may exceed the governor limits with Flow and Process Builder? Are you looking to control record recursion in your automation? Is performance and speed a concern? Is the ability to gracefully handle errors important? If the answer to any of these is ‘yes’, then an Apex Trigger is going to be your recommended solution.

Pick one?

So which type of automation is the best for field updates? The answer is “it depends.” And it truly does depend on the requirements, the skillset available, and the existing automation. Determine if automation is truly needed, or if there is another way to solve it using the tools already available. Take the time to document what is currently in place and the requirements. Think about what needs to be updated, where does the update occur in the data model, and where does the update happen in the transaction? Does the update happen in real time, or can it happen later? Should it happen at specific times of the day?

The best solutions often utilize multiple approaches. Study each of the methods mentioned here individually, and use them together to create a scalable, long-lasting solution. And remember: “Why make it Code, when it can be Config? Why make it Config when it can be Data-driven? And why make it Data-driven when it’s available out-of-the-box?”


About the Author

Dan Curry serves as our Director of Global CRM Delivery and Architecture with over 14 years’ experience in creating specialized clients solutions in process automation, data-driven application design, and team dynamics. He holds multiple Salesforce and industry specific certifications. Outside of his professional life, Dan spends time with his family, is an active minister in his local church, and practices Gadi Kempojitsu and Krav Maga where he is both an instructor and mentor.

Daniel Curry

Director, Global CRM Delivery and Architecture

St. Louis, Mo


bottom of page