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"
"Sample Delegated Assignment Process Flowchart"
"About Setting Up Assignment Rules for Delegation"

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 Table 8-1. The numbers at the start of the table correspond to the numbered list following the table.

Table 8-1 Sample Data for Dynamic Candidates Assigned to an Activity

1Asset Team Member	Type	2Account Team Member	Type	3Service 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".

Figure 8-1 provides a sample process flowchart of the delegated assignment feature. Each of the process steps are explained in further detail later in this chapter.

Figure 8-1 Sample Process Flowchart for Delegated Assignment

Figure 8-1 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 Chapter 5, "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. Figure 8-2 shows an example of this n-tier hierarchical relationship.