Delegated administration

Delegated administration allows administrators to set domain-specific policies.

The policies set lower in the domain hierarchy override policies set higher in the domain hierarchy. While in a domain, administrators can set domain-specific versions of these global policies and settings:

  • Client scripts
  • System policies
  • Application and module names
  • Application roles
  • Module filters
Warning: All users with the admin role have special access to all system features, functions, and data because administrators can override ACL rules and pass all role checks. Grant this privilege carefully.

When users have the admin role, then all policies in the instance are available to them regardless of the assigned domain. They can enter a specific domain, and then only policies in that domain or higher are visible and processed during a relevant transaction. When an administrator modifies a policy that is in a higher domain or the global domain, the system automatically creates a new record for that administrator's current domain. It does not modify the original policy, application, or module record. This new record overrides the original.

To make changes to a policy in a lower-level domain, go into that domain and modify the policy. This approach creates the new policy record in your domain that overrides the original, higher-level policy record.

Do not make changes on the higher-level policy and then change the Domain field on that policy. This approach does not create a policy record in your lower-level domain, nor does it keep the policy record for the higher-level domain.

The sys_overrides field indicates that a policy, application, or module at a lower level in the hierarchy overrides a record at a higher level. The system automatically sets this field when an administrator attempts to modify a policy, application, or module that belongs to another domain higher in the hierarchy. Again, rather than actually changing the higher level record, the attempted update is changed into an insert, and the sys_overrides field is set to indicate the higher level policy, application, or module that is being overridden. Later when the records for a relevant transaction are loaded, the overriding domain-specific policy, application, or module is used instead of the original.

Domains for delegated administration

By default, delegated administration always uses the record's domain to determine what policies to apply.

The record's domain takes precedence over the user's domain. If there are no policies in the record's domain, delegated administration checks for policies in the next highest level of the domain hierarchy. The search for domain policies continues up the domain hierarchy until reaching the global domain. If there are no domain policies lower in the domain hierarchy, delegated administration uses the policies for the global domain.

For example, Fred Luddy is a user in the Database domain who can see records in the Database: Atlanta, Database: San Diego, and NY DB child domains. When he opens a record in the Database: San Diego domain, delegated administration first checks for policies in the Database: San Diego domain. If there are no policies at this level of the domain hierarchy, delegated administration checks for policies from the Database domain. If there are no policies in the Database domain, delegated administration uses the global domain polices as there are no other domains higher in the domain hierarchy.

Example delegated administration with domain specific applications

The following example illustrates delegated administration with domain-specific applications and modules.

As the administrator of the Database domain, David Loo decides to customize the Configuration application. To start with, David reviews the modules available in the Configuration application module.

Figure 1. Starting view of the Configuration application

David decides to rename the Configuration application to CMDB and to allow the inventory_admin role to see the application.

Figure 2. Sample domain-specific changes to the Configuration application

Next, David decides to change the Incident application by activating the Open - in "New" State module and adding a new filter item to show open incidents in the Database category.

Figure 3. Sample domain-specific changes to the Open - "New" State module

This creates a new module entry in the application rather than overwriting the existing module in the global domain.

Figure 4. Domain-specific view of the Incident application

If another administrator from another domain, such as Fred Luddy, logs in and looks at the Configuration application, the settings from the global domain appear.

Figure 5. David Loo's view of applications
Figure 6. Fred Luddy's view of applications

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 the Database/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 7. Global domain rules

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

Figure 8. 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 9. 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 10. 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 11. 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 looks like this:

Figure 12. 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 13. 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.

Manually re-enable delegated administration

Delegated administration allows administrators in lower portions of the domain hierarchy to add domain-specific policies that override policies set higher in the domain hierarchy.

Before you begin

Role required: admin

About this task

By default, activating domain separation enables delegated administration. Use the following steps to manually re-enable delegated administration if it was previously disabled.

Procedure

  1. Navigate to Domain Admin > Configuration.
  2. For Enable delegated administration, select the Yes check box.
  3. Click Save.