Example delegated administration with domain specific policies

The following example illustrates delegated administration with domain-specific policies.

In this hierarchy David Loo is in the Database domain and Don Goodliffe is in theDatabase/Database San Diego domain. To begin, David Loo makes a change to the global assignment policy.

Then Don Goodliffe also makes a change to the same policy.Initially, all assignment rules have a global domain as shown below:

Figure 1. Global domain rules

If David Loo updates the assignment rule for Database or Software, the following list appears:

Figure 2. Database domain-specific rules

The following policy changes occur:

  • When the policy is chosen and updated, the system detects that David Loo is not at the right level of the hierarchy to change this record. Therefore, the update is changed into an insert, and a new record is created.
  • The new policy has the same name (Database or Software).

Notice that this policy is in the Database domain and overrides the policy that previously applied (Database or Software).Notice that there are now two policy entries with the same name. Because this is not desirable, David opens the record and changes the name to something appropriate. After the update, the list appears as follows.

Figure 3. Renamed database or software to database specific policy

This time, the record being updated is at the same level in the domain hierarchy as the user, so the record is updated with a more appropriate name. Here is the resulting rule. Notice that database incidents are directly assigned to David.

Figure 4. Database specific policy assignment rule

If a new incident is created in the Database domain or lower in the hierarchy, the new rule is applied. It has overridden the global assignment rule. If a new incident is created in the global domain or any other domain not within the Database domain hierarchy, then the global rule applies.

In the following scenario, Don Goodliffe, in the Database/Database San Diego domain hierarchy, decides that database incidents created in his domain should be assigned to him rather than to David Loo. As an administrator, Don Goodliffe starts out with the following assignment policy:

Figure 5. Don Goodliffe's starting view of assignment rules

Notice that this level of the hierarchy starts out with the policy established at the parent level (the Database domain). After changing the Database-Specific Policy, the list look like this:

Figure 6. Database San Diego rules override Database-specific policy rules

Again, the attempted update is changed automatically to an insert, and the override value is supplied to indicate that the higher-level policy is being overridden. Here is the resulting rule; it shows that database incidents created in the Database San Diego domain are assigned to Don Goodliffe.

Figure 7. San Diego specific policy

The result of the above customization is:

  • A database incident from the Database San Diego domain is assigned to Don Goodliffe.
  • A database incident from the Database hierarchy other than Database San Diego is assigned to David Loo.
  • A database incident from any other domain, including global, is assigned to the system administrator.

The above customizations all show changes to higher-level policy. However, new policy can also be created at any level of the domain hierarchy.

During a transaction, the current user's domain normally determines the policy to load. For example when a user in the Database domain updates an incident, the Database domain is used for business rules and policies even if the incident record was originally created in the Database San Diego domain. By default, the user's domain supersedes the record's domain.

There is a system setting that can change this behavior. If Using the Current Record's Domain Instead of the Current User's Domain is set to true, then the above behavior is reversed. The domain of the record is used to determine which policy to load, not the domain of the user. For example if a user in the Database domain updates an incident that is in the Database San Diego domain, then the business rules and policy that exist for Database San Diego are executed. The domain of the user still determines the records that are visible to the user, and the domain of the user sets the domain for records that user creates, but is not a factor in determining rules and policies.