Fullcast routing policies offer several stages, each of which can be switched on or off based on specific requirements. The order of these stages is important, as records progress through them sequentially. Toggling the stages on/off directly impacts the routing logic and process.
Before you begin
If you’re just getting started with routing, refer to Get started with routing to understand the overall process of implementing routing policies.
Route Using Best Matched Account (BMA) or Territory
Lead and Account Routing only
Purpose: This stage evaluates the record according to the same logic used in your territory structure. Optionally, you can enable BMA functionality to match records to existing accounts. This stage is only available for lead and account routing.
Best Matched Account: Determines which existing account in your CRM is the best match for the lead or account.
Territory Routing: Evaluates data fields on the record and processes them according to your territory rules to route them to a territory. For example, if you have a territory rule that uses an employee count field on the account, you can evaluate an equivalent field on the lead.
Requirements
This stage must be used with at least one other related stage: Role-based Routing or Round Robin Routing.
BMA and Territory routing require configuration in Salesforce Custom Metadata, refer to Configure Salesforce Custom Metadata for Fullcast Routing.
To construct detailed BMA logic, refer to Introduction to Best Match Account Functionality and Rules for Fuzzy Matching, How does Best Match Account work?, and Best Match Account Functionality with Fuzzy Logic.
Configuration Options
If an account cannot be matched, then match to a territory.
Enables basic territory-based routing
Checked by default when you enable the stage and cannot be unchecked.
Ignore Best Matched Account even when available (Lead Routing only)
Configuration of BMA / Territory Routing in a Lead Routing policy. Note the option to "Ignore Best Matched Account even when available” which is explained below.
Optional way to bypass best-matched account.
Assumption is that the account is in a territory different from where the rules would place it.
Use cases: One scenario is that your territory rules specify that child accounts follow parent accounts, so subsidiaries all end up in the same AE-based territory, but for your SDRs you want to have a more regional approach. In this case, you may prefer to route leads to SDRs according to geographic or firmographic data rather than to the territory where the parent account, and thus all subsidiaries, is located.
Update Account Teams (Account Routing only)
Configuration of BMA / Territory Routing in an Account Routing policy. Note the option to Update Account Teams which is explained below.
Updates the account team with the exporting roles on the territory where the account gets routed to
Use cases: if you want to update the full team instead of just the account owner.
Duplicate Processing
Purpose: This stage allows you to define how the system identifies and handles duplicate records.
Considerations: If you already have duplicate processing in another system, such as marketing automation, this step may be redundant, in which case it’d be best not to use it.
Requirements: Duplicate processing relies on Salesforce’s standard duplicate rules.
Configuration Options
There are slight variations in the configuration options according to record type. These are called out below.
Configuration for the Duplicate Processing stage of a lead routing policy. Note the option referencing contacts, which is explained below.
Find Duplicates within the last [number of] days with a [number]% match. Here you define what constitutes a duplicate. This works much like the match scores in Salesforce’s matching criteria. The percentage (% match) indicates how closely an incoming record matches an existing record.
If a duplicate is found, then [options]. Here you determine how to deal with the new lead based on the identified duplicate. These options are the same for all the choices in this policy stage.
Do Nothing: Leave the duplicate record as is. This lets the identified duplicate continue to exist and the routing record to proceed independently.
Route: Route the duplicate to the same owner as the identified duplicate record.
Merge: Merge the duplicate with the original record. This consolidates information but requires careful consideration of data integrity.
If a contact is found matching this lead, then [options]. (Lead Routing only)
Do nothing
Route to the contact owner
Convert and merge to the contact owner
If duplicates from the same domain are found, then [options]. Here you can create a different way to handle duplicates from the same domain (company). This could be useful, for example, in case routing where you would want to ensure that cases from the same domain, which could appear to be duplicates, get routed to the same owner.
Do nothing
Route to the same owner of the original
Auto Convert
Lead Routing only
Purpose: This stage automates the conversion of leads to contacts. You can create one condition that enables conversion to happen. The condition can be based on either the Lead or the associated Account. If all options of this stage are enabled, the outcome would be a lead gets converted to a contact with the same information as the lead, and an account gets created and the contact would get associated with the account.
Considerations: Auto-conversion can streamline lead management but requires careful setup to ensure accuracy and avoid premature conversions. If you do not have BMA well-tuned, you probably shouldn’t enable the auto-conversion of Leads to Accounts in this stage.
Requirements: The account-related aspects of this routing stage rely on the results of BMA processing.
Configuration Options
Auto convert lead to contact matching the following criteria on [lead/account].
Select Account or Lead
Define criteria/condition by inputting
A field from the record type selected above
A logical operator (equals, includes, etc.)
A field value that will trigger auto convert
If no account exists, then…
This step uses the BMA outcome from the BMA / Territory Routing stage. If no best matched account was previously identified, you have the option to create an account.
Create it
Do nothing
.png)
Configuration for the Auto Convert stage on a lead routing policy, where leads are automatically converted to contacts if the Account Type is Customer.
Role-Based Routing
Purpose: This stage routes records to either the account owner or individuals in specific teams roles, based on territory coverage assignments. Optionally, you can differentiate role-based routing according to account data.
Requirements: BMA/territory routing need to be enabled for this stage to execute correctly
Configuration Options
For Leads, Cases, Contacts, Opportunities you can choose between the following two options.
Route to the account owner
Route based on criteria on the account – this allows you to select one field and create different routing rules for different field values. Start by selecting the desired account field. Then, for each different field value, click the (+) button to add a field value and corresponding role.
For Accounts, you can only select one role from the territory coverage assignments to route new records to.
The configuration of Role-based routing for a lead routing policy, where the value of the Type field determines which role the lead gets routed to.
Round-Robin
Purpose: This stage distributes records evenly among a group of participants (users) or territories.
Requirements: To Round-Robin between Teams of participants, you must set up a team structure in the Teams module. Otherwise, you need to manually input user names.
Configuration Options
Participants vs Territories
Selecting Participants allows you to create the round-robin pools based on either Team structure or to manually add individual users
Selecting Territories allows you to create the round-robin pools by selecting specific levels or nodes in a territory, or manually adding territories
Weightage works like a ratio. Each member of the round-robin pool gets a number, which impacts the volume of records they will receive relative to the other members of the pool.
Skills refer to specific values configured in the Policy Handler and allow users to receive preference over another user if they have a skill that is needed for a specific record.
Vacation can be used to pause routing to a participant or territory. Once a participant or territory is added to a round robin pool, vacation dates can be added by clicking “manage” and inputting start and end dates of the leave.
Limits allow you to specify a maximum number of records in a given timeframe.
Additional Round-Robin Configurations: Additional options include skipping the stage if no matching skills are found, supporting agent login for round-robin routing, and limiting the total number of cases. For more detailed information, refer to Understand Fullcast Round-Robin Functionality.
Configuring the Round Robin Stage in a lead routing policy three different ways: by adding participants using a team structure, adding territories from your territory structure, and adding participants manually by selecting users.
Defaults and Record Tagging
Purpose: This stage allows you to specify what to do if the previous stages fail to route the record. It serves as a fallback. It also allows you to set up rules for automatically tagging routed records.
Configuration Options
Select either a Default User or Queue. Users are managed here in the policy stage, while Queues are managed in Salesforce. Since this is a failsafe, consider a setup that will guarantee the record can be routed successfully. That is, if you choose to use the “User” option, keep in mind that you will need to maintain the pool of users in Fullcast. Whereas if you choose to use the “Queue” option, you will need to manage the queue of users in Salesforce.
Field Updates are optional. Here you can select multiple fields to stamp on the record at the time of routing. This can be helpful for tracking purposes. The values that are available include things such as Territory Name.
.png)
Configuration of Default users & record tagging for a lead routing policy with default routing to a specific user and record tagging set to stamp the routing queue name in a field called System Modstamp.
Notifications via Chatter
Purpose: Notify users when a record is routed. When enabled, this will send a default notification message to the new owner of the record.
Configuration Options
Additional Text to Send in Notifications: Input a fixed text string to include in the Chatter Notification
Additional People Beside the Owner to Notify: Select additional users to include in the notification
.png)
Configuration of a lead routing policy with notifications including text specifying the name of the policy used in routing, as well as a notification to a specific user.