This recipe provides details on creating and managing the roles required for Change and Release Management using SCSM.
You must plan to meet the following prerequisites before you complete this task:
Process |
Process role |
SCSM Security role (template) |
AD group |
Categories (area) |
Change Management |
Change Initiators |
Change Initiator |
SCSM - CR Change Analysts |
Standard - infrastructure |
Change Management |
Change Owners |
Change Managers |
SCSM - CR Change Managers |
All Change Management categories |
Release Management |
Release Owners |
Release Managers |
SCSM - RR Release Managers Analysts |
All Release Management categories |
Follow these steps to create Change and Release management class security roles:
The How it works... section in the Creating and managing Service Request roles recipe is applicable to this recipe. You must plan specifically for the Change and Release management process.
There are two typical scenarios for Change and Release Management process roles in organizations:
In the first scenario, plan to use the AD groups created for the Incident Management roles as the assigned users of the Change and Release Management role. The authors recommend the best practice of creating dedicated groups by processing and adding the same users as members.
In the second scenario, plan the Change and Release Management roles using the RACI (Responsible, Accountable, Consulted and Informed) model as a guide. Use the agreed role plan to implement the SCSM role model.
Built-in security roles that you can use as templates are great for testing, as they have implied and inherited permissions over all objects by default.
The built-in roles provide a means to delegate SCSM security roles to the specific process areas. Plan to use custom roles to avoid granting unnecessary access to SCSM. The built-in roles are assigned global scope access to all work and configuration items. You must limit the scope of access using groups and views to avoid unplanned access to SCSM process areas.