Active Directory SLA for workflows

Human error is a major concern when it comes to cybersecurity. In organizations that rely on AD, it's important to use tools like ADManager Plus to set up workflows, which are essential to keep an eye on man-made errors.

ADManager Plus' AD workflow feature allows users to set up reviewer- and approver-based workflows whenever a technician tries to perform an action. This aids in getting a fresh set of eyes to avoid human errors and unsolicited actions. When more people are involved in a process, it's important to ensure that all actions are taken on time and that business continuity is not affected when someone is not available. What happens if a reviewer or approver is not available to perform a critical operation? Can user provisioning wait until the approver comes back from their vacation? As an answer all these woes, ADManager Plus has service-level agreements (SLAs) in AD workflows.

What is an SLA?

In terms of AD management, an SLA is the level of service expected from an admin or technician with respect to defined metrics and remediation actions when an SLA is not met. SLAs are a critical component in an AD environment when planning to delegate actions to others.

SLAs in AD workflows

SLAs in AD workflows help take appropriate actions on pending and time-sensitive requests in the most efficient manner. With ADManager Plus' SLA feature, users can configure the following:

• SLA Rule: Configure attributes based on which the workflow requests must be filtered and SLAs must be applied. For example, requests can be filtered based on the action, requester, priority, and other attributes.
• Response Time: Set the expected response time in terms of days, hours, or minutes according to organizational requirements. A user provisioning request may require a response time of two hours, while a password reset request must be completed within 15 minutes for optimal efficiency.
• Escalation: Configure what happens if a request is not completed within the specified Response Time. Choose to notify admins, reassign the request, change the priority, or change the status of the request. The highlight of this feature is the multi-level escalation. Users can configure multiple escalations to be executed at specified intervals. For example, reassign a password reset request to another technician with the priority set as high when the request is not resolved within 15 minutes.