8Assignment Rule Administration for Delegated Assignment
Assignment Rule Administration for Delegated Assignment
This chapter explains how to delegate assignment rules to others, and how others can inherit and further define these delegated rules. The tasks explained in this chapter are for delegated administrators (DAs), and as such, the procedures are documented using the Administration - Delegated Assignment screen and views.
The topics in this chapter are organized to present information in a sequence roughly corresponding to the order in which you are likely to be concerned with the subjects described when using delegated assignment. However, your company might follow a different process according to its business requirements for using Siebel Assignment Manager.
This chapter includes the following topics:
Automating the Menu Options: Regenerate Denormalized Rule Hierarchy and Rule Group Hierarchy
Process of Inheriting and Refining Delegated Assignment Rules
About Delegated Assignment
Delegated assignment provides people (positions) other than the assignment administrator the ability to create and manage assignment rules. The highest assignment administrator (AA) position can delegate rule administration to other positions and partners to route leads, activities, accounts, and other objects to employees or positions. These delegates are known as DAs. DAs can, in turn, delegate assignment rule administration to other DAs. This hierarchical assignment rule inheritance feature might be suitable for sales organizations and organizations that work closely with partners.
Delegated assignment allows AAs the ability to enforce core business logic using rule inheritance, while allowing delegated administrators (DAs) the ability to further refine that logic and specialize their assignment rules for their unique circumstances.
However, DAs can only inherit rules from their parent rule group. When inheriting a rule, DAs are allowed to choose only from rules in the parent rule group in which the owner of their rule group is currently a candidate (employee or position). The logic specified on a rule is enforced on all inherited rules by making sure that the rule contains nonremovable and noneditable copies of all criteria from the parent rule. DAs can further refine the rule's logic, by adding new criteria to inherited rules by either creating new criteria or by adding and modifying criteria templates. DAs can also delete any rule they choose to inherit from the parent rule group. Candidates (employees and positions) of rules are not inherited, so users can choose anyone their organization visibility allows as a candidate. Workload criteria, organization workload criteria, and organizations are not inherited.
If you plan to use delegated assignment, then the highest AA position must first prepare the assignment rules for inheritance. After a rule is inherited and changes are made to the original rule (such as adding criteria to, expiring, or deleting the rule), those changes are propagated down the hierarchy to all rules that were inherited from it.
This topic contains the following information:
Scenario for Delegated Assignment
This topic is part of About Delegated Assignment.
This scenario gives one example of how you can dynamically assign candidates. You might use this feature differently, depending on your business model.
For this scenario, candidates are assigned to an activity based on the information provided in the following table. The numbers at the start of the table correspond to the numbered list following the table.
1 Asset Team Member |
Type |
2 Account Team Member |
Type |
3 Service Region |
4 Skills |
---|---|---|---|---|---|
Employee 1 |
Primary |
Employee 3 |
Primary |
Employee 1 |
ENU |
Employee 2 |
Secondary |
Employee 6 |
Secondary |
Employee 2 |
FRA |
Employee 3 |
Tertiary |
Employee 2 |
Tertiary |
Employee 3 |
Not applicable |
Employee 4 |
Tech Support |
Employee 4 |
Tech Support |
Employee 7 |
Not applicable |
Employee 5 |
Never Send |
Employee 7 |
Never Send |
Employee 8 |
Not applicable |
The activity has an asset team and each employee in that team has a type. All the employees in this team are eligible candidates for the activity. The employees are scored based on their type and the following assignment rules:
If Organization = Americas, then the primary score = 100.
If Organization = Europe, then the primary score = 50.
Based on the rules and their type, assume that the asset team scores are:
Employee 1 = 100
Employee 2 = 75
Employee 3 = 50
Employee 4 = 25
Employee 5 = 0
The activity has an account team and each employee in that team has a type. All the employees in this team are eligible candidates for this activity. The employees are scored based on their type.
The account team scores are:
Employee 3 = 80
Employee 6 = 60
Employee 2 = 30
Employee 4 = 10
Employee 7 = 0
The activity has a service region, and the service region has employees. All employees are eligible candidates for skill matching. You match activity skills and employee skills, but you can specify other matching criteria as well.
Employee 1 = 100
Employee 2 = 150
Employee 3 = 75
Employee 7 = 200
Employee 8 = 25
This step determines the final list of candidates for this activity. This list is the union of the employees from all previous three lists, and employee scores are added if they exist in more than one list.
The final list of candidates for this activity with their corresponding scores is:
Employee 1 = 200 (100 + 100)
Employee 2 = 255 (75 + 30 + 150)
Employee 3 = 205 (50 + 80 + 75)
Employee 4 = 35 (25 + 10)
Employee 5 = 0
Employee 6 = 60
Employee 7 = 200 (0 + 200)
Employee 8 = 25
All employees with a passing score pass the rule. In this example, if the minimum score for the rule is 200, then Employee 1, 2, 3, and 7 pass and Employee 2 is set as the primary because that employee has the highest score.
Sample Delegated Assignment Process Flowchart
This topic is part of About Delegated Assignment.
The following figure provides a sample process flowchart of the delegated assignment feature. Each of the process steps are explained in further detail later in this chapter.

