Stop Babysitting PowerShell: Enable Self-Service Without Losing Control

Your onboarding script creates the account, accepts the required parameters, and saves someone from repeating the same administrative steps.

Yet whenever a new employee joins, one of your admins still needs to run the script.

HR still has to submit a ticket. Someone in IT checks the details, supplies the parameters, and runs it. Missing information triggers another exchange. Account creation might take seconds, but the request still waits for someone who can execute it.

That dependency has consequences beyond onboarding. At healthcare provider Hirslanden, for example, an SQL engineer used to receive calls at night and on weekends because the help desk couldn’t resolve database problems independently. The expertise existed, but access to the solution depended on an expert being available.

Our webinar, “Stop Babysitting PowerShell: Enable Self-Service Without Losing Control,” explores how to break that dependency. Using employee onboarding as an example, it shows how HR can initiate account creation while IT retains control over the automation behind it.

Give users access to a perform defined task

Take for example a common situation: HR needs to create an Entra ID account for a new employee. They need a way to provide the relevant information and submit the request for execution.

In ScriptRunner, creating an Action makes a script available through an executable web form. The form is generated from the script’s PowerShell parameters, while administrators configure the execution target, credentials, and access.

In the onboarding example, parameters such as first name, last name, and group information become fields the user can complete. Microsoft Graph is the configured target for creating the Entra ID user.

Delegations then determine who can use the Action. An HR employee signing in as an end user sees the Actions made available to them, without access to the administrative configuration.

That gives HR a task they can initiate themselves. IT maintains the script and decides who can execute it, where it runs, and what access it uses.

Control the target and credentials behind it

A delegated user’s access to an Action should not require handing them the backend credentials that make it work.

ScriptRunner manages credentials separately from script code. Administrators can use configured credentials to connect to an execution target or inject a credential into a script parameter at runtime.

The webinar demonstrates both: a credential used to connect to Microsoft Graph, and a separate Active Directory script that accepts a PowerShell credential parameter.

For the onboarding workflow, this means HR can initiate the task while IT manages the authentication needed to carry it out. The person completing the form does not need to handle the backend credential.

A connected credential server provides a central place to manage those credentials. The webinar also covers encrypted local storage, while recommending a credential server to simplify maintenance across instances.

Make input requirements part of the form

A usable form should help people submit information the script can work with.

Validation defined in the PowerShell script can carry through to the generated form. In the onboarding demonstration, a ValidatePattern attribute rejects digits entered in the first-name field because they fail the configured regular expression.

That pattern is illustrative. Real employee names can contain spaces, apostrophes, hyphens, and characters from different writing systems. Your rules need to reflect the people and systems involved.

The benefit is catching input that fails those rules before execution. Where a requirement can be checked automatically, build that check into the Action so users can correct their own submissions.

For onboarding, this reduces avoidable exchanges with IT. Administrators still define the requirements, but they should not have to explain the same input error every time it occurs.

Keep the script behind the service manageable

Once people depend on an Action, the script behind it becomes part of a service. You need to know which version they are using and how changes will be maintained.

ScriptRunner’s central script repository brings scripts together through connected local or remote Git repositories. Administrators can organise scripts with tags, inspect change history, and return to an earlier version when needed.

That gives the onboarding Action a maintained source, rather than leaving it dependent on a file in someone’s workstation folder.

It also separates script development from everyday use. IT maintains the PowerShell logic while HR interacts with the task through its form. As more teams contribute automation, clear policies for access and delegation help keep those responsibilities defined.

See who ran the Action and what happened

Self-service will not eliminate every failure. When something goes wrong, IT needs enough information to investigate it.

ScriptRunner’s execution reports show the initiating user, execution target, and detailed logs. Administrators can review the run and investigate errors without relying solely on the requester’s description. Dashboards provide a broader operational view through execution counts and success rates. For a delegated onboarding Action, these help IT assess whether people are using the automation and whether it is running reliably.

Management reporting also estimates time and cost savings using configured manual execution times and hourly rates. Those figures depend on the assumptions you supply, so use realistic baselines.

For the original onboarding problem, there is another practical question to ask: how often does a routine request still need someone in IT to step in?

Stop being the handoff for every request

Let's go back to the new employee waiting for an account.

With the Action configured and delegated, HR can open the form, enter the required information, and initiate account creation. Validation catches inputs that fail the configured rules. The script runs against Microsoft Graph using credentials managed by IT, and execution reports let administrators review what happened.

IT still owns the automation: its logic, access, credentials, and maintenance. Its author no longer needs to be involved in every routine execution.

Start with one repeatable task. Define what users can do, configure the access it needs, validate its inputs, and make the results available for review. Then delegate it to the people who need it.

Watch “Stop Babysitting PowerShell: Enable Self-Service Without Losing Control” to see the onboarding workflow demonstrated in ScriptRunner.

‍