5.2.3 Designing assignment of access permissions

(1) Considerations about operation

Decide the rules for assigning access permissions, referring to the following examples:

• If you want to show the inquirer the status of the inquiry, grant him the View item permission for the relevant process work board.

  You can also separately create and manage process work boards for external disclosure of information and for internal investigation.

  Access permissions for the process work board for external disclosure of information:

  For inquirer: Grant the View item permission.

  For the person in charge of inquiries: Grant the View item, New item, Edit item, and Close item permissions.

  For the approver for the person in charge of inquiries: Grant the View item and Acknowledge item permissions.

  Access permissions for the process work board for internal investigation:

  Grant appropriate access permissions to workers for individual processes according to their work assignments.

  Also, grant the Escalation permission for the relevant process work board to the person in charge of inquiries so that Items can be escalated to the process work board for investigation.

• Grant the View item permission for the relevant process work board to the persons in charge of other processes so that they can view Items for reference.

• Grant the New item and Escalation permissions to only specified users or roles to prevent unspecified users or roles from registering Items.

• Grant the Acknowledge item permission for the relevant process work board to special persons so that only persons in special positions can acknowledge Items.

• Grant the Close item permission only to the process work board manager or to special users or roles to strictly control the closing of Items. This makes sure that Items are closed only after confirmation that they can really be closed.

• If you want to manage all the registered Items even if some of them were registered by mistake, grant the Delete item permission only to the process work board manager or those in special positions.

• If you want to temporarily grant access permissions for a specified process work board, add users corresponding to those access permissions. If you want to grant access permissions based on work assignments or departments, add roles corresponding to those access permissions.

• When you create a base system to process Items that are relevant to several systems, users are able to see Items with which they have no direct involvement. By assigning view permissions for individual Items, you can prevent users from seeing these Items. For details on how to set access permissions when view permissions are set for individual Items, see (5) Operation example (setting view permissions for individual Items).

• Specify an initial person in charge of status for individual process work boards. Assume that you have set the initial persons in charge of status. Then, when you enter a status while creating or editing an Item in the New item window or Edit item window, the Person in charge combo box automatically displays the initial person in charge of the entered status. Use the Edit permissions window to set the initial persons in charge of status.

To Page Top

(2) Operation example (managing operation status of service support)

You need to assign appropriate permissions to the key personnel (and their managers) who are in charge of incident management, problem management, change management, and release management of an in-house system in the information management department. This will enable them to manage the operation status of service support.

The following example illustrates a case in which the target system administrator (the person in charge of an in-house system in the information management department) and the information system administrator (a higher level administrator) check the operation status separately.

The information system administrator views the Item status of the entire in-house system, and checks whether there are any problematic systems. If there seems to be a problem (for example, there are too many Items held for a long time in a certain system), he or she directs the system administrator of the relevant system to take actions.

The target system administrator views the Item status of the system in his charge, and checks whether there are any problematic processes. The target system administrator checks the processes that have too many Items in the Discussing status or that have an Item for which the deadline for taking measures is approaching, and follows up with the manager of the process.

The following table describes the permissions required for individual administrators when the above operation is performed.

To Page Top

(3) Operation example (deciding an escalation route (escalation path))

You must consider an escalation route for each process (escalation path) separately from the consideration of the processing of each process. You can decide an escalation route by granting the Escalation permission to the persons in charge of the individual processes. Decide escalation routes and configure corresponding permission settings before starting operations.

The following description assumes the escalation route shown in the following figure.

In this example, an escalation route is set in the order of incident management, problem management, change management, and release management. Escalation is allowed for those in charge of the individual processes. In this case, set permissions in the following procedure.

1. Create a role for each process, and configure the setting so that those in charge of each process have the role for the corresponding process.

   

   If the persons in charge of the same process can have the same permissions, we recommend that you create a role and assign them to that role.

2. For each process, set whose escalation will be allowed.

   

   The escalation route will be fixed after the access permissions (which define who can escalate at which processes) are set.

If the escalation route is changed, as shown in the following figure, you must review the settings of who can initiate escalations and of the escalation-destination processes.

To Page Top

(4) Operation example (processing an Item)

If you put different people in charge of different processes based on an Item's processing flow, you must assign permissions appropriately so that the Item can be smoothly transferred between processes on JP1/Service Support. The following describes four operation examples that can be assumed according to the operational structure that processes an Item. Refer these examples for your design.

Tip

If the processing for an Item is transferred from a person in charge of a process to another person in charge of another process, assign to the person in charge of the transfer-destination process the access permissions for the Item before its status changes.

