Which Tickets to Automate, and the Review Before a Script Runs Anywhere

Three Tickets, Three Fates: What a Script Should and Shouldn't Own

Picture the ticket that made you think about automation in the first place. A client keeps asking you to add or remove mailboxes for the same handful of users, every week, same pattern. That's a script's job: it's repetitive, it's deterministic, and the failure mode is known. A short script that applies the same mailbox permissions every time is exactly what a script should own.

The second bucket is where a script could do the work, but the work touches a client environment with sensitive data, or the script is new and untested, or it would run unattended. That ticket gets scripted, but it gets a human gate before it runs.

The third bucket is the one nobody wants to admit. Some tickets need judgment: a user who says "I can't work" could mean a dozen different things, and no script should guess which. Those stay manual, and that's not a failure of automation. It's the correct call.

The hard part is deciding which bucket a ticket falls into. That's where the determinism test comes in.

The Determinism Test: Is It the Same Every Time?

Ask three questions about a ticket before you write a single line of script. Is the action fully deterministic, meaning the same input always produces the same correct output? Is the volume high enough to justify the maintenance? And is there zero judgment required about the client's intent?

If the answer to all three is yes, you have a scripting candidate. A script that clears a stuck print queue and restarts the spooler is deterministic: same action, same result, no client context needed. A ticket that says "user can't work" is not, because the action depends on what the user actually means.

The test has two edges that catch people. First, ambiguous user intent keeps a ticket manual. If the user's request could mean two different things and the wrong guess is harmful, a human has to interpret it. Second, client-specific exceptions keep a ticket manual. If one client's environment changes what the correct action is, the script can't know that without asking, and at that point it's not automation anymore.

Once you've passed a ticket through the determinism test, the next question is who gets to say yes before it runs on a client machine.

Who Approves Before a Script Runs?

My view is that every script change needs a human review before it touches any client machine, and that review is not a formality. A designated reviewer, usually the owner or service manager, checks three things: what the script change actually does, which client environments it will run against, and whether there are compliance implications in any of them. Patient data, regulated records, anything like that means the review is a compliance check, not a code review.

The review only works if the reviewer actually does those checks. A rubber stamp that approves every change without looking at the client context is worse than no review at all, because it gives you false confidence.

Treat reviewer time as a variable cost, not a fixed benchmark. A trivial one-line script change takes minutes to review. A script that touches a client's directory or patient records takes longer, and it should. The review time scales with the change's complexity and the reviewer's familiarity with the client environment.

For low-risk scripts, have a second technician who isn't the author do the peer review. For high-risk scripts, route through the service manager or whoever owns compliance. The principle is the same: someone other than the author, with client context, says yes before it runs.

When you've got that gate in place, the next question is where the approved scripts live so you can trace what ran and who changed it.

One Folder, One Owner: A Change Log for Every Script

Every script lives in one version-controlled folder, with one named owner and a change log that records who changed what, when, and why. The owner is the person who can approve changes to that script. The log is the audit trail that tells you which version ran on which client and who put it there.

This matters most when a script outlives the person who wrote it. Say you have a mailbox script owned by one technician. She updates it, logs the change, and later a client reports a problem. You check the log, you see version 3 ran on Tuesday, you compare it to version 2, and you know exactly what changed. Without the log, you're guessing.

The setup is simple: a shared drive or version control system everyone can reach, a naming convention, and a change log template. It's the enforcement that's hard. Changes made directly on a client machine and never recorded defeat the whole system, so make the log part of the workflow, not an afterthought.

A wiki page per script with a change history works fine if you don't want a formal tool. The point isn't the tool. The point is that no script runs unrecorded and every failure can be traced to a version and an owner.

This all sounds clean. Here's what happens when it breaks down.

When the Script Goes Wrong: The Honest Failure Modes

The whole approach fails in three ways, and they're all quiet.

First, the determinism test gets misapplied. A ticket looks repetitive but actually needs client judgment, you script it anyway, and the script makes the wrong call. The failure shows up as a client issue, and the script looks fine in the log because it ran exactly as written.

Second, the reviewer isn't available. The reviewer is away, nobody is cross-trained to cover the review, and an urgent script fix needs to go live. The choice is between running unreviewed or waiting, and waiting is the correct answer even when it hurts. If the review step becomes a bottleneck because there's no coverage, that's a staffing problem, not a reason to skip the gate.

Third, the change log isn't enforced. The folder becomes a dumping ground, someone edits a script on a client machine directly, and when something goes wrong nobody can say which version ran. The system fails silently because the record was never kept.

Here's what I'd do on Monday. Take three tickets from your backlog and run the determinism test on each. Pick the one that passes. Write or find the script, store it in the folder with an owner, and make the change log entry before it runs anywhere. That's the whole system, started with one script. The rest follows.