Salesforce Automation: Workflow Rules, Approval Processes, Governor Limits, and Bulkification

Let’s see a scenario that would most likely happen in almost every Salesforce organisation you are going to work with.

A common real life scenario where a sales rep closes a deal. The opportunity record needs to be updated with the close date. Then someone in finance needs to get an email about it. Then a task needs to get created for the account manager to schedule an onboarding call. And if the deal crosses a certain amount, a VP needs to approve the discount applied.

Now imagine doing all these manually every single time, for all the deals.

Nobody does that. Or rather, nobody should be doing that. That is what Salesforce Automation is for.

Table of Contents:

• Current Trend of Salesforce Automation 
• Why Salesforce Automation?
• Workflow Rules in Salesforce
• Approval Processes in Salesforce
• Governor Limits in Salesforce
• Bulkification in Salesforce
• Frequently Asked Questions

What Does the Current Trend of Salesforce Automation Say?

Salesforce reported $37.9 billion in revenue for fiscal year 2025, which is up 9% year over year. Their Q3 fiscal 2026 filing with the SEC shows the company raised its full year guidance to $41.45 billion, and CEO Marc Benioff announced a long term revenue target of $60 billion by fiscal 2030. Those are not projections from some random analyst report. Those come straight from the company's own SEC filings.

And the dominance is not just about revenue. IDC's 2025 Worldwide Semiannual Software Tracker ranked Salesforce as the number one CRM provider for the 12th consecutive year, holding a 20.7% global market share in 2024. They generated over $21.6 billion in CRM revenue alone, which is more than Microsoft, Oracle, Adobe, and SAP combined. IDC also ranked them first in Sales for 13 straight years, first in Customer Service for 12 years, and first in Marketing for 6 years. Separately, Gartner's CRM sales software market analysis pegged the global CRM sales market at $25.7 billion in 2024, growing at 12.2%.

More than 150,000 companies run their operations on Salesforce. According to Salesforce's own earnings announcement, nearly half of Fortune 100 companies are now customers of both their AI and Data Cloud products. Their Agentforce AI platform handled over 380,000 customer support conversations with an 84% resolution rate, and only 2% of those interactions needed a human to step in.

Why Salesforce Automation?

Salesforce gives you tools to make all of this happen on its own. Records update themselves and emails go out without anyone clicking “Send.” While the tasks appear in people's activity feeds, approvals get routed to the manager. And, all of it runs in the background, triggered by the data itself.

But here is the part most tutorials leave out. There are rules about how much automation you can run at one time. Salesforce puts caps on it. And if you are writing code to handle any of this, you need to write it in a very specific way or it breaks the moment someone loads more than a handful of records.

So what we are covering here is the full picture. Workflow rules for no code automation. Approval processes for getting human sign off on records. Governor limits so you know where the guardrails are. And bulkification so your code does not fall apart in production.

Alright, enough setup.

• Workflow Rules let you set up automatic actions like field updates, emails, and tasks without touching a line of code
• Approval Processes route records to specific people for review before anything moves forward
• Governor Limits are the hard caps Salesforce puts on how much your code or automation can do in one go
• Bulkification is a coding discipline that makes your Apex survive when it has to process hundreds of records at once

Workflow Rules in Salesforce

For the first time when you set up a workflow rule, you might try to automatically update a Status field on a custom object whenever someone changed the Priority to "Urgent." It will take you nearly ten minutes to configure, and you will end up thinking, wait, that is it? No code? It just works?

Yeah. It just works.

A workflow in Salesforce is basically an engine that watches your records. When a record gets created or edited, the engine checks it against criteria you have defined. If the record passes the check, one or more actions fire automatically. If it does not pass, nothing happens. The record saves like normal, and nobody notices.

The Two Pieces of a Workflow Rule:

Every workflow rule boils down to two things.

Criteria: This is the "if" part. You are telling Salesforce what to look for. Probably, you are asking it to check if the Amount field is greater than 50000. Or if the Stage field equals "Closed Won." Or if the Lead Source is "Web." You define the conditions, and Salesforce evaluates every record against them.

