skip to Main Content
Building Your First Routing Flow

Routing Flows allow you to customize actions to define what will happen to records in your database. Combined with a built process, you can trigger a flow and outline what changes/updates to automatically be made on specified records.

Lane Four’s quick start install includes a Lane Four Visual Routing flow that can be edited. Below outlines a use case for building your own Routing Flow.

From the Lane Four launcher, click the Routing Flow icon to the right of the page.

From the Flows page, click New Flow.

*We recommend building a single flow that will show all of your routing in one place. Typically a flow will include Lead, Account, and Contact routing decisions but other objects can be added as well. An example would be a flow that outlines how to route new Leads, Accounts and Contacts, which we will focus on for this use case.

To begin your flow, start with a Decision node. This will determine what you will be routing, in this example we will be routing Leads, Contacts and Accounts.

Using a Decision Node

Select Decision from the left menu and drag it to the main screen.  Label your decision and create Outcomes related to it. In this case, we are taking a record and defining it to be a Lead, Account or Contact. Therefore, the outcomes will be Lead, Contact and Account. This is telling the flow to identify what kind of record it is and defining how you want the Decision node to branch out.

For each outcome, you must specify what information will be used to define it. In our use case, we will use the Source in the form of a variable. The Source is a piece of information given to the Flow via a Process Builder (which will trigger this flow to begin). The process will classify the record as a Lead, Contact or Account (source) and send the information along to the flow, allowing the flow to then use it. In order to identify and use this information later in our flow, we will save it as a variable, in our example, varSource

Creating a Variable

Variables are used to store information to be used in other nodes of the flow. To create the variable,  first begin with naming your outcomes within the Decision Node, i.e. Lead/Contact/Account, and from the “When to Execute Outcome” drop down, select All Conditions Are Met. Under “Resource” click on the field and select New Resource.

The Resource Type will be Variable and the API Name should closely resembled the type of information being tracked in the variable. In our example, we are tracking the record source, therefore we will label it varSource. Adding “var” to the beginning will allow you to easily identify the variable for later use.

The Data Type will be Text and checking off both items under “Available outside the flow” will allow this variable to be used outside of this flow.

Click Save.

Once saved, on the Resource field back in the outcomes setup, type in the variable name (i.e. varSource) and select varSource.

You now need to define what the variable should be equal in order for an outcome to be chosen. In our example, we want to route Leads, Accounts and Contacts, so we will select the source to be “Lead,” “Account,” or “Contact.” 

*Do this for each outcome.

Connect Start to the Source Decision in your flow.

You can now define what should happen to records flowing through each outcome. As in, if a record is identified as a Lead, what do we want to happen to the record? 

Using Get Records Node

In this use case, we want to check if there is an existing account matching the lead in order to Auto Convert or assign it. For us to do that, we must first get more information on the incoming Lead record to check for a matched account. We use the Get Records node for this. 

Label your Get Records node accordingly. In our example, we will label it “Lookup Lead” because we want to use it to look up lead information that will be used to route lead records further.

The Object we are getting information from is a “Lead” and we want to get the LeadId to later use as an accurate way of ensuring the correct records are being updated. 

[Enter “ID” in the field space, operator should be “Equals” and for Value you will create a new Variable to store the Lead ID information. (Refer to Step 5 for Variable creation)]

How Many Records to Store should be “Only the first record” because each record will have a unique ID. 

Where to Store Field Values defines if you want to store various pieces of data in one variable or in separate variables. In our example, we will store in one. At this point, select what information to store in the Variable.

The Record Variable should be the one we just created, “varLeadId,” and you can then define the information to be stored in this variable.

Once saved, you can now connect the Source Decision to Get Records node and select the outcome of “Lead.” This is telling the flow that “if it is a Lead, let’s gather more information to make routing decisions”.

Next, we can use the newly stored information towards making a decision for the record. 

In our example, we will use it to identify if the Lead has a Matched Account. So we will select a Decision node and drag it into the flow. 

Label it accordingly and the outcomes of this decision will be a Yes or No. If yes, this means Lane Four has identified an account matching the lead. We use the field LFBN__Duplicate_Account__c which Lane Four fills in when the record first enters Salesforce if a matched account is found.

We use the operator “Starts With” and value “001” to identify that there is a duplicate account based on the ID number of the account. 

*Ensure you are selecting the LFBN Duplicate Account field that we have stored in the Lead variable. See sample above.

The Default Outcome of the decision can be labelled as No. This will tell the flow that if the LFBN Duplicate Field conditions are not met, then it does not have a Matched Account. 

Since we now have outlined how we identify a lead with/without a matched account, we must route the outcomes. For our use case, if the lead has a matched account ,we want to auto convert it to the existing matched account by using an Update Records node.

Using an Update Records Node

Update Records Nodes are used to update/make changes to a record.

Select Update Records and drag it into your flow, label it accordingly and select Lead as the object we will be updating. 

We also want to outline conditions to determine which records we are updating, in our example, we are updating Leads with the IDs stored in the Lead ID variable we previously created (varLeadID). Select Conditions are Met in the Conditions Requirement drop down and under Field type in Id, operator Equals and Value should be varLeadID.

We now want to identify what we will be updating in the records matching our condition. 

When a lead has a matched account, the following actions are commonly done:

  1. Auto-Convert lead to matched account
  2. Account-based assignment

Auto-Convert lead to matched account

Most common use cases will add a node in the Lane Four flow to convert a lead into the matched account found. To complete this action, we use the Lane Four “ Auto Convert Lead” checkbox field. The node added to the flow is used to check-off the Lane Four Auto Convert field, which will flag the profile to be converted. 

The Lane Four Convert Lead field name is labelled as LFBN__Auto_convert_Lead__c which you will look for in the Field area of the node, and set the Value to true.

Depending on your preferences, additional fields can be set to update when a Lead is converted.

Account based assignment

Another common option when a lead has a matching account, is to use account information for assignment of the lead, for example assigning ownership. To program your flow for ownership assignment based on the account owner, the Field would be OwnerId and the Value would be the AccountOwnerId (which must be information captured in a Get Records node of the Account and saved into a variable).



Let’s take a step back to the Matched Account Decision and now outline what happens when a matched account is not found.

In this use case, the next step is to measure if the incoming lead is an MQL for proper assignment.

To decide whether a lead is an MQL, drag a Decision node into your flow and name it accordingly. There will be 2 outcomes to this decision: Yes or No

In our example, we identify a lead as an MQL if it is a part of the Information Technology Industry: 

  1. IF YES, that means the Industry = Information Technology. (varLead1.Industry; make sure the Industry information is captured in the previously created Lead Get Records node)
  2. Relabel Default Outcome to No.

If the Lead is or inot an MQL below are other options to route the record:

  1. Round Robin Assignment:You can add an Update Records node to the flow; identify the conditions as Id = varLeadID; and you will be updating the Owner of the lead, therefore select OwnerID as the Field and paste the ID of the Skip Account Round Robin queue. You can find the queue ID under Setup.
  2. Region Based Assignment:To queue the Lead record for region assignment, add an Update Records node; identify the conditions as Id = varLeadID; then we want to check off the Lane Four Assign Region owner field so the record can be routed through the regions.

*This step requires you to set up Region Automation settings in your Lane Four app. Please see Region Automation documentation for more detail. 

Queue Assignment

  • To do so, select the field to be OwnerId and the value will be the ID number of the queue you’d like to use. You can find the ID by accessing the queue details via Setup.

For more information on building a Flow in Salesforce, visit the link below:

How to build a Routing Flow in Salesforce.

Back To Top