AI & Automation

Automating User Onboarding and Offboarding Across Clients

Provisioning and deprovisioning across many client environments, without a pile of custom scripts nobody maintains. What to standardise, what to keep per client, and the offboarding risk nobody prices.

Mauricio Esparza By ·Published ·2 min read
mithub.club
Short answer

Treat a client as a configuration and the lifecycle as one shared process: a request form, an approval, the provisioning steps and a verification. Keep per client only what genuinely differs, which is usually groups, licences and naming. Offboarding matters more than onboarding because an incomplete offboarding is a security exposure that stays open silently.

This is the work that quietly consumes a service desk, and it is usually solved with custom scripts that only their author understands.

The shape that scales

A client is a configuration. The lifecycle is one shared process.

Shared everywhere: the request form, who approves, the order of the steps, the verification that runs afterwards, and the audit record.

Per client, by configuration: groups, licences, naming conventions, the approver, the systems in scope, and any genuine exceptions.

The test is the same as any multi unit rollout. Write down what changes between client one and client two. If it is all values, you can standardise. If it includes logic, fix that first.

Build offboarding first

Most teams build onboarding first because it is the one people complain about. That is the wrong order.

Onboarding fails loudly. Someone cannot log in and you hear within minutes.

Offboarding fails silently. An account stays live, a licence keeps billing, access to a shared drive is never revoked. Nobody reports it. It sits open until an audit or an incident finds it.

Build the one that fails silently first, and put the noisy one second.

Verify the end state, not the run

The automation reporting success means it executed. It does not mean the state is correct.

After each run, verify: does this account exist, in these groups, with these licences, and are these accesses removed. Check the state rather than the log, because a green execution with a wrong outcome is the failure mode that survives longest.

One form, conditional fields

The recurring debate is one form for all clients or one per client. One form, with fields that change based on the client configuration.

Separate forms multiply maintenance and drift, and the differences between clients are almost always values rather than different logic.

Handle exceptions without breaking the model

There will be a client who genuinely needs something different. Make it a configuration value with a name, not a branch in the code.

The moment an exception requires different logic, you have found either something that belongs in the shared process because others will need it, or something that should not exist.

What this leaves you

A process that survives the person who built it, an audit trail per client, and a verification report you can show at renewal.

That last one is worth more commercially than the hours saved, because it is evidence of a control the client cannot easily check themselves.

Frequently asked questions

Why does offboarding matter more than onboarding?

Because it fails silently. Nobody calls to report that a departed user still has access, so the failure sits open until an audit or an incident finds it, while a broken onboarding is reported within minutes.

One form for all clients or one per client?

One form with conditional fields driven by the client configuration. Separate forms multiply maintenance and drift apart, and the differences between clients are usually values rather than logic.

Custom scripts or an automation platform?

Scripts are fine for one environment and become unmaintainable across many, because each one encodes a client's specifics. A shared process with per client configuration is the pattern that survives staff turnover.

What should run after the automation finishes?

A verification pass that checks the end state rather than the execution log: does this account exist, in these groups, with these licences. A green run is not proof the state is correct.

Sources

  1. Handle errors gracefully · n8n Docs (accessed 2026-09-22)
  2. Why evaluate AI workflows · n8n Docs (accessed 2026-09-22)
  3. Building effective agents · Anthropic (accessed 2026-09-22)
AI & AutomationMSPOperations
Mauricio Esparza
Mauricio EsparzaGTM Systems Lead · Revenue Engineer · Founder of MitHub. Designs and runs revenue systems for multi-location businesses: AI voice campaigns, enrichment, CRM automation and attribution. Founded MitHub to teach the method in the open.

Part of AI & Automation on MitHub.

Keep going

Revenue Engineering

Who Owns an Automation After It Goes Live?

The question nobody answers when the build finishes: who monitors it, who fixes it when an API changes, who approves changes, and what happens when the person who built it leaves.

Read · 2 min →mithub.club
Revenue Engineering

How to Standardize Lead Follow-Up Across Multiple Locations

Every branch does it differently and each one is sure theirs is right. The configuration model that makes follow up identical everywhere without taking local judgment away.

Read · 2 min →mithub.club
Revenue Engineering

When to Automate a Process (and When Not To)

Five tests that tell you whether a process is ready to automate, the three that mean wait, and why automating too early is more expensive than doing nothing.

Read · 2 min →mithub.club
Revenue Engineering

What to Automate First in a Revenue Team

A prioritisation method that ranks automation candidates by hours returned, error cost and effort, plus the five that pay back fastest in most companies.

Read · 2 min →mithub.club
n8n

Choosing an Automation Platform: n8n, Zapier or Make

A buyer's comparison of the three automation layers most revenue teams choose between, the cost model that decides it, and when self hosting is worth the operational burden.

Read · 2 min →mithub.club
AI & Automation

When to Hire a Forward Deployed Engineer

The buyer's view of the forward deployed engineer: the problems that need someone embedded in your systems, how the engagement is scoped, and how to tell a real one from a consultant with slides.

Read · 3 min →mithub.club