Actions: This is the "then" part. What should happen when a record matches? Send an email? Update a field? Create a task? Fire off a message to an external system? You pick one or more of these, and Salesforce handles the rest.

When Do the Actions Actually Run?

This is a question that catches people off guard, because not all actions fire at the same moment.

• Immediate Actions run right away. The record is saved, the criteria are checked, and boom, the action executes. No waiting.
• Time Dependent Actions are different. They sit in a queue. You ask Salesforce to "send this email 7 days before the Close Date" or "create this task 3 days after the record was last modified." Salesforce holds onto the action and only runs it when the time comes. It is kind of like scheduling a reminder, except the platform handles everything.

Four Things a Workflow Rule Can Do

Once the criteria are met, you get four options for what happens next.

• Field Updates: Automatically change the value of a field on the record. You would see this used for everything from setting default values to calculating simple formulas on save. For example, it is used while automatically stamping the current date into a "Last Reviewed" field whenever a record gets edited.
• Email Alerts: Send an email to one or more people using a template you built ahead of time. The sales manager gets notified when a big deal closes. The support lead gets pinged when a high severity case comes in.
• Tasks: Assign a to do item to a specific user. The person sees it in their activity feed and can update the status as they work on it. Managers can track these through related lists on the record. It replaces the old "send someone a Slack message asking them to do something" approach, which, we all know, does not work reliably.
• Outbound Messages: This one is more technical. It sends an XML based API message to an external endpoint. So if you have a system outside Salesforce that needs to know when certain records change, outbound messages are one way to make that happen without writing integration code.

Building One From Scratch

The steps are pretty simple, but let's list them down because skipping any one of them will leave you wondering what’s wrong.

• Step 1: Go to Setup, find Workflow Rules in the sidebar, and start a new rule. Pick the object it applies to.
• Step 2: Define your conditions. Choose the fields, set the operators, enter the values. You can also use a formula if your logic is more complex than simple field comparisons.
• Step 3: Add your actions. Field update, email alert, task, outbound message. Either pick one or combine a few.
• Step 4: This is the one people forget. Activate the rule. Salesforce does not run inactive rules. You might wonder why "my workflow is not firing" and the answer would be you never turned it on.

If you want a proper walkthrough with live practice, check out MindMajix's Salesforce Automation training that covers workflow configuration as part of the curriculum.

Approval Processes in Salesforce

There is a pattern you see in every business, regardless of size or industry. Junior people cannot sign off on certain things. A sales rep cannot just hand a client a 40% discount without someone above them saying yes. An employee cannot book international travel without their manager's authorization. A new hire's paperwork cannot move forward until HR and the department head both review it.

In Salesforce, this pattern is handled through approval processes and once you set it up, you will realize how much time people waste doing this manually through email chains and verbal confirmations.

What Actually Happens When Someone Submits a Record for Approval

Let me walk through the sequence because it is important to understand the mechanics.

For instance, a user clicks the "Submit for Approval" button on a record. Salesforce immediately locks the record so that nobody can edit it while it is under review. Then the platform checks entry criteria to decide if this record qualifies for the approval process or not. If it qualifies, Salesforce identifies who the approver should be and then notifies them. Next, the approver reviews the record and either approves or rejects it. Depending on the outcome, different actions are fired automatically.

The whole thing happens without anyone needing to send a follow up email or chase someone down the hallway.

A Real Example:

This one comes from the source material and it is a good illustration.

A placement company handles candidates applying for job placements in the UK. The HR team processes applications, but before any UK placement candidate can move forward, the hiring manager has to approve them. So the approval process checks: is the Country field on this candidate's record set to "UK"? If it’s yes, send it to the manager. However, if the manager is out of office, the system sends an email notification using a predefined template so that the manager can approve remotely.

It’s very simple, automated and traceable.

Setting It Up Step By Step:

