Selecting the Best Automations for Your GTM Processes

Manual tasks in your go-to-market (GTM) processes can be crippling, particularly when you’re trying to scale. As your business grows, manual tasks consume more than their proportionate share of resources, both in time and money, and are prone to error. Most importantly, manual tasks divert attention away from the selling- and revenue-related activities that truly add value.

GTM automation tools are critical enablers of any operational process. However, it is important to select the right tool for the right process at the right time. Just as you shouldn’t use a screwdriver to drive a nail into a wall, you shouldn’t use the less optimal automation tool simply because it’s the closest at hand or you have the most experience with it. This blog post will provide an overview of when to use Salesforce tools like Process Builder and Workflow Rules, and when you should automate with tools like LeanData solutions. 

Determine key process criteria 

Before I field a request to build out an automation, I first determine the requirements for effectively working out the process.

• What objects in Salesforce will this impact and how?
• What criteria in Salesforce do we need to reference?
• How does this relate to the automations currently in our system? Are they combinable?
• What auditing capabilities should exist, and where do failsafes need to be? (Stop a process, reverse it, or just audit it?)

Once there’s a firm handle on the answers to the questions above, it’s then time to determine which tool to use. Typically, the functionality and complexity of our GTM processes don’t go beyond that of Salesforce Workflow, Process Builder, or LeanData. 

Select the right automation tool in Salesforce

Workflow Rules perform automated actions when another condition, or a series of conditions, have taken place. A perfect example is an instruction based on an if/then statement. The best Workflow Rules are for simple and straightforward processes that don’t require as many calls on systems.

Don’t confuse Workflow Rules with Lead Assignment Rules or Case Assignment Rules in Salesforce. Assignment Rules should be thought of as “incoming” rules, as they use criteria to determine which Salesforce user becomes the owner of a record. Workflow Rules, on the other hand, are “outgoing” in nature, as they trigger actions like:

• Same-object field updates (i.e., from a contact record, you can only update that record’s fields)
• Sending emails
• Creating tasks

Workflow Rules are an option that won’t require an Apex code job and will run without any delay – unless of course, you want to set up a time-dependent action. It is generally easier to set up time delays in Workflows than Process Builder.

However, Workflow Rules can’t have multiple steps of evaluation or updates, nor can it update across objects. For instance, if I want to update “A” when criteria “A” is met, but then also update “B” if criteria “A” is not met – a single Workflow Rule can’t do that for me. It also can’t update an Account from a Contact record. This is where a Process Builder can come in handy.

Process Builder is a powerful Salesforce tool to build, automate, and customize processes. Its simple point-and-click graphical interface allows you to easily select objects and fields while setting up immediate or time-based actions. 

Process Builder is designed for a broader variety of use cases, including the following:

• Same- and related-object field updates or creations (i.e., from a contact record, you can update the contact, its account, or other records you can access via the object’s lookup fields)
• Exchanging data and writing updates across different processes
• Evaluating different sets of criteria in different steps

Process Builder does have limitations, however, and in particular it does require Apex calls. SFDC has Apex governor limits on both synchronous and asynchronous calls, and Salesforce Essentials (designed for use by small businesses) limits orgs to a maximum of five Process Builder flows total. It’s best to minimize your Process Builders, which I have suggestions for later in this post.

LeanData automated solutions 

Salesforce is great, and your business depends on it. However, Salesforce has certain inherent limitations, and that’s where managed applications in the AppExchange, like LeanData, come to the rescue. 

LeanData is the only enterprise-grade, Salesforce-native app to solve for your lead-to-account matching and routing challenges. As LeanData resides within your SFDC org, your data doesn’t have to go off platform and back on, ensuring it’s secure and your flows can proceed without costly time delays. With its solutions, LeanData is the preeminent leader in its category. Not because I write it, but because LeanData’s customers say it.  

LeanData Routing uses a drag-and-drop user interface that provides a visual depiction of your GTM processes. You simply build out your automated processes by connecting the nodes, which determine your criteria or actions like:

• Same-, related-, and matched-object field updates or creations
• Sending emails or Slack messages
• Assigning lead, contact, account, opportunity, or case records and/or fields to users and round robins
• Adding leads and contacts to automated interactions defined with your revenue-generating teams

Among Process Builder and Workflow Rules automation options, LeanData is the most capable in checking multiple criteria across your different processes and objects. When it comes to lead assignment, as soon as your organization deploys a hybrid GTM model of inbound, outbound, account-based, and more, LeanData Routing becomes indispensable, particularly with value-adds like service level agreement (SLA) compliance and reporting and Multi-Graph for autonomous business units and their unique processes. 

However, when it comes to your overall GTM process, perhaps the best feature of LeanData Routing is its relatively unsung audit log features, which allows LeanData to serve as a sort of “command center” for your entire tech stack. Audit logs show if and how your processes are working. If anything breaks anywhere along your process, audit logs are the best way of determining where, when, and why. It captures the time the process kicked off for the record, the values of the relevant fields when it happened, the path the record took through the process you built in Router, and the outcomes (both successes and failures).

Summary

In summary, let’s revisit my key criteria from above:

• What objects in Salesforce will this impact and how?

1. 1. 1. If it is a simple, same-object process, keep to Workflow Rules to minimize any Process Builder Apex calls or LeanData CCIO calls, which can be saved for more high priority processes.
      2. If the process intends to update related objects, it will require Process Builder or LeanData.

• What objects in Salesforce do we need to reference (criteria)?

1. 1. 1. The logic is parallel to thinking through question #1. Simple criteria favors Workflow Rules (i.e., send an email for an Opportunity field update).
      2. When checking against related objects, other tools are needed. While Process Builder can only check records via related lookup fields on the record, such as the Account on the Contact, LeanData can also match and check against indirectly related objects, such as an Activity on the Contact or an Opportunity on the Account.

• How does this relate to the automations currently in our system? Are they combinable?

1. 1. 1. Workflow Rules are simple but also hard to combine. It’s important to name and sort the related Workflow Rules accordingly.
      2. Consider limiting Process Builders to two per Object, one for when a record is created, and a second for when a record is created or edited (if needed). Descriptions and carefully thought out criteria can be added on to differentiate automation purposes within one build, serving wonders in saving a system from being overrun with Apex errors.
      3. If the process being built is related to Object routing and assignment, try to keep them all within LeanData Router.

• What auditing capabilities should exist, and where do failsafes need to be? (Stop a process, reverse it, or just audit it?)

1. 1. 1. For Workflow Rules and Process Builder, auditing is difficult unless field history tracking is turned on or an error email is eventually received. 
      2. LeanData is best in quality assurance of processes as it also tracks the successes, ensuring things are working as expected from point A to point Z. And, when things don’t work as intended, there are clear messages for when and why any particular point failed.