Automation  ·  IT and security

How to build self-service password reset

Password resets and lockouts are among the most common tickets a service desk gets, and almost every one is the same five minutes of work. Below is the model behind handing them to the requester safely, the prompts that build it, and the parts that only bite once it is live.

Built with Tray Headless

  1. System Slack
  2. Step Check the request
  3. Step Verify identity
  4. Step Reset or clear lockout
  5. System Okta
Also Hand to IT

The reset only runs after the person proves who they are through a second factor they already have; anything unusual goes to a person.

The short answer

What is self-service password reset?

Self-service password reset has four parts: a request from wherever the person already is, an identity check through a second factor they already enrolled, the reset or lockout cleared in the directory with a one-time link instead of a password in chat, and every reset recorded so security can see patterns. The failure that matters is a weak identity check. A reset that anyone who knows a name and a manager can trigger is a gift to whoever is phishing your staff, and the help desk is the first place they try.

Stage 2 of 6: Password resets and lockouts. Part of IT service desk, end to end : every stage, the systems it runs on and the guide that builds it.

What matters here

  • Never send a password in chat or email. Send a one-time reset link that expires in minutes.
  • Verify with a second factor the person already enrolled, never with facts an attacker can look up, like a manager's name or a start date.
  • Treat accounts with admin rights differently. They always go to a person, however good the check.
  • Clear a lockout and find out why it happened. Repeated lockouts from a new location are a security signal, not a nuisance.
  • Record every reset with how identity was confirmed. Security will ask, and the answer should be a query.

Who this is for

You run an IT service desk or own identity. Password resets and lockouts arrive all day, each one takes a few minutes, and each one interrupts somebody who could be doing harder work.

How it works in practice

The path from "I can't log in" to logged in, without a ticket anyone has to touch.

  1. 1

    The person asks where they already are

    A message to the IT app in Slack or Teams, or a link from the login page for people with no chat access.

  2. 2

    The request is checked

    Is the account active, is it locked or expired, and does it hold admin rights.

  3. 3

    Identity is confirmed with a second factor

    A push to the authenticator app they already enrolled, or a code to a phone number on record.

  4. 4

    The reset runs in the directory

    The lockout is cleared or a one-time reset link is sent, never a password.

  5. 5

    Anything unusual goes to a person

    Admin accounts, failed checks and repeated lockouts route to IT with what was tried.

  6. 6

    Every reset is recorded

    Who, when, how identity was confirmed, and what was changed.

What self-service reset is made of

Four, and the second decides whether the whole thing is safe.

A request from where people are

Chat for most people, a link from the login page for anyone locked out of chat too. If the only route is a ticket, nobody saves any time.

An identity check worth trusting

A second factor the person already enrolled. Questions about a manager or a start date are answered by a quick search, and attackers know it.

A reset that never exposes a password

Clear the lockout or send a one-time link that expires in minutes. A temporary password pasted into chat stays in the history for years.

A record security can use

Every reset logged with how identity was confirmed, so a run of resets from new locations shows up as the warning it is.

The Tray Headless prompts

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

  1. 1

    Set up, then size the problem

    The volume is usually higher than anybody's estimate.

    Headless skills build-workflow 

    Use build-workflow. The systems in play are Okta, Slack and ServiceNow,
or whatever we run in those seats.

Before building anything, pull the last three months of tickets about
passwords, lockouts and multi-factor problems. Show me:

  Volume per week, and the share of all tickets it represents
  Median time from ticket to the person being able to log in
  How many were for accounts with admin rights
  How many people had more than three in the period

The last number matters. Somebody locked out every week has a problem
a reset will not fix, such as a saved password on an old device.

    Include tickets raised by phone or walk-up if you log them. They are the ones where somebody could not get to chat at all, and the design has to cover them.

  2. 2

    Take the request in chat and from the login page

    If the only route is a ticket, nothing is saved.

    Headless skills build-workflow 

    Use build-workflow. Add a "Can't log in" action to the IT app in Slack
and in Teams. It asks one thing: reset my password, or my account is
locked.

Add a link from the login page to the same flow for people locked out
of chat as well. That link asks for a work email address and nothing
else.

Look the person up in Okta and check before going further:

  Is the account active, or suspended or deprovisioned
  Is it locked, expired, or neither
  Does it hold admin rights anywhere

Suspended accounts and admin accounts stop here and go to IT with the
reason. Neither gets a self-service reset.
  3. 3

    Confirm identity with a factor they already have

    This step decides whether the whole thing is safe.

    Headless skills tray-gotchas 

    Use tray-gotchas. Confirm identity with a factor the person already