This figure shows the following relationships:
Amy is the EVP of Sales and is the assignment administrator. Amy must first create root-level rule groups, child rule groups, and rules, and add criteria templates and owners of the child rule groups to the assignment rules before delegated assignment can be implemented.
Lance and Henry are Sales VPs and are delegated administrators (second-tier). Lance and Henry must first inherit rules in the rule group Amy created for their respective areas, and can then further refine and delegate those rules further down the hierarchy.
Rick and Sarah are Sales Managers and are delegated administrators (third-tier). Rick and Sarah inherit the rules created by Lance for their respective areas, and then further refine those rules for their sales representatives.
Robin and Sam are Partners and are delegated administrators (third-tier, similar to Rick and Sarah). Robin and Sam inherit the rules created by Henry for their respective areas, and then further refine those rules for their sales representatives.
Note: After a rule is inherited in child rule groups and changes are made to the original rule, such as adding criteria to, expiring, or even deleting the rule, those changes are propagated down the hierarchy to all rules that were inherited from it.
About Setting Up Assignment Rules for Delegation
This topic is part of About Delegated Assignment.
If you plan to use delegated assignment, then the highest AA position must first prepare the assignment rules for inheritance in addition to the tasks presented in Assignment Rule Administration
The highest AA position typically creates rules and rule criteria templates from which all other delegated rules and rule criteria are created using the Administration - Assignment views. DAs can then inherit these predefined rules and further refine those rules by adding new criteria or apply criteria templates criteria using the Administration - Delegated Assignment views. These refined rules can again be inherited and modified by other DAs at a lower level in the hierarchy, and so on. At each level in the hierarchy, administrators can assign designees to act on their behalf. Designees can view and edit rule groups (and the rules within those rules groups) on behalf of an AA or DA. Rule Group Explorer shows an example of this n-tier hierarchical relationship.
About Assignment Rule Group Hierarchy
A rule group is a group of categorized assignment rules. You might think of a rule group as similar to a territory. The delegated assignment feature provides a hierarchical (tree) distribution of rule groups, as shown in Rule Group Explorer. The logic defined in the rules in rule groups at the head of the hierarchy is enforced down the hierarchy, but can be refined.
This topic contains the following information, which describes rule group hierarchy in further detail.
See also the following topics:
Rule Group Explorer
This topic is part of About Assignment Rule Group Hierarchy.
The Rule Group Explorer is one of the views in the assignment administration screen. The Rule Group Explorer, shown in the following figure, is a graphical representation of the rule group hierarchy tree and provides a convenient way to navigate the entire rule group hierarchy. The relationships between parent and child rule groups is a hierarchy.

