The following example illustrates delegated administration with domain-specific
policies.
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.
