Considerations When Editing Inherited Roles

This topic describes some of the things to keep in mind when you edit inherited roles on the Active Policies page of the Sales and Service Access Management work area.

To add or remove a job role's access to object data, you have to know which policies provide the access. A job role can be assigned a policy in these ways:

• It can be assigned a policy directly

• It can inherit a policy indirectly from an inherited role

• It can receive the same policy from more than one role

The information on the Active Policies page lets you view all policies a job role is assigned, from all sources, for the selected object. For each policy in the Access Policies table, the Role Name field lists the role that the policy is associated with; this is either the top-level job role you selected on the Sales and Service Management page, or a duty role that the top-level role inherits.

You can't edit policies that are inherited from predefined duty roles because predefined roles can't be edited. But you can edit policies that are inherited from custom duty roles. If you edit a policy provided by an inherited custom duty role, keep in mind that if the custom duty role is also inherited, directly or indirectly, by other roles then the change you make to the policy also impacts these other roles.

To make sure that you don't inadvertently change the access provided by roles other than the top-level job role you're editing, a warning message alerts you if a policy change you're making impacts other roles. The message lists the names of all roles impacted by your edit, and prompts you to confirm whether or not you want to continue to make the change. Select one of these options:

• Click Yes to continue to apply the access change to the inherited custom role in either of these situations:

  • You want to make the access change to all the roles listed in the warning message.

  • You don't want to make the access change to all the roles listed in the warning message, but you do want to apply the access change to the job role you're editing now.

    In this situation, make a note of the roles listed in the message before clicking Yes. At a later time, you can directly update each role listed in the message to restore the access it provides to its original setting. This process can be time consuming if there are a number of roles affected by the edit of the inherited duty role so it's a good idea to avoid this situation if possible. For example, if you removed a privilege from the custom inherited role, you will have to manually add the privilege back to each job role listed in the message, or to the job role associated with each duty role listed in the message.

• Click No if you decide not to apply the access change to the inherited custom role. Instead, use these steps to implement the access change for the top-level job role only:

  1. Modify the role hierarchy of the top-level job role by removing the inherited custom role.

  2. Do one of the following:

     • Make a copy of the inherited custom duty role you removed using the Copy top role option, assign the copied duty role to the top-level job role, then edit the duty role as required.

     • Directly assign the job role with the access provided by the removed inherited duty role that you want to retain.