This figure shows the following relationships:
Root-level rule groups: Root-Level Rule Group 3, Root-Level Rule Group 2, Root-Level Rule Group.
Child rule groups and their characteristics:
Rule Groups (lists all child rule groups for the current rule group)
Rules
Designees
Inheritable Rules
For example, Rule Group 1 and Rule Group 2 are child rule groups for Rule Groups.
Rules in rule groups at the lower levels of a hierarchy are processed first, moving up one level each time no rule in the previous level passes. Within each level in the hierarchy, the rules are processed by ascending order of sequence number.
Administrators (AAs and DAs) use the Rule Group Explorer to create and maintain rule group hierarchies. Assignment administrators have organization visibility, so they see the rules for their specific organization or organizations. Typically, AAs use the Rule Group Explorer views in the Administration - Assignment screen but can also use the views in the Administration - Delegated Assignment screen.
Delegated administrators must use the My Rule Group Explorer view in the Administration - Delegated Assignment screen and can see only rule groups for which they are an owner or designee, and the rule groups and rules that appear in the subtree.
DAs can only create a new rule group below one for which they are the owner or designee; this new rule group is a child rule group of the original rule. DAs can also create grandchild rule groups, great-grandchild rule groups, and so on.
Parent and Root-Level Rule Groups
This topic is part of About Assignment Rule Group Hierarchy.
A parent rule group is a rule group that directly precedes another rule group in the hierarchy. A root-level rule group is a rule group without a parent. For example, in the following image, RG 2 is the parent of RG 4, but RG 2 is not a root-level rule group. Only RG 1 is a root-level rule group, because it is the only rule group in the hierarchy that does not have a parent rule group (and, subsequently, is at the head of the hierarchy).
The following image provides a sample rule hierarchy that shows how parent and root rule groups relate to other rule groups in the same hierarchy.