• Step 1: Navigate to Setup, then go to Workflow & Approvals, then Approval Processes. Pick the object you want to build it on.
• Step 2: Name the process something descriptive. "UK Placement Approval" is better than "Approval Process 1." You will thank yourself six months from now when you are trying to figure out what each one does.
• Step 3: Set the entry criteria. This is the gate. Only records that match get into the approval pipeline. Everything else is unaffected.
• Step 4: Choose the approver. Salesforce lets you pick a specific user, the record owner's manager, someone from a role hierarchy, or even a queue. Depends on your business needs.
• Step 5: Set up the email template for the notification. If someone needs to approve something and they are not logged into Salesforce at that moment, this email is what gets their attention. Make it clear and include the relevant details.
• Step 6: Define what happens on approval and what happens on rejection. Is it approved? Update the Status field to "Manager Approved" and send a confirmation email. Is it rejected? Then, set the Status to "Returned" and notify the submitter with the reason.
• Step 7: Activate it. Same deal as workflow rules. Does not run until it is active.

When One Approver Is Not Enough:

Some situations need multiple levels of approval. A discount under 20% might only need the team lead. Between 20% and 40%, the regional manager has to weigh in. Above 40%, it goes to the VP.

Salesforce handles this through multi step approval processes. You chain steps together. Each step can have its own entry criteria and its own designated approver. The record climbs the ladder until it either gets fully approved or someone rejects it along the way.

Governor Limits in Salesforce

Alright, now we get into the part that frustrates every new developer at least once.

You write a trigger. It works perfectly in your sandbox. You test it with 5 records, 10 records, everything looks great. You deploy it to production. Someone loads 400 records through the Data Loader the next morning, and suddenly there is an error message that says "System.LimitException: Too many SOQL queries: 101."

That is a governor limit error. And the first time it happens, it is genuinely confusing.

Why These Limits Exist in the First Place:

Here is the thing about Salesforce that a lot of people do not fully appreciate. Your org does not have its own server. It shares server resources with thousands of other Salesforce customers. A small company with 50 users is on the same physical infrastructure as a multinational company with 10,000 users. And, your company is right there alongside them.

Now think about what happens if someone at one of those orgs writes a trigger that runs a database query for every single record in a 200 record batch. That is 200 queries hitting the server. And if someone else at another org does the same thing at the same time, now you have 400 queries competing for database resources.

Salesforce cannot allow that. So they put caps on what any single transaction can do. These caps are governor limits, and they are not suggestions. They are hard walls. Cross one, and your code stops executing immediately. The transaction rolls back. The user sees an error.

The Limits That Come Up Most Often:

These are some of the most important ones that cause 90% of the challenges on real projects.

• SOQL Queries: You get 100 per synchronous transaction. Most developers blow through this one by putting a query inside a for loop. 200 records in the trigger means 200 queries. You are done at 100.
• DML Statements: Cap of 150 per transaction. Every insert, update, delete, or undelete is one statement. If you put a DML call inside a loop, you are asking for trouble.
• DML Rows: A max of 10,000 rows are affected by DML in a single transaction. So even if you only run one insert statement, if the List contains more than 10,000 records, it fails.
• Heap Size: 6 MB for synchronous, 12 MB for asynchronous. This is how much memory your variables and data structures can consume. Large collections or complex objects eat through this fast.
• CPU Time: 10,000 milliseconds for synchronous transactions. If your code takes longer than 10 seconds, Salesforce kills it. No negotiation.
• Callouts: 100 HTTP callouts per transaction. Each API call to an external system counts.

What Actually Happens When You Hit One:

Your transaction dies and there comes no "warning at 80%" or "graceful fallback." The system throws an exception and everything that happened in the transaction gets rolled back. Finally, the end user sees an error screen. In some cases, this means that the data that should have been saved is gone.

That is why knowing these limits is not some optional trivia for Salesforce Automation professionals. It is survival knowledge.

Managed Package Limits:

One thing worth knowing. If your org has AppExchange packages installed, the ones that are certified by Salesforce get their own separate governor limit counts. Their SOQL queries do not count against your 100. Their DML does not count against your 150. Each certified namespace gets its own bucket.

But, and this is important, some limits are global. CPU time, heap size, and total execution time are shared across all namespaces. So a heavy managed package can still eat into your available CPU even if its queries are counted separately.