For example, assign the Close item permission and the Edit item permission or the Acknowledged^# status permission to the person who changes the Item status from Acknowledged to Close. After the person in charge of the transfer-source process finishes editing the Item and changes the status to Acknowledged, they must be able to specify the person in charge at the transfer-destination process.

You can also use email notification for smooth transfer of an Item.

#

Users who are granted the Edit item permission can edit Items in any status. Users who are granted a status permission can edit Items only in the corresponding status. If you want to strictly manage users who can handle Items according to the status of the Items, set status permissions.

To Page Top

(5) Operation example (setting view permissions for individual Items)

Some environments incorporate a base system to process Items that are relevant to several systems. In such an environment, you can hide irrelevant Items from a subset of users by enabling view permissions for individual Items in the process work board of the base system. To achieve this, you need to plan access permissions for the process work boards in each system, and decide which users and roles should be assigned view permissions for individual Items.

The following describes how to plan access permissions for process work boards when view permissions are set for individual Items. This example involves designing the roles and access permissions required to process Items in the Incident management process work boards in systems A, B, and C, and base system D.

1. Plan the access permissions required to process Items in the Incident management process work boards in systems A, B, and C.

   The following table shows an example of access permissions required to process Items in the Incident management process work boards of systems A, B, and C:

   System name: Process work board name	Role	Users who belong to the role	Access permission for process work board
   System A: Incident management	Role A1 (standard role)	User A1, User A2	View item Edit item Escalation
   	Role A2 (manager role)	User A3, User A4	View item Edit item Escalation Acknowledge item
   System B: Incident management	Role B1 (standard role)	User B1, User B2	View item Edit item Escalation
   	Role B2 (manager role)	User B3, User B4	View item Edit item Escalation Acknowledge item
   System C: Incident management	Role C1 (standard role)	User C1, User C2	View item Edit item Escalation
   	Role C2 (manager role)	User C3, User C4	View item Edit item Escalation Acknowledge item

2. Design the access permissions required to process Items in the Incident management process work board of base system D.

   At this point, you do not need to consider the processing of Items escalated from each of the other systems.

   The following table shows an example of access permissions required to process Items in the Incident management process work board of base system D:

   System name: Process work board name	Role	Users who belong to the role	Access permission for process work board
   Base system D: Incident management	Role D1 (standard role)	User D1, User D2	View item Edit item Escalation
   	Role D2 (manager role)	User D3, User D4	View item Edit item Escalation Acknowledge item

3. Design the roles and members required for incident management in base system D.

   You now need to design the roles that will be used to process the Items escalated from the other systems. In designing the roles required for incident management in base system D, you need to consider the members of the roles assigned to the process work boards of systems A, B, and C and base system D as an integrated whole.

   The following table shows an example of designing the roles and members required to process Items in the Incident management process work board of base system D.

   Role	Users who belong to the role	Description
   Role AD (integrated role)	User A1, User A2, User A3, User A4, User D1, User D2, User D3, User D4	A role that combines the users of system A and base system D.
   Role BD (integrated role)	User B1, User B2, User B3, User B4, User D1, User D2, User D3, User D4	A role that combines the users of system B and base system D.
   Role CD (integrated role)	User C1, User C2, User C3, User C4, User D1, User D2, User D3, User D4	A role that combines the users of system C and base system D.

4. Assign view permissions to the roles required for incident management in base system D that you designed in step 3.

   Redesign the roles, members, and access permissions required for incident management in base system D based on the roles, members, and access permissions you planned for each system in steps 1 to 3. The following table shows an example of the redesigned roles, members, and access permissions required for the Incident management process work board in base system D:

   System name: Process work board name	Role	Users who belong to the role	Access permission for process work board
   Base system D: Incident management	Role D1	User D1, User D2	View item Edit item Escalation
   	Role D2	User D3, User D4	View item Edit item Escalation Acknowledge item
   	Role AD (integrated role)	User A1, User A2, User A3, User A4, User D1, User D2, User D3, User D4	View item
   	Role BD (integrated role)	User B1, User B2, User B3, User B4, User D1, User D2, User D3, User D4	View item
   	Role CD (integrated role)	User C1, User C2, User C3, User C4, User D1, User D2, User D3, User D4	View item

The figure below shows an operation example of a system that uses the access permissions designed using the above steps. In this example, when escalating Item A1 of the Incident management process work board of system A to base system D, the operator sets Role AD as the Item view permission owner for Item A1. Although User B1 to User B4 and User C1 to User C4 have view permissions for Items registered in the Incident management process work board in base system D, they do not have view permissions for Item A1. Consequently, these users cannot view Item A1 registered in the Incident management process work board of base system D.

To Page Top