enrolled in Okta:

  A push to their authenticator app, which they approve
  If they have no app, a code to the phone number on their record

Never ask questions an attacker can answer from a quick search: manager
name, start date, employee number, office location.

If the check fails twice, stop, route to IT with what was tried, and
alert security if the request came from a location or device this
person has never used.
  4. 4

    Reset without exposing a password

    A password in chat stays in the history.

    Once identity is confirmed:

  Locked account: clear the lockout and tell them in the same thread
  Forgotten or expired password: send a one-time reset link from Okta
  that expires in 15 minutes, to the channel they asked from

Never generate a temporary password and never write one into chat,
email or the ticket.

Then check why it happened. If the lockout came from failed logins on a
device or location the person does not normally use, tell them and
raise it with security, because that is somebody else trying the
account.
  5. 5

    Record it, then report

    Security will ask how identity was confirmed.

    Record every request in ServiceNow as a closed ticket, even the ones
that never needed a person: who, when, which channel, how identity was
confirmed, and what was changed.

Report weekly: resets and lockouts handled without a person, median
time to logged in, failed identity checks, and the people with repeated
lockouts so IT can fix the cause.
  6. 6

    Validate, then hand the rules to IT and security

    The rules tighten over time, never loosen.

    Run the per-step checks and the whole-workflow audit before this
touches production. Test it against an admin account, a suspended
account and a failed check, and confirm each one routes to a person.

Then open the same workflow in Tray Build so IT and security can change
which accounts are excluded, which factors count and how long the reset
link lasts. Those are security decisions, and they belong to the people
who answer for them.

What it connects to

The request comes from chat, the identity check and the reset happen in the directory, and the record lands in the ITSM platform.

Okta

Look up the account, send the second-factor check, clear the lockout or issue the one-time reset link.

Reads and writes

Azure Active Directory

The same steps for accounts managed in Microsoft's directory, including on-premises accounts synced to it.

Reads and writes

Slack

Take the request, confirm each step in the thread, and deliver the reset link in a private message.

Reads and writes

Microsoft Teams

The same request and confirmation for people who work in Teams.

Reads and writes

ServiceNow

Record every reset as a closed ticket, and open one for IT when the request routes to a person.

Writes

Splunk HTTP Event Collector

Send each reset and failed check to security, so unusual patterns show up beside other login events.

Writes

Same build, other stacks

The design does not change if you run something else in one of these seats. The same prompts build it against Google Chat, Jira, Jira Service Desk, Zendesk or Freshservice.

Connections in this build

Field mapping, templates and common problems for each pairing: Okta + Slack, Azure Active Directory + Slack, Okta + Microsoft Teams and Okta + ServiceNow.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Running it in production

This changes how people get back into their accounts. It is a security control first and a time saver second.

It runs on the platform, not on your laptop

People get locked out at any hour, often before the service desk opens, and the reset runs the moment they ask.

Admin accounts never reset themselves

However good the check, an account with admin rights goes to a person. It is the account an attacker most wants.

Credentials are managed, never written into the build

Resetting passwords needs a directory credential with exactly that permission and no more, held as its own authentication in your workspace.

Every reset is evidence

Who, when and how identity was confirmed, written to the ticket and to security's log, so an audit question has an answer.

Security owns the rules

Excluded accounts, accepted factors and link lifetime open in Tray Build, and change only when security decides.

Questions people ask

Is self-service password reset safe?

It is as safe as its identity check. A push to an authenticator app the person already enrolled is a strong check. Questions about a manager or a start date are weak ones, because anyone can find the answers.

Which accounts should never reset themselves?

Accounts with admin rights, suspended or deprovisioned accounts, and any account where the identity check has failed. Those go to a person with what was tried.

Why not send a temporary password?

Because it stays in the chat or email history long after it is used. A one-time reset link that expires in minutes does the same job and leaves nothing behind.

What should we do about repeated lockouts?

Find the cause. It is usually a saved password on an old device, and occasionally somebody else trying the account. Both need a person, and a reset alone fixes neither.

Further reading

Background on the same subject, for the case rather than the build.

Related guides

IT and security

How to build IT ticket triage and routing

Classify each IT ticket by what it is about, attach who raised it and what they run, and route it to the team that fixes it first time. The prompts that build it.

IT and security

How to build IT service desk fulfilment

Catalogue the requests worth automating, fulfil the safe ones end to end, and route the rest with everything already gathered. The prompts that build it.

IT and security

How to build access request and approval

Route to the system owner, grant with an expiry by default, provision automatically, and produce the access review as a by-product. The prompts that build it.

Last reviewed October 2026.