Sort by Topics, Resources
Topics
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Salto for
Salesforce
Guides
Salesforce Automation - How to Truly Eliminate Work
In this guide to Salesforce automation, discover the biggest error companies commit, plus tools and tactics for eliminating unnecessary work.
Author
Knuckles
8
min read
SHARE
Identifying Salesforce Inefficiencies
As the adage goes, applying automation to an inefficient process will magnify the inefficiency. Yet many teams do this regardless because it’s actually quite difficult to know whether something is inefficient while it’s happening.
Very often, inefficiency masquerades as the opposite—a perfectly virtuous Salesforce workflow rule with immediate benefits.
For example, you implement a validation rule for salespeople and suddenly, 100% of all new sales opportunities have a contract value. Hooray! Yet upon inspection you find that the validation rule has equally fast-acting negative effects—sales reps now avoid creating opportunities ... and instead keep things in Evernote.
That’s why every discussion of Salesforce automation should begin not with how to do it, but why, and who. Only then can you decide whether workflow rules or Flows are best, and how to test and launch that change.
In this guide, we explore the theory of Salesforce automation, best practices, Salesforce automation types, examples of automation gone right and wrong, and a flow chart to help you decide whether Salesforce automation is a good idea.
What is automation in Salesforce?
Salesforce automation is the act of creating automatic, rules-based actions within Salesforce (or Force.com) software. The vast majority of these actions are triggered events that fire if a set of criteria is met. For example, automatically creating a new customer record when a deal is saved as “Closed-Won.”
There are several ways of going about creating those rules, which we will discuss later. But first, let’s step back and get philosophical. Automation, at its heart, is about achieving an outcome while minimizing human input. Cars are automation. Travel booking sites are automation. SMS text is automation (as opposed to delivering a handwritten note).
Which is all to say, there’s a whole spectrum of ways to reduce human involvement—from the mundane, like duplicating a Salesforce record, to the profound, like entirely replacing the role of a sales development rep.
Nobody says you need to go straight for full automation in Salesforce. Full automation is not easy. Nor is it guaranteed. The graveyard of failed Salesforce projects is littered with overly clever attempts to fully remove humans from the loop, which often result in lightning-fast rules ruining customer data at lightning speed.
Examples of failed Salesforce automation
- Validation rules block sales reps from logging activities
- Deleted data prevents finance from sending invoices
- Overwritten object data is lost forever
- An import rule creates duplicate leads
- A rule incorrectly updates all child records with duplicate data]
That’s why, to return to our definition of Salesforce automation, “achieving an outcome” is so very important. Before you even consider what type of automation you need, you first must define the problem and solve it on paper.
There is no such thing as a Salesforce automation consultant who can waltz into an organization, customize it, and have things go well. Every organization is unique, hence the success of Salesforce as a company—its software is the CRM (or Success Cloud, or Finance Cloud) with the strong foundation that companies can customize entirely to suit their needs.
Salesforce clouds are so extensible that companies build entire businesses on the Force.com platform, like nCino, which built and now sells a CRM for banks. Within each company running Salesforce CRM, administrators and managers essentially act like product managers and developers, assembling new offerings out of Salesforce components to create a product upon which the revenue organization runs.
And if Salesforce managers have the responsibility of product teams, they ought to treat automation with the same rigor, and only automate things that they first truly understand.
A Salesforce automation flow chart:
Another way to think about Salesforce automation is you are encoding people’s existing habits and practices into the system, with added nudges and safeguards to ensure the moral arc of your instance bends toward data quality. Very often, you won’t even know where your opportunities to automate things lie until you’ve been with the organization for some time. And you won’t know the right fix until after thorough interviews, research, testing, and discussion.
Thus, the best thing you can do when thinking about Salesforce automation is to truly, deeply understand how your business works. Know the problems your users run into, and be the one to identify problems that are a fit for automation.
"Many requests from the business are really people problems disguised as technical requests."
And if you receive requests, as you assuredly will, triage those requests carefully. Many requests from the business are really people problems disguised as technical requests. Marketing may ask for help implementing lead follow-up rules to avoid a difficult discussion with the sales team. Very often, the flowchart of “Should we implement more rules?” should lead you to, “No, these teams simply need to talk to each other.”
Only consider automating when an idea or request matches these criteria:
- It can’t be more easily solved without automation
- Fixing the issue would have a meaningful impact on your org
- You understand and can articulate the problem
- You can draw a diagram of the fix, and it makes sense
- You conduct impact analysis and verify that the change wouldn’t have serious negative consequences
And if you find something with those criteria, you move on to implementing Salesforce workflow rules and Flows.
The 4 Salesforce automation types
Broadly, there are four types of Salesforce automation available to you:
- Workflow rules—simple “if this, then that” logic
- Flows—an interface for visually diagramming rules
- Code—an interface to write Apex code
- APIs—an interface to integrate business logic with other systems
Let’s explore each of the Salesforce automation types in detail:
1. Workflow rules are limited but easy to set
Salesforce workflow rules allow you to set “if this, then that” scenarios where if the criteria are met, Salesforce will make a specific change, such as:
- Create a task
- Update a field
- Send email alerts
- Send outbound emails
The great challenge with workflow rules is that each one is an island, and a collection of workflow rules can grow into an unmanageable snarl of dependencies.
They do precisely what they’re instructed, even as the environment evolves. So as you alter your org’s configuration, you may have to return to update every rule.
Avoid workflow rules if possible—they’re fast and easy, but they tend to create technical debt.
"Whenever possible, automate your if/then statements with Process Builder instead of workflow rules." - Salesforce’s Help Docs
2. Flows are powerful but require planning
Salesforce Flow Builder gives you a visual interface within which you can create logic flows and set conditions. Unlike workflow rules, Flows are far more flexible. They’re also more complicated. But it allows you to structure what is essentially a collection of rules, with the added ability to delete information as an action.
Whenever possible, use Flows rather than workflow rules. It’ll force you to think through your org’s configuration and help you avoid technical debt.
3. Code automation (Apex) is powerful, but fragile
Apex code is the king of automation. If something can’t be done in the interface, it can generally be accomplished with code.
However, avoid using Apex, aka “one-off code.” Custom code creates technical debt the same way that rules do—as your org evolves, the code won’t, and it becomes a colossal maintenance burden, as well as a risk. If someone who wrote that code leaves your organization and didn’t document it, an update could overwrite it and it’d be gone forever.
4. API automation can make managing Salesforce far easier
You can also automate Salesforce actions via other tools thanks to its API. Salto is one such system, and allows you to de-risk changes and speed up management.
Here’s how it works: Salto allows you to avoid hunting for things in the Salesforce interface, and instead, see one blueprint of all your configurations and metadata. That means you can:
- See how your instance is configured
- Search for configurations
- Duplicate and reuse patterns
- Save multiple versions of your environment
- Easily push changes into production
The Josh Thorngren, VP of Growth at Torq, found it reduced Salesforce deployment effort by 75%.
Importantly, Salto also allows you to conduct impact analysis. Salesforce’s native “where is this used” functionality is limited to custom fields and it doesn’t cover all dependencies. Salto allows for “where is this used” (aka impact analysis) functionality across all metadata types, so you’ll know if the automation you’re about to apply will have unintended consequences.
Automating Salesforce to save time
There is good Salesforce process automation and there is bad Salesforce process automation, and the difference is whether you’ve got the system magnifying an efficient system or an inefficient system.
It’s of course difficult to know which is which while you’re creating rules. But that’s why interfaces like Salesforce Flow and Salto help you apply rigor and act more like a product manager.
The Salesforce Architect site also offers an extensive guide that provides recommendations and rationale for which tools they believe are the most appropriate for various triggered automation use cases.
These tools give you the ability to triage requests, diagram changes, and conduct impact analysis, so you only apply automation in ways that actually save time, and help your business grow.
What’s next?
Knuckles has suggestions
Enterprise App Configuration. Re-Imagined.
© Copyright Salto 2024 | Various trademarks held by their respective owners
