Service Automation

Allow requesting roles (bundled products) for end users with dependency-aware provisioning and deprovisioning
When using the self-service functionality in HelloID Service Automation, end users currently request individual products one at a time. While this works functionally, it can be inefficient and does not align well with real-world scenarios where access is typically granted based on roles or job functions. In many organizations, access to applications and services is grouped into roles (e.g. department roles, project roles, or job-based access). These roles often consist of multiple underlying products. Currently, end users must request each product individually, which increases complexity and does not reflect how access is logically structured. Requested Enhancement Introduce the ability for administrators to define roles that consist of one or more products, and allow end users to request these roles through the self-service portal. When a role is requested: The end user submits a single request for the role HelloID provisions all underlying products linked to that role Each product has its own workflow or there is a workflow defined at the role level Additionally, the system should support dependency-aware deprovisioning: When a role is revoked, HelloID evaluates whether underlying products are still assigned via other roles A product should only be deprovisioned when it is no longer linked to any active role or assignment for that user This ensures that access is not unintentionally removed when multiple roles grant the same product Example Scenario An employee requests the “Finance Employee” role via self-service. This role includes access to: Financial system Reporting tool Shared finance drive HelloID provisions all associated products. Later, the employee also receives a “Project Controller” role, which includes the reporting tool. When the “Finance Employee” role is revoked, HelloID detects that the reporting tool is still assigned through the “Project Controller” role and does not remove access. Only when the last role granting that product is removed will the product be deprovisioned. Business Value This improvement aligns access management with real-world role-based access models, reduces the number of individual requests for end users, and improves usability of the self-service portal. It also increases reliability and governance by preventing unintended access removal through dependency-aware deprovisioning. Additionally, it reduces administrative overhead by allowing administrators to centrally manage product groupings via roles instead of maintaining large numbers of individual product requests.
0
Allow delegated requester configuration for users
Introduce the ability to configure a delegated requester for a user by assigning a group. Users who are members of this group should be able to submit requests on behalf of the configured user. This allows certain users to create requests for another user without giving them approval rights. The delegated requester should only be able to submit requests and not approve them. This functionality is similar to part of the behavior that managers currently have, where they can submit requests for their employees. Requested Enhancement Allow administrators to configure a delegated requester for a user by assigning a group. Members of this group should be able to submit requests on behalf of the configured user. The delegated requester should only have permission to submit requests and should not receive any approval permissions. It is important to clearly distinguish this functionality from delegated approvers. Delegated approver functionality allows someone to approve requests in addition to or on behalf of the manager. Delegated requester functionality would only allow someone to submit requests on behalf of another user. This configuration should also be manageable through the HelloID API so that delegated requester assignments can be automated or integrated with external systems. Example Scenario A common scenario is that the service desk submits access requests on behalf of users. For example, a service desk employee may request access to applications or resources for another employee. By configuring a delegated requester group for a user or department, service desk employees who are members of that group would be able to submit requests on behalf of the user without receiving approval permissions. Use Case / User Story As an administrator, I want to configure delegated requesters for a user so that designated users, such as service desk employees, can submit requests on behalf of that user without granting them approval rights. Business Value This functionality provides more flexibility in request delegation and better reflects real organizational processes where service desk employees, assistants, or coordinators often submit requests on behalf of others. It also ensures that request submission and approval responsibilities remain clearly separated.
0
Load More