Strategies for Staying Within the Limits:

Well, there is no magic trick here. It just comes down to writing efficient, thoughtful code.

Move queries and DML outside of loops. Always. No exceptions.

Use collections to batch your operations. Gather IDs in a Set, query into a Map, do DML on a List. One operation instead of many.

Use the Limits class to check where you stand during execution. Limits.getQueries() tells you how many SOQL queries you have used so far. Limits.getLimitQueries() tells you the maximum allowed. Compare the two before running additional operations.

If your logic is too heavy for a synchronous transaction, move it to an asynchronous context. Future methods, Queueable, Batch Apex. These give you higher limits and their own execution context.

Bulkification in Salesforce

This topic is really the practical answer to the governor limits question. You now know what the limits are. Bulkification is how you write code that respects them.

The word itself is a bit unusual. "Bulkification" is not something you will find in a standard programming textbook. It is a Salesforce specific term that means writing code capable of handling many records at once without running into governor limits.

Let’s be clear about something. This is not optional. Every Apex trigger in Salesforce should be bulkified. Not most. Every single one. If your trigger only works correctly with one record at a time, it is broken. It just has not failed yet.

The Classic Mistake:

Let us show you the code pattern that breaks in production. You will see versions of this in code reviews more times than you can count.

// This will crash when processing bulk data
for (Levis__c jean : Trigger.new) {
    if (jean.Price__c >= 1000) {
        jean.Price__c = jean.Price__c - 100;
        update jean;
    }
}

Each time through the loop, it runs a separate update statement. If the trigger receives 200 records (which is the standard batch size for many operations in Salesforce), it means it is 200 DML statements. But, the limit is 150. So around record number 150, the whole transaction explodes.

The Fix:

// This works with any number of records
List<Levis__c> jeansToUpdate = new List<Levis__c>();

for (Levis__c jean : Trigger.new) {
    if (jean.Price__c >= 1000) {
        jean.Price__c = jean.Price__c - 100;
        jeansToUpdate.add(jean);
    }
}

if (!jeansToUpdate.isEmpty()) {
    update jeansToUpdate;
}

One DML statement. One. Does not matter if the trigger received 1 record or 2000. The DML count stays at 1 because the update happens outside the loop, operating on the entire collection at once.

Same Problem, SOQL Edition:

Queries inside loops are actually even more common than DML inside loops, and they are just as deadly.

What not to do:

for (Contact con : Trigger.new) {
    Account acc = [SELECT Name FROM Account WHERE Id = :con.AccountId];
    System.debug(acc.Name);
}

That query runs once per Contact. Two hundred Contacts? Two hundred queries. Limit is 100. Crash.

What to do instead:

Set<Id> accountIds = new Set<Id>();
for (Contact con : Trigger.new) {
    accountIds.add(con.AccountId);
}

Map<Id, Account> accountMap = new Map<Id, Account>(
    [SELECT Id, Name FROM Account WHERE Id IN :accountIds]
);

for (Contact con : Trigger.new) {
    if (accountMap.containsKey(con.AccountId)) {
        System.debug(accountMap.get(con.AccountId).Name);
    }
}

One query. Always one query. You grab all the Account IDs first, run a single SELECT, dump the results into a Map, and then look things up from the Map inside the loop. No additional database calls needed.

Testing Bulkified Code:

When you are writing test classes for bulkified triggers, Salesforce gives you something useful. The Test.startTest() and Test.stopTest() methods reset the governor limit counters between them. So the DML and SOQL you used during test data setup do not eat into the limits available for the actual code you are testing.

@isTest
static testmethod void testJeanDiscount() {

    Levis__c j = new Levis__c();
    j.Name = 'Louis';
    j.Price__c = 1200;

    Test.startTest();
    insert j;
    Test.stopTest();

    Levis__c result = [SELECT Price__c FROM Levis__c WHERE Id = :j.Id];
    System.assertEquals(1100, result.Price__c);
}

