You can assign change roles to a person, group, company, or all users. To simplify maintaining change management security, you can assign change roles directly to the change object or inherit them through item role mapping from the subject item of the change object. For example, you can map the Design Engineer item role to the Change Design Engineer role for issues, change requests, and change orders. So users with the Design Engineer role on the subject item of the change request header will inherit the Change Design Engineer role as well. You can also assign a default role to all internal users with the site level profile ENG: Internal User Default Role for Changes. A role that is explicitly granted to a user for a change object is a direct role assignment. Roles inherited from an item are inherited role assignments.

All seeded item roles are mapped to seeded change object roles. User-created item roles do not have to be mapped to change roles. If you do not want a seeded item role mapped to a change role, edit that item role (such as Item Author) explicitly.

The change role assigned to a user for a change object (for example, issue, change request, change order) determines which actions that user can perform on the change object. For example, a user with an Approver role on a change request is granted the View Basic Change Information and Edit/Delete Change privileges. You can also specify which user-defined attribute groups a user can view and/or edit when granted a change role.

Following are the seeded change roles:

• Approver

• Assignee

• Creator

• Requestor

• Reviewer

   To assign change roles directly to the change object:

Change roles are assigned directly to the change object by the change type. When you defined your change types in Defining Header Types, you specified a workflow. Each workflow step with an Approval status requires at least one associated workflow template (see: Defining Workflow Templates). Each person, role, or group specified in the workflow template receives a role on the change object based on the approval routing activity. All Request Approval assignees get an Approver role. Request Comment and FYI assignees get a Reviewer role on the change object. You can also specify a Default Assigned To role for a person/group when you define a change type. The Assigned To person for every change object gets an Assignee role.

   To inherit change roles through item role mapping:

1. In the applications tree menu, click Roles.

2. On the Roles page, select the item object, enter the role name, and then click Go.

3. On the Role Search Results page, click the name link of the role for which you were searching.

4. On the Role: (Role Name) page, click Update in the Role Mappings region.

5. On the Role Mappings page, you can map each change object type to a specific change role.

6. Click Apply.

   To assign a default change role to all internal users:

You can assign a default role to all internal users with the site level profile option ENG: Internal User Default Role for Changes.

1. Within the System Administrator responsibility, click System.

2. In the System Profile Values window, search for and select the site level profile option ENG: Internal User Default Role for Changes.

3. In the Site field, select the default change role for the site from the list of values.

4. Save your work.

   To implement attribute group security for change management:

When implementing role-based change management security you can set up privileges to control the view and edit permissions for specific change management attribute groups. You can control which users can view and/or edit certain attribute groups for a change object by assigning a role granting those specific privileges. By default, a change role's View Basic Change Information and Edit/Delete Change privileges control whether you can view or edit attributes that are not controlled specifically at the attribute group level. In other words, when implementing change management security you do not have to specify a view or edit privilege for each attribute group.

Suppose your company is co-designing with your supplier a new motherboard for its next generation of desktop computers. To improve communication with your supplier on design changes to the motherboard, you would like to securely share change request information externally with your suppliers and contract manufacturers. The Supplier Engineer should only be able to view specific attribute groups.

1. Select the Application Developer responsibility, navigate to the Form Functions form, and create Form Functions for each privilege that controls view and edit permissions for the attribute groups. Specify "Change" or "Change Line" in the Object field for each Form Function.

   See: Creating Custom Privileges

2. Select the Development Manager responsibility and navigate to the Setup Workbench. On the Attribute Group Details page for each attribute group, specify the View Privilege and Edit Privilege in the Business Entities region.

3. On the Change Role Detail page, grant the privileges that you defined as Form Functions in the previous steps.