Notes
PowerShell automation for the work that should not need a person
There is a document called "Leaver Checklist v3.docx". It has nineteen steps. Somebody follows it, mostly, when they remember, and step fourteen gets missed about a third of the time because it is the one that requires a different portal.
That is the shape of the problem these notes address. Not automation as an engineering aspiration, but automation as the only realistic way one person performs a nineteen-step process consistently, on a Tuesday, while three other things are on fire.
What powershell automation is actually for here
Three categories earn their place, and everything else is a hobby.
Processes with a compliance consequence. Joiner, mover and leaver is the obvious one. Missing a step is not merely untidy, it leaves someone with access they should not have, and the evidence that the process ran is what an auditor asks for. A script produces that evidence as a by-product; a checklist produces a tick in a Word document.
Recurring evidence collection. Access reviews, MFA coverage, device compliance, backup status. Somebody asks for these quarterly and they take a day each time, because the exports are manual and the format changes depending on who did it last.
Anything you have done three times. Not twice. Twice is a coincidence, three times is a pattern, and by the third repetition you have enough understanding of the edge cases to write something that will not need rewriting immediately.
The failure mode is not a missing script
The scripts people write are usually fine. What goes wrong is what they do when they cannot do their job.
A leaver script that reports success having skipped the mailbox conversion, because the licence had already been removed and the mailbox was no longer visible to the cmdlet it used. A cost report that returns nothing because the token expired. A drift check that goes green because it could not reach Graph.
All three produce output that looks like the outcome you wanted. That is what makes them worse than a crash: a crash gets investigated, and a clean report gets filed. The single most valuable habit in this cluster is making "did not find anything" and "could not look" different outcomes, with different exit codes.
Permissions are part of the design
The other recurring theme is that a script's permissions outlive the script.
Something gets Directory.ReadWrite.All because it was the first result and it
worked. Two years later nobody knows what that app registration does, it still
holds tenant-wide write access, and its client secret has been copied into three
pipelines and a former employee's password manager. The script was fine. The
grant was the problem.
Reading the permissions reference properly the first time takes twenty minutes and is the highest-value twenty minutes in this cluster.
The handover test
Everything here is written to the same standard used for client work: if the person who inherits it cannot maintain it, it was built wrong.
In practice that rules out authentication as a named person, anything that only runs from one laptop, and documentation that stops at "run the pipeline". If a thing needs a service principal, the handover includes the service principal, the permission list, the reason each permission is there, and the expiry date in somebody's calendar.
Reading order
Joiner, mover and leaver first, because it is the process with the highest cost of being wrong and the clearest audit consequence. Exit codes and logging second, and honestly it should be read first if you already have scheduled scripts, because it is the note most likely to reveal that something you rely on has been quietly failing.
Graph permissions and evidence collection are independent and can be read in either order.