Everything between startTest() and stopTest() gets a fresh set of limits. This matters when your test class has several methods and each one does a lot of setup work. Without this mechanism, you would exhaust your DML allowance before you even get to the actual assertions.

The Pattern That Solves Most Problems:

After writing triggers for a few years, you start to see the same four step pattern emerge over and over. It works for almost every trigger scenario.

• First: loop through Trigger.new and collect whatever IDs or field values you need. Put them into a Set.
• Second: run a single SOQL query using that Set. Store the results in a Map keyed by the record ID.
• Third: loop through Trigger.new again. This time, look up related data from the Map. No queries inside the loop. Just Map lookups.
• Fourth: collect any records you need to modify into a List. After the loop finishes, run one DML statement on the entire List.

That is the template. Set, Map, loop, single DML. It handles 1 record the same way it handles 10,000. And it keeps your governor limit usage predictable and low.

How All Four Pieces Fit Together:

Let’s take a second to explain why we covered these four specific topics together, because it is not random.

Workflow rules and approval processes are what you use when the business logic can be handled declaratively. No code needed. They cover a surprising range of automation scenarios, and honestly, you should always check if a workflow rule or flow can handle your requirement before reaching for Apex.

But even workflow rules count against governor limits. A field update triggered by a workflow rule is still a DML operation under the hood. An email alert still consumes resources. So understanding limits matters even for admins who never write code.

Governor limits define the playing field for everything. Code, automation, managed packages. Everything operates within these boundaries.

And bulkification is how developers write code that plays well within those boundaries. It is the bridge between knowing the limits exist and actually writing triggers that respect them.

If you skip any one of these four topics, you will end up with gaps in your understanding that will cause real problems on real projects.

Frequently Asked Questions

1. Do I need to know Apex to work with Salesforce Automation?

Ans:  Not for everything. Workflow rules and approval processes are completely declarative. You build them through the Salesforce UI. But if you want to write triggers, batch classes, or anything involving custom logic, then yes, Apex is required. A lot of admins start with declarative automation and pick up Apex gradually as they encounter more complex requirements.

2. What happens if my workflow rules and triggers both fires on the same record? 

Ans: They both execute, but the order matters. Triggers fire first, then workflow rules evaluate and fire their actions. So, if a workflow field update changes on a field value, Salesforce re-fires the before update and then after update triggers a second time. This might create unexpected behavior if you are not aware of it.

3. Why do governor limits exist? 

Ans: Salesforce is a shared platform. Thousands of orgs run on the same servers. Governor limits prevent one org's code from consuming so many resources that it degrades performance for everyone else on the same infrastructure. They are a tradeoff. You give up unlimited execution in exchange for guaranteed stability.

4. What is the single biggest mistake new developers make with bulkification? 

Ans: Putting SOQL queries or DML statements inside for loops. It is the one mistake that causes the most governor limit failures in production. The fix is always the same. Move the query or DML outside the loop and use collections to batch the operations.

5. Where can I practice building workflow rules and approval processes?

Ans:  Sign up for a free Salesforce Developer Edition org. It costs nothing and gives you a full sandbox environment. Build a workflow rule on any standard object, test it, and see the results. Then try building an approval process. Hands-on practice is genuinely the fastest way to learn this.

6. Are there more learning resources available? 

Ans: Yes. MindMajix has several free resources.

• Salesforce Tutorials
• Salesforce Interview Questions

Conclusion

We covered a lot in this guide. Quick recap of where we landed.

Workflow Rules : It lets you watch your records and fire off automatic actions when conditions are met. Field updates, email alerts, task assignments, outbound messages. All configurable through the UI.

Approval Processes : It gives you a structured way to route records through one or more levels of human review. While submitters submit, approvers approve or reject, and automated actions fire based on the outcome.

Governor Limits are the ceilings Salesforce enforces on every transaction. 100 SOQL queries, 150 DML statements, 10 seconds of CPU time. These are non-negotiable, and knowing them prevents a lot of production headaches.

Bulkification is the coding practice that keeps your Apex running smoothly when it processes records in bulk. Queries and DML outside of loops. Collections to batch operations. One operation instead of many.