This image shows the following relationships:
Rule groups that have no parent are root-level rule groups. There is only one root-level rule group for each hierarchy and that root-level rule group appears at the head of the hierarchy (RG1).
Note: Only assignment administrators (not delegated administrators) can create root-level rule groups.Rule groups that are parents to no other rule groups (rule groups with no child rule groups) are considered leaf rule groups and appear at the lower levels of the hierarchy (RG3, RG4, and RG5).
Rules at the leaf nodes are processed first by Assignment Manager. If none of those rules pass, then Assignment Manager processes rules in the set of rule groups that precedes the leaf nodes, and so on, until the root-level rule group is processed. This method of processing the rules ensures that, if a rule is inherited from one rule group to another, then the inherited rule is passed first.
Note: The Default Rule Group is a root-level rule group (has no parent) as well as a leaf node (has no child).
Assignment Owners and Designees
This topic is part of About Assignment Rule Group Hierarchy.
Siebel Assignment Manager uses ownership as a means to determine whether a particular rule is eligible for inheritance by a rule group. Each rule group must have an owner, and a rule group defaults to the creator (as owner) when a new rule group is created.
Owners can delegate their responsibility to designees with the same rights as an owner. A designee is an individual who can view and edit rule groups (and the rules within those rules groups) on behalf of an owner. The owner and the designees of a rule group are collectively known as delegated administrators (DAs).
Assignment Rule Inheritance
This topic is part of About Assignment Rule Group Hierarchy.
Rule inheritance allows assignment administrators (AAs) to enforce business logic, while allowing delegated administrators (DAs) to further refine that logic. In addition, inheritors of rules can refine those same rules and specialize them for their unique circumstances.
Criteria templates are special criteria that can be applied to inherited rules. Assignment Manager does not process criteria templates until an inheritor of an assignment rule chooses to apply a template to the inherited rule.
Rule Group Visibility and Permissions
This topic is part of About Assignment Rule Group Hierarchy.
AAs have visibility only for the rule groups (and the rules within those rule groups) for their specific organization (unless given permission to the All Rule Groups Across Organizations view). DAs have visibility only to the rule groups for which they are an owner (or designee) and each of their rule groups' subtrees. An owner of a particular rule group cannot be the owner (or designee) of a rule group lower in the hierarchy (subtree), but can be an owner (or designee) for rule groups in other hierarchies.
Automating the Menu Options: Regenerate Denormalized Rule Hierarchy and Rule Group Hierarchy
When Siebel Assignment Manager rules or rule groups are created through the user interface (see Creating Assignment Rule Groups and Creating Assignment Rules), the hierarchy is automatically maintained (that is, the tables are updated). However, whenever new Assignment Manager rules or rule groups are imported using Siebel Enterprise Integration Manager (EIM), the hierarchy must be regenerated.
The following menu options support regenerating rule hierarchy and rule group hierarchy:
Regenerate Denormalized Rule Group Hierarchy
Regenerate Denormalized Rule Hierarchy
The Siebel administrator or Assignment Manager administrator can use these options after a Siebel EIM import of the Assignment Manager rules or rule groups.
Regenerating Rule Groups Hierarchy
After importing the Assignment Manager rule groups, regenerate the rule group hierarchy.
To regenerate the rule group hierarchy
Navigate to the Administration - Assignment screen, and then the Rule Groups List view.
In the Rule Groups list, click Menu and then select Regenerate Denormalized Rule Group Hierarchy.
Regenerating Rule Hierarchy
After importing the Assignment Manager rules, regenerate the rule hierarchy.
To regenerate the rule hierarchy
Navigate to the Administration - Assignment screen, and then the Assignment Rules List view.
In the Assignment Rules list, click Menu and then select Regenerate Denormalized Rule Hierarchy.
About Invoking Regeneration Functions by Scripting
It is possible to invoke the functions Regenerate Denormalized Rule Group Hierarchy and Regenerate Denormalized Rule Hierarchy by scripting, using the corresponding business component method:
To regenerate rule groups hierarchy, invoke the method RegenerateDenormHierarchy on the Assignment Rule Group business component.
To regenerate rule hierarchy, invoke the method RegenerateDenormHierarchy on the Assignment Group business component.
This method can then be used to automate the call of these functions. For example, after a Siebel EIM batch, a workflow process can be launched, calling a custom business service that invokes the corresponding methods.
Example of the Core Script in Siebel eScript
The following are examples of the core script in Siebel eScript:
To regenerate rule groups hierarchy:
var busobj; var buscomp;
// Regenerate Rule Groups busobj=TheApplication().GetBusObject("Assignment"); buscomp=busobj.GetBusComp("Assignment Rule Group"); buscomp.InvokeMethod("RegenerateDenormHierarchy"); buscomp=null busobj=null
To regenerate the rule hierarchy:
var busobj; var buscomp;
// Regenerate Rules busobj=TheApplication().GetBusObject("Assignment"); buscomp=busobj.GetBusComp("Assignment Group"); buscomp.InvokeMethod("RegenerateDenormHierarchy"); buscomp=null busobj=null
Setting Up Assignment Responsibility for Designees
This topic explains how to add designees to an assignment rule group using the delegated assignment administration views. Use the following procedure if you want to delegate assignment responsibility to someone else (a designee).
To add a designee to an assignment rule group
Navigate to the Administration - Delegated Assignment screen, and then the Rule Group Explorer view.
In the Rule Group Explorer, expand the rule group for which you want to assign designees, and then click Designees.
In the My Rule Group Explorer list, click New.
In the Pick Positions dialog box, query for the position that you want to add to the rule group, and then click OK.
For more information about designees, see Process of Making an Assignment Rule Inheritable.
Process of Making an Assignment Rule Inheritable
By associating positions to the inheritance access list for an assignment rule, you make that rule inheritable for use by child rule groups (accessible by the rule group's owners and designees). Assignment administrators (AAs and DAs) can make an assignment rule inheritable as long as they have access to the rule.
To make assignment rules inheritable, you perform the following tasks:
Creating Child Assignment Rule Groups
You must first create a child rule group from a parent rule group, setting the Parent Rule Group field to the current rule group.
Adding Owners to the Inheritance Access List
After creating the child rule group, you add the owner of the child rule group to the inheritance access list for the rule.
Note: Unless the owner of a rule group is on the inheritance access list, that owner (and his or her designees) cannot inherit a rule.(Optional) Adding Criteria Templates to Assignment Rules
Optionally, you can add criteria templates to an assignment rule. DAs then have the option to apply the criteria templates to their inherited rules in lieu of creating new criteria.
Creating Child Assignment Rule Groups
This topic explains how to create a child assignment rule group using the delegated assignment administration views.
This task is a step in Process of Making an Assignment Rule Inheritable.
To create a child rule group
Navigate to the Administration - Delegated Assignment screen, and then the Rule Group Explorer view.
In the Rule Group Explorer, expand the rule group folder for which you want to define a child rule group, and then click Rule Groups.
In the My Rule Group Explorer list, click New.
In the new rule group record, click in the available fields to enter relevant information for the new group rule.
In the Name field, type a name for the child rule group.
In the Owner Position field, click the select button to query for an owner, and then click OK.
Note: You must specify an appropriate position for the owner. A position cannot be owner (or designee) for a rule group below one for which that position is already an owner or designee.
Adding Owners to the Inheritance Access List
This topic explains how to add owners to the inheritance access list for an assignment rule using the delegated assignment administration views. After owners are added to the inheritance access list of an assignment rule, inheritors of that rule can further refine and specialize that rule.
This task is a step in Process of Making an Assignment Rule Inheritable and Setting Up Assignment Responsibility for Designees.
To add an owner to the inheritance access list
Navigate to the Administration - Delegated Assignment screen, and then the Rule Group Explorer view.
In the Rule Group Explorer, expand the rule group in which the assignment rule resides, and then click Rules.
In the My Rule Group Explorer list, drill down on the assignment rule that you want to make inheritable, and then click the Inheritance Access view tab.
In the Inheritance Access List, click Synchronize.
Note: This action first deletes anyone from the list who is not an owner of a child rule group and then adds back only the owners of the child rule group. To prevent deletion, check the Lock During Synchronization checkbox next to a position before clicking Synchronize.Delete any positions from the list that you do not want to inherit rules.
Alternatively, you can add a single position:
In the Inheritance Access List, click New.
In the Pick Positions dialog box, query for the position that you want to give access, and then click OK.
Adding Criteria Templates to Assignment Rules
This task is a step in Process of Making an Assignment Rule Inheritable.
To add criteria templates to an assignment rule
Navigate to the Administration - Delegated Assignment screen, and then the Rule Group Explorer view.
In the Rule Group Explorer, select the assignment rule for which you want to add criteria templates.
Note: Depending on the rule, you might have to navigate down the hierarchy.In the My Rule Group Explorer list, drill down on the assignment rule, and then click the Criteria view tab (if not already active).
Add a new criterion.
For information about creating new criteria, see Process of Creating Assignment Criteria for Use in Assignment Rules.
Check the Template checkbox for the new criterion.
The new criterion template is now available for use with inherited rules.
Note: Assignment Manager does not process criteria templates until an inheritor chooses to apply a template to an assignment rule. When someone inherits from that rule, that person has the option to apply a template into an actual criterion (by checking the Create From Templates button in the Criteria view tab) instead of creating a new criterion.
Process of Inheriting and Refining Delegated Assignment Rules
To inherit and refine delegated assignment rules, you perform the following tasks:
Inherit an assignment rule.
For a procedure, see Inheriting Delegated Assignment Rules.
Add criteria to the inherited assignment rule by either creating new criteria or applying criteria templates.
For information about:
Creating new criteria, see Process of Creating Assignment Criteria for Use in Assignment Rules
Applying criteria templates, see Applying Criteria Templates to Inherited Assignment Rules
Add candidates to the assignment rule.
For information about adding candidates, see Choosing a Candidate as the Primary Assignee.
Inheriting Delegated Assignment Rules
This topic explains how to inherit an assignment rule using the delegated assignment administration views.
This task is a step in Process of Inheriting and Refining Delegated Assignment Rules.
To inherit a delegated assignment rule
Navigate to the Administration - Delegated Assignment screen, and then the Rule Group Explorer view.
In the Rule Group Explorer, expand the rule group for which you want to inherit rules, and then click Inheritable Rules.
Select one or more rules that you want to inherit, and then click Inherit Rules.
The rule (or rules) now appear as rules in the Rule Group Explorer view under Rules.
Applying Criteria Templates to Inherited Assignment Rules
This topic explains how to apply predefined criteria templates to inherited assignment rules using the delegated assignment administration views.
This task is a step in Process of Inheriting and Refining Delegated Assignment Rules and an optional step in Process of Making an Assignment Rule Inheritable.
To apply criteria templates to an assignment rule
Navigate to the Administration - Delegated Assignment screen, and then the Rule Group Explorer view.
In the Rule Group Explorer, expand the rule group in which the assignment rule resides and you want to apply criteria templates, and then click Rules.
Note: Depending on the rule, you might have to navigate down the hierarchy.In the My Rule Group Explorer list, drill down on the assignment rule for which you want to apply criteria templates, and then click Create From Templates.
In the Pick Criteria Templates dialog box, select the rule criterion that you want, and click OK.
Examples for Using Delegated Assignment
This topic provides examples of how delegated assignment might be used. You might use delegated assignment differently, depending on your business model. Your company might follow a different process according to its business requirements.
This topic contains the following information:
Scenario for Working with Delegated Administrators
This topic is part of Examples for Using Delegated Assignment.
A sales organization for a high tech company wants to create assignment rules that are inheritable and configurable by several different levels in the organization. The requirements are:
Handle large sales leads internally; handle small sales leads externally using partners
Promptly assign sales leads to the most qualified representative
Design complex assignment rules, making use of the delegated assignment inheritance and criteria templates features to allow for uncomplicated rule administration by persons at all levels
In this scenario, the Sales EVP, vice presidents, regional sales managers, partners, and sales representatives participate in delegated assignment for one rule group hierarchy, as shown in the following figure.
The following figure shows the following relationships:
Amy, Executive Vice President of Sales, is the assignment administrator (AA).
Two vice presidents report to Amy:
Lance, VP Direct Sales
Henry, VP Channel Sales
Lance and Henry are second-tier delegated administrators.
Two managers report to Lance:
Rick, Eastern Regional Manager
Sarah, Western Regional Manager
Rick and Sarah are third-tier delegated administrators (DAs).
Two partners report to Henry:
Robin, Partner 1
Sam, Partner 2
Robin and Sam are also third-tier delegated administrators (DAs).
Three Western regional sales representatives report to Sarah.
Three partner sales representatives report to Robin.

The following table provides sample responsibilities for each of the positions discussed previously.
Position |
Responsible for … |
---|---|
Executive Vice President (EVP) of Sales |
Making sure that large leads are handled by internal sales representatives and small leads are handled by partner sales representatives. |
VP Direct Sales |
Making sure that leads are routed to the correct regional manager. (Second-tier delegated administrator) |
VP Channel Sales |
Making sure that leads are routed to the correct partner. (Second-tier delegated administrator) |
Regional Manager |
Making sure that leads are routed to the best sales representative. (Third-tier delegated administrator) |
Partner |
Making sure that leads are routed to best partner employee (because the high tech company cannot determine which partner employee is best suited for the lead). (Fourth-tier delegated administrator) |
Delegated Assignment Example 1: Delegated Administration Tasks
This topic is part of Examples for Using Delegated Assignment.
Amy, the EVP and assignment administrator (AA), makes sure that large leads go to internal sales reps (by way of Lance, VP Direct Sales) and small leads go to channel partners (by way of Henry, VP Channel Sales).
To perform high-level delegated assignment administration tasks
Create a root-level rule group.
In this example, Amy organizes her assignment rules into a logical grouping. Rules that route leads are in one rule group.
For information about how to create a root-level rule group, see Creating Assignment Rule Groups.
Create a child rule group (or groups) with the root-level rule group as the parent.
In this example, Amy creates two rules groups, as follows:
Rule Group 1 with Owner = Lance
Rule Group 2 with Owner = Henry
Creating these rule groups gives Henry and Lance the ability to manage their own lead assignment rules for their subordinates.
For information about how to create a child rule group, see Creating Child Assignment Rule Groups.
Create an assignment rule (or rules)
Add a new assignment rule.
Assign candidates to the rule.
For information about adding candidates to assignment rules, see Choosing a Candidate as the Primary Assignee.
Add criteria templates to the rule.
Note: It is recommended that assignment administrators create criteria templates to assist DAs in rule creation. Doing this reduces the need for DAs to fully understand the steps required and implications of creating new logic.For information about adding criteria templates to assignment rules, see Adding Criteria Templates to Assignment Rules.
Add owners of the child rule groups to the inheritance access list for the assignment rule.
After owners are added to the inheritance access list, inheritors of those rules can refine and specialize the rules by adding criteria and candidates for their unique circumstances.
For information about adding owners to the inheritance access list for an assignment rule, see Adding Owners to the Inheritance Access List.
In this example, create the following assignment rules to route leads to Lance and Henry.
Task
Assignment Rule 1
Assignment Rule 2
Add criteria
Leads greater than $100,000
Leads less than $100,000
Assign candidates
Lance (VP Direct Sales)
Henry (VP Channel Sales)
Add owners to inheritance access list
Lance
Henry
These configured values help make sure that large leads are managed by internal sales and smaller leads are managed by partners.
(Optional) Create additional criteria templates.
Create new criteria for the assignment rule.
Click the Template flag for each new criteria created.
In this example, use the following criteria:
Add to Rule |
Assignment Rule 1 |
Assignment Rule 2 |
---|---|---|
Criteria Template 1 |
Product Line = Servers |
Not applicable |
Criteria Template 2 |
Product Line = PCs |
Not applicable |
Criteria Template 3 |
Product = Notebooks |
State = NY, CT, NJ |
Criteria Template 4 |
Product = Desktops |
State = WA, CA, OR, NV |
Criteria Template 5 |
Product = Peripherals |
Not applicable |
These configured values provide Lance and Henry with the ability to refine rules with predefined criteria instead of creating new criteria.
Delegated Assignment Example 2: Second-Tier Delegated Administration Tasks
This topic is part of Examples for Using Delegated Assignment.
Lance, VP of Direct Sales and a second-tier delegated administrator (DA), makes sure that the leads that are more than $100K are routed to the correct sales manager based on geography and territories:
Leads in the Eastern states go to Rick
Leads in the Western states go to Sarah
Henry, VP of Channel Sales and another second-tier DA, follows the same steps as Lance, except Henry uses different criteria templates to route leads based on product line, as follows:
Leads for PCs go to Robin (employee of Partner 1)
Leads for servers go to Sam (employee of Partner 2)
To perform second-tier delegated assignment administration tasks
In the Rule Group Explorer, select a rule group previously created by the assignment administrator.
In this example, Lance selects the rule group for which he is the owner (Rule Group 1).
Create a child rule group (or groups) with the current rule group as the parent.
In this example, Lance creates two rules groups, as follows:
Rule Group 10 with Owner = Rick; Parent Rule Group = Rule Group 1
Rule Group 20 with Owner = Sarah; Parent Rule Group = Rule Group 1
Creating these rule groups gives Rick and Sarah the ability to manage their own lead assignment rules for their subordinates.
For information about how to create a child rule group, see Creating Child Assignment Rule Groups.
Inherit assignment rule (or rules).
In this example, Lance inherits Amy's rule twice so that he can refine each rule to make sure that leads in the Eastern states go to Rick and leads in the Western states go to Sarah.
For information about inheriting an assignment rule, see Inheriting Delegated Assignment Rules.
Refine the inherited assignment rule (or rules).
Apply criteria templates.
See Applying Criteria Templates to Inherited Assignment Rules.
Add candidates.
See Choosing a Candidate as the Primary Assignee.
In this example, use the following information to refine the assignment rules. The first criterion was inherited from the original rule and is read only. The second criterion was applied from criteria templates.
Rule Data
Assignment Rule 10
Assignment Rule 20
Criteria
Leads greater than $100,000
Leads greater than $100,000
Criteria
State = NY, CT, NJ
State = WA, CA, OR, NV
Candidate
Rick
Sarah
Add owners of the child rule groups to the inheritance access list for each assignment rule.
See Adding Owners to the Inheritance Access List.
After you add Rick and Sarah to the inheritance access list for the appropriate assignment rule, Rick and Sarah can inherit the rules and further refine them by adding criteria and specifying candidates.
Delegated Assignment Example 3: Third-Tier Delegated Administration Tasks
This topic is part of Examples for Using Delegated Assignment.
Rick and Sarah are third-tier delegated administrators in the rule group hierarchy.
To perform third-tier delegated assignment administration tasks
Rick and Sarah follow the same steps as Lance in Delegated Assignment Example 2: Second-Tier Delegated Administration Tasks, except that Rick and Sarah:
Inherit Lance's rules (Assignment Rule 10 and 20), and refine those rules so that the leads are routed directly to sales representatives.
Do not have to create child rule groups (because they assign leads directly to representatives).
Delegated Assignment Example 4: Third-Tier Delegated Administration Tasks for Partners
This topic is part of Examples for Using Delegated Assignment.
Robin and Sam are third-tier partner delegated administrators. Robin must make sure that leads that have been assigned to Partner 1 are routed to the best sales representative and that no leads go unassigned.
To perform third-tier delegated assignment administration tasks for partners
In the Rule Group Explorer, select the rule group previously created by the second-tier delegated administrator (Henry, in this example).
In this example, assuming Henry created Assignment Rule 30 for Robin and Assignment Rule 40 for Sam, Robin selects Rule Group 30.
Inherit the assignment rule (or rules).
In this example, Robin inherits Henry's rule three times and refines each rule to make sure that leads are routed to one of Partner 1's three sales representatives.
For information about inheriting an assignment rule, see Inheriting Delegated Assignment Rules.
Refine the inherited rule (or rules).
Apply criteria templates.
See Applying Criteria Templates to Inherited Assignment Rules.
Add candidates.
Add owners to the inheritance access list for the assignment rule.
See Adding Owners to the Inheritance Access List.
In this example, use the following information. In this example, rule 30B inherits from rule 30A, and rule 30C inherits from either rule 30B or rule 30A. Therefore, the values for the first and second criteria are read-only for rules 30B and 30C. For the third criteria, Product = Desktops, new values from criteria templates were applied to rule 30B and rule 30C.
Apply to Rule |
Assignment Rule 30A |
Assignment Rule 30B |
Assignment Rule 30C |
---|---|---|---|
Criteria |
Leads greater than $100,000 |
Leads greater than $100,000 |
Leads greater than $100,000 |
Criteria |
Product Line = PCs |
Product Line = PCs |
Product Line = PCs |
Criteria |
Product = Desktops |
Product = Notebooks |
Product = Peripherals |
Candidate |
Partner 1 Sales Rep 1 |
Partner 1 Sales Rep 2 |
Partner 1 Sales Rep 3 |
Summary for Examples of Delegated Assignment Administration
This topic is part of Examples for Using Delegated Assignment.
The following bullet points further summarize the delegated assignment activities as they pertain to the examples provided:
The examples describe a four-level assignment model. However, this is no limit to the number of levels that the delegated assignment feature supports, and there is no limit to the number of branches in a level. In these examples, the levels are:
Level 1 = Amy
Level 2 = Lance, Henry
Level 3 = Rick, Sarah; Robin, Sam
Level 4 = Eastern and Western Sales Reps; Partner 1 and Partner 2 Sales Reps
Rule group hierarchies are executed from the bottom up (from the lower levels to the higher levels of the hierarchy). For example, Assignment Manager attempts to use Robin's rules to match a particular lead to a candidate before it tries to use Henry's rules. However, if Robin's rules fail, then Assignment Manager then tries Henry's rules, and assigns the lead to Robin, and so on up the hierarchy.
Each rule group owner can assign a designee.
Designees have the same responsibilities as an owner. You might want to delegate your ownership to someone else, such as an administrative assistant, to perform the tasks.
Each partner might assign one person as the delegated administrator (in these examples, either Robin or Sam) and that person would manage the partner's rule group. This same person should receive all leads that are not assigned to the partner's sales representatives.
AAs and DAs can create new criteria (you are not required to use criteria templates). However, it is recommended that the AA create criteria templates for the most common criteria to ease the learning curve for the DAs.