The n8n Workflow That Ended My Password Reset Queue

The question that started this build wasn't subtle. Why was I spending a meaningful chunk of every Monday resolving tickets that all said some version of the same thing?

"Can't log in." "Account locked." "Need my password reset."

At the large international NGO I worked at, with users spread across multiple counties and countries, password resets were the background radiation of the help desk. They didn't break anything critical, they weren't complex to resolve, and they weren't interesting. They were just constant. I started tracking them properly after a particularly slow Monday: eleven password-related tickets before noon. Each one required me to verify the requester, open the Active Directory or Entra ID console, reset or unlock the account, then draft a reply with next steps. Call it five minutes per ticket on a clean run. That's nearly an hour of Monday morning gone, on the most repetitive work in the queue.

That was the moment I decided to automate the whole thing.

What the Old Process Actually Looked Like

Before I built anything, I mapped exactly where the time went — not just the reset itself, but every step around it.

The typical flow:

1. User submits a ticket via Help Scout or directly by email
2. I triage, verify their identity (usually checking their submitted email against the org directory)
3. Open Active Directory or the Entra ID admin console
4. Reset the password or unlock the account
5. Email the user with their temporary credentials and next steps
6. Close the ticket

Step 1 was passive — it just arrived. Step 5 was mostly copy-paste from a template. The only parts that genuinely needed a human were identity verification (step 2) and the actual account action (step 3). Everything else was friction.

The automation target was clear: if I could verify the user programmatically and execute the reset through an API, I could remove myself from the majority of these tickets entirely.

The Architecture

The final workflow runs on n8n and connects three things:

An intake form. n8n's native form node. Users land on a simple page, enter their work email and employee ID, and submit. That two-field check is the identity verification layer. It's not the strongest factor in isolation, which I'll come back to, but it's effective for most cases.

Microsoft Entra ID via the Graph API. n8n has a built-in Microsoft Entra ID node that handles the OAuth handshake with your tenant. The workflow queries the submitted email to confirm the account exists, checks whether it's locked, and either unlocks it or triggers a password reset — depending on which flag is set on the account.

Email delivery via Microsoft 365. A temporary password is generated (or a secure reset link is constructed, depending on your Entra configuration), and the user receives it in under a minute. The ticket in Help Scout is created and immediately closed with the action logged, so there's an audit trail without a human touching it.

Form submission to email delivery: under 60 seconds. No one on the IT team involved.

The Part That Requires Thought: Identity Verification

This is where most self-service password reset builds either cut corners or overcomplicate things.

If you verify purely by email, anyone who knows someone's work address can trigger a reset. That's a real risk in multi-branch organisations where email addresses follow a predictable pattern. So I layered two checks: work email plus employee ID. The employee ID doesn't need to be a true secret — it just needs to be something a casual attacker doesn't have alongside the email. For most help desk scenarios, that separation is enough to block the low-effort attempts.

For accounts with elevated access — finance, leadership, IT itself — I excluded them from self-service entirely. Those requests still come to me directly. The exclusion list is a simple array in the n8n workflow that I update in one place when roles change.

The verification layer is where the real security trade-off lives. Build it too weak and you've created a fast path for account takeover. Build it too heavy and users route around it back to the help desk anyway — which defeats the point.

An option I evaluated and didn't implement for that deployment: SMS OTP via Twilio. It's a stronger second factor and n8n's Twilio node makes it a few extra nodes to wire in. The blocker for us was that mobile numbers weren't reliably populated in the directory at the time. If I were building from scratch today, I'd add Twilio from the start rather than treat it as an upgrade. The cost is marginal; the security posture is meaningfully better.

What Changed After Deployment

After roughly three months in production, the numbers were consistent:

• Roughly 75% of password reset and account unlock tickets were handled fully by the workflow — no manual action from me
• Average resolution time for those tickets dropped from around five minutes of my time to zero minutes of my time
• The remaining quarter were excluded accounts, edge cases the workflow couldn't match (mistyped employee IDs, deprovisioned mailboxes, merged accounts), or users who didn't trust the form and emailed me anyway

That last group shrank over time. Trust in the automation compounds as people use it and get their access back in under a minute. The best endorsement a workflow can get is the person who used it once telling a colleague it actually worked.

The one thing I'd undo: I didn't add a logging view until two months in. For the first eight weeks I had no clean dashboard showing how many self-service resets ran, what the failure patterns were, or whether anyone was probing the system. n8n's execution log is there by default, but I should have piped outcomes to a simple Google Sheet or Airtable table from day one — something I could share with my manager without asking them to read raw workflow logs.

How I'd Build It Today

The core architecture is the same. Three changes I'd make:

Use Entra's native SSPR where licensed. If your Microsoft 365 plan includes Entra ID P1 or P2, Microsoft's Self-Service Password Reset is built in and handles the verification, reset flow, and audit trail without custom tooling. I'd use n8n to augment it — auto-routing failed SSPR attempts into Help Scout, notifying the user by Slack, logging outcomes to a sheet — rather than replace it. Don't build what's already included in your licence.

Add the Twilio OTP layer at build time, not later. Retrofitting a second factor after users are already accustomed to the form is harder than shipping it correctly from the start. One extra node and a mobile number field in the form is the right call.

Manage the exclusion list as a lookup, not a hardcoded array. When the list of excluded accounts changes — a new hire in finance, a role change, a contractor rotation — editing and redeploying a workflow just to update an array is unnecessary friction. A Google Sheet or Airtable table that the workflow queries at runtime means the right person can own that list without touching the automation itself.

The Broader Point

Password resets are the most repetitive ticket in IT support. They're also one of the best first automation builds precisely because they're repetitive — the logic is clear, the variation is low, and the blast radius of a mistake is contained. If you're looking for an n8n workflow that will run in production rather than sit in a demo environment gathering dust, this is a strong candidate.

The n8n community forum has working templates for Entra ID and Azure AD integration. Start there, layer in your identity verification, test with your own account first, and you can realistically go live within a week. The Monday morning queue looks different after that.

If you've built something similar — especially if you've got the Twilio OTP piece wired up and have opinions on the edge cases — I'd like to hear how you handled it.