.svg)
.svg)
A new employee starts on a Monday, but it takes the better part of that week to get them access to their accounts. Meanwhile, the long-gone employee they are replacing still has access. Either problem can occur in an IT team that already uses scripts to automate account management. The individual tasks run quickly, but the process still depends on people passing information, requesting approvals, and checking results.
This is where much of the hidden cost of manual IT operations processes sits. Scripts reduce the work needed to complete a task. To extend those savings across onboarding, offboarding, and access requests, teams must also connect the dots. End-to-end automation workflows bring the trigger, approval, system changes, verification, and final record into a single, controlled sequence.
Where does the cost hide?
Consider a typical onboarding request. HR creates a record, someone opens a ticket, and IT creates accounts, assigns licenses, adds group memberships, and prepares a mailbox. Your team may have scripts for every technical step. Even so, someone must copy the data, obtain approval, and decide when the next task can start. Each handoff adds staff effort and a period of waiting.
A 2024 internal audit at Shared Services Canada, the Canadian government’s IT service provider, illustrates the problem. Covering 1,889 departures between April 2022 and March 2023, the audit found separate systems and manual data transfers that caused entry errors. Only 154 of 744 access-revocation records (21%) met the responsible team’s one-day standard. On the onboarding side, equipment delivery delays prevented some new employees from starting work on schedule.
The cost also continues after a request is complete. A November 2024 audit at Veterans Affairs Canada examined two samples of 172 and 185 new accesses. Approval evidence was normally an email, yet only 50% and 49%, respectively, clearly had approvals attached. This does not mean that the remaining accesses lacked approval. It means the available records often failed to demonstrate approval clearly.
These findings concern two organizations, but they illustrate three distinct consequences: extra work to coordinate tasks, delays before the required outcome, and difficulty proving what happened. Faster scripts alone cannot resolve these problems while the handoffs remain manual.
What should a complete process deliver?
A better process needs to address all three consequences. It must carry information between systems, control when tasks run, and retain evidence of the result. This starts with a clear definition of completion: a request is complete when the required changes have been checked and recorded.
The CIS Critical Security Controls v8.1, Safeguards 6.1 and 6.2, provide a useful foundation. They describe granting and revoking access as processes that should be “preferably automated.” Safeguard 6.2 also calls for disabling accounts “immediately upon termination.” Meeting that objective depends on timely information about the departure as well as reliable account changes.
In a Microsoft ecosystem, an authorized HR event can start a workflow that carries validated data through Active Directory, Microsoft Entra ID, and Microsoft 365. Required approvals stay linked to the request, and tasks run in a defined order. The workflow checks each result, routes failures to the responsible team, and records what succeeded. Requesters can then see the status without asking an administrator to reconstruct it.
Many teams still have gaps between these systems. ScriptRunner’s State of Microsoft Automation 2026 benchmark surveyed 180 IT managers and senior system engineers at enterprises with at least 1,000 employees between October and December 2025. In that self-assessment, 83% reported less than full integration across ITSM, monitoring, and infrastructure tools. This helps explain why teams can have substantial automation and still spend time moving requests between systems.
How should IT leaders evaluate workflow automation?
The central question is whether an approach can manage the complete process from the initial request to a verified result. A successful account-creation demonstration answers only part of that question. The evaluation must also show how the request arrives, how approval is recorded, and what happens when a later step fails.
Use a real onboarding, offboarding, or access request to examine five areas:
Evaluation pointScripted tasks with manual handoffsEnd-to-end workflowTriggerA person reads the request and starts a task.An HR event or ticket starts the sequence.Approval evidenceStaff collect evidence from separate records.Approval remains linked to the execution record.Steps across systemsA person transfers data and starts each task.The workflow passes data between ordered tasks.VerificationA person checks whether each change worked.Defined checks confirm results and route failures.Time to changeStaff update scripts and handoff instructions separately.Staff update and test the process in one workflow.
Include an unavailable system or a failed account change in the demonstration. Check whether the process preserves completed work, identifies the failure, and gives someone responsibility for resolving it. These details determine how much manual coordination remains when a run encounters a problem.
Also test how easily the team can change the process. In the same benchmark, 25% needed weeks to build a new workflow and depended on developer availability. Adding an approval or replacing a task should be part of the evaluation. Existing scripts can remain useful building blocks, with the workflow managing their order and dependencies.
Turning an approved ITSM request into a controlled action using a governed execution layer provides the foundation. Onboarding, offboarding, and access requests build on that foundation: the workflow coordinates several actions across systems, manages their dependencies, and checks the final result.
Where does ScriptRunner fit?
ScriptRunner provides a way to connect those tasks while retaining execution controls and auditability. Its Workflow Engine, introduced in version 8.0, lets administrators combine existing ScriptRunner Actions in a visual designer with conditions and branches. Administrators define input forms, and help desk staff or end users can run delegated workflows without administrator rights on the target systems. Version 8.1 adds approval configuration for workflow actions.
The same approach connects execution with reporting. ITSM systems such as ServiceNow, Ivanti, and Matrix42 can start Actions through web service connectors and receive status and a result reference. Workflow runs produce a parent report and reports for their child Actions, helping teams trace the work performed.
As a this is a very recently released feature, case studies involving the Workflow Engine are not yet available. The value of reusing and delegating automated tasks, however, is illustrated by the the ScriptRunner deployment at IT services group Bechtle. The case study reports “30% time savings for 2nd and 3rd level” support teams. Although this case predates the Workflow Engine, it supports the value of implementing an execution layer. End-to-end workflows open the door to even greater savings.
Start with one process and measure the whole result
Choose one frequent process and follow it from the initial request to the confirmed outcome. Measure staff time, manual handoffs, approval delays, and corrections. Keep total waiting time separate from hands-on effort: a request that takes three days may contain only a few minutes of technical work.
Estimate direct labor cost from staff hours per request, hourly cost, and request volume. Track late access removal and missing approval evidence separately. Then define who can safely start delegated tasks and how the process fits your enterprise PowerShell automation approach.
This gives the team a practical basis for improvement. The hidden cost becomes visible in the work between tasks—and success becomes a faster, verifiable outcome for the complete request.