Understanding user criteria for event types in Workforce Optimization for ITSM
Summarize
Summarized using AI
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.
Summary of Understanding User Criteria for Event Types in Workforce Optimization for ITSM
This section covers managing user access for event types like meetings, training, and time-off requests within the Workforce Optimization for ITSM. Users can have specific permissions (Create, Read, Write or Update, and Delete) controlled through inclusion and exclusion user criteria. By default, users have role-based access, but additional customization is possible.
Show less
Key Features
- CRUD Operations: Manage Create, Read, Update, and Delete rights for users, groups, or roles.
- User Criteria: Set specific access for team members or groups to enhance flexibility beyond role-based access.
- Access Evaluation Logic: Access is determined first by exclusion criteria, followed by inclusion criteria, with exclusion having precedence.
Key Outcomes
By implementing user criteria for event types, customers can:
- Tailor event access for specific users or groups, ensuring relevant permissions.
- Verify the access rights of team members to confirm they have the proper permissions for managing events.
Manage user access for any event type such as meeting, training, and time-off requests in the team calendar.
You can include or exclude Create, Read, Write or Update, and Delete (CRUD) rights for event types using the inclusion and exclusion user criteria access. You can perform the CRUD operations for users, groups, or roles.
Note:
By default:
- Users have role-based access to manage event types.
- Team members don’t have read-access to events of type Actual work.
The flow diagram shows the logic on how inclusion and exclusion user criteria access work for event types.
How inclusion and exclusion user criteria access works
When the user criteria rules get evaluated, it's done in the following order:
- The system first evaluates the exclusion access for each criteria.
- If the exclusion access for a CRUD operation is set to true, then the system evaluates the user criteria.
- If the user doesn’t have access based on their role, then the user is denied access for the specific CRUD operation.
- If the user isn’t denied access, then the system evaluates the inclusion criteria.
- If the exclusion access for a CRUD operation is set to false, then the system evaluates the inclusion criteria.
- If the exclusion access for a CRUD operation is set to true, then the system evaluates the user criteria.
- For the inclusion access, for a specific CRUD operation such as Create, the system checks if at least one of the inclusion user criteria is set to true. If yes, then the system evaluates the user
criteria based on the user's role access.
- If the user:
- Has access for the CRUD operation based on their user role, then the user can perform that action. For example, if the event type is training and the CRUD operation is Create then the user can create the training event types.
- Doesn’t have access for the CRUD operation based on their user role, then the user can’t perform that action.
- If at least one of the inclusion criteria isn’t set to true, the user doesn’t have access to the specific CRUD operation. In this example, the user can’t create the training event types.
- If the user:
Note:
The exclusion access always takes precedence over the inclusion access. If no inclusion or exclusion access is set, then the role-based access is used for managing event types.