Assignment Policies

Assignment policies are used to automatically route leads, opportunities, accounts, and cases to the correct teams, individuals, and roles defined in your go-to-market plan. For good customer experience, getting the right information to the right role is key. All assignment policies have a routing engine that you can customize specifically according to how you go to market.

Interacting with the Design Module

The Motion Module uses the go to market design set up in the Design Module as a basis for the assignment policies. Territories created and people assigned in the Design Module show up as options for routing in the Motion policies.

Can I use the Motion module independently?

The Motion Module can function independently of the Design Module, but it won't be automatically linked to your go to market design. You will need to manually configure the rules in the Motion Module.

Types of Assignment Policies

In the Motion Module, you can use different assignment policies to route specific objects within your Salesforce instance. The following assignment policies are available:

Lead Routing
Account Routing
Contact Routing
Opportunity Routing
Case Routing
Subscription Routing

Routing Options

You can customize any of the policies listed above using the routing options enabled in the Motion Module based on coverage, capacity, team setup, or even skills. These routing options support flexible go-to-market designs that can be pushed to CRM without a hassle. When you add a new assignment policy, the routing options will be displayed in stages, which vary upon the object you're routing.

When Should I Use Assignment Policies?

With the routing options enabled with each assignment policy, you can do the following:

Territory Based Routing
This is where the territory an account is assigned to can be used to route the related objects such as contacts, opportunities, leads, subscriptions, etc. to the right owner.

Role-based Routing
This is where the various objects can be routed to various roles based on the status of the object. For example, the routing rule can be configured to send leads to an SDR team if the company is a prospect but send it to an account manager if the account is already a customer.

Skills-based Routing
Not every sales rep is equal. Do you want to route the customers from Spanish speaking countries to team members who can speak Spanish? Do you want to route Financial Services customers to team members familiar with the industry? You can do this using Skills-based routing.

Round Robin
This is where the various objects can be round-robin distributed to team members to distribute the workload equally. This can be used in combination with any of the rules above to optimize the allocation of work to the various teams and roles.

Route based on Logged in Status
Active logged in status can be used to route objects to team members. If your scenarios require immediate attention to leads, cases or contacts, this is an ideal way to route objects to team members who are logged into a call center type system.

Follow the Sun Routing
You can route objects to various teams around the world based on timing. Do you want leads to be routed to your team in Europe during European business hours and by the US team during US business hours? You can do this using the timing policy within the routing engine.

Delayed Routing
Do you want to route objects sometime after a particular event occurs? For example, do you want to route a lead 2 hours after creation if no one's picked it up? You can configure delayed routing by using the Scheduler component within the Motion package.

Capacity Based Routing
You can define policy around how many objects can be simultaneously routed to an individual as a way to manage capacity. Limits on capacity can be set based on:
1) Personal capacity - e.g. how many leads can one SDR handle
2) Daily, Hourly, Weekly capacity - e.g. how many leads can be routed to an individual based on these time periods
3) Global capacity - e.g. everyone can only have a max of 100 leads at any point in time.

As the individuals take action on these objects, that frees up capacity for them to receive more from the routing engine.

Account Family-Based Routing
Not only can you route based on the matched account information, you can also route objects based on the account family as well. For example, route all leads for a specific global account to the owner of the Ultimate Parent for appropriate allocation of work. In this case, the Roles on the ultimate parent associated with the matched account is used for routing the object.

Managing Account Families
The account family information can be automatically maintained within your CRM using the Account Hierarchies component of the Motion App.

Duplicate Management
The routing engine is able to handle duplicates by taking advantage of Salesforce's duplicate matching engine. A duplicate lead or contact can be:
1) Merged Automatically
2) Routed to the owner of the original record so that two reps aren't calling on the same contact.

Follow-up Policy
The routing engine does not just route and forget. It can follow up and make sure action is taken on the routed objects. You can configure policy around what happens if a routed object is not acted on. For example - you can configure a policy that re-routes a lead which has not been acted on by the person originally routed to - if no action is taken within 2 hours.

Understanding Routing

In general, when a best-matched account is found, and there are duplicate accounts that show up as matches, then the appropriate duplicate action will be taken. If no duplicates are found, then we autocovert the records. If the auto-convert criteria aren't matched, then we route by role and validate the role or person the record gets routed to. If skill-based routing is needed, we can use tags to route leads, accounts, and contacts to the correct place. Similar to best-matched accounts, we can route leads to territories themselves. We can see which node in the GTM hierarchy they get routed to in the policy status object in Salesforce using the GTM field.

Use the flowchart below to understand how the assignment policies are executed.

Use the flowchart below to understand how the assignment policies are executed.


Assignment Policies


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.