tenfold meets Service Management
Besides tenfold, our customers often choose to use different service management solutions for identity and access management (IAM) purposes. Mostly, these solutions are used to map out incident, request and change management processes. In these processes, there are numerous touch points with tenfold’s core functions, such as making requests for new accounts or permissions. The question is: how can we harmonize these systems with one another to get the most out of each solution? Two scenarios have emerged as possible solutions.
tenfold meets Service Management
tenfold as front-end
When the service management (or helpdesk) solution in use does not provide any self-service functions, like the ability to request specific resources (e.g. accounts, permissions, etc.), tenfold can be implemented as a front-end solution for end users. Through the tenfold user interface, it is possible to request new permissions or accounts for different target systems.
Provided that there is a connector available between tenfold and the relevant system (e.g. Active Directory, Fileserver, Exchange, SAP or other business applications), the requested resources can be distributed automatically, in which case no further manual operations are necessary.
If certain systems (or partial steps) cannot – or should not – be automated, it is possible to set tenfold to generate a ticket that requests manual execution. tenfold remembers the ticket number to prevent any gaps in the documentation flow. When the manual task has been completed and the ticket is closed, tenfold automatically closes the corresponding request as well. This scenario has been put into practice for some of our customer projects: TopDesk, OTRS and SAP Solution Manager.
tenfold as back-end
If the service management application in question provides its own self-service request management functions (e.g. in form of a service catalogue), the situation is obviously quite different. In this case, customers will usually opt to use this system as their front-end solution. This decision makes sense because it means that there is only one interface for the ticket module of the service management application that users must become accustomed to – one interface that allows them to complete all requests (e.g. requests for new resources, error and problem reports, etc.).
In this case, tenfold is often implemented as the back-end system, which means that its purpose is the technical provision of requested resources. Users are able to order new resources (permissions in the Active Directory, on file servers, in SAP or other in ERP applications) through the service catalogue, while transparency is always maintained.
tenfold is contacted through one of the numerous interfaces (API) and automatically provides the demanded resources. In this case, it is possible to illustrate the permission workflow either in the service management solution or in tenfold directly. Reference projects for this scenario have been realized for the service management solution iET.
Summary
tenfold can be implemented individually, according to your desired scenario and needs. If no self-service portal exists, tenfold can provide a user-friendly interface for conducting resource requests. If self-service is mapped by another portal, tenfold can be implemented for permission workflows and the provisioning process.
Furthermore, tenfold improves the reporting capabilities for existing permissions, which are reviewed on a regular basis, thereby also improving compliance.
Our No-Code Solution Makes IAM Easy.
Start Your Free Trial Today!