How to automate password resets and access requests in Slack

A message landed at 4:50 on a Friday. "hey it's Dave from finance, I'm locked out and I have a board deck due in an hour, can you just reset me?"

The display name said Dave. The profile photo was Dave's photo, lifted from our own website. The account had been created ninety minutes earlier.

I would love to tell you I spotted it instantly. What actually happened is that I typed most of a reply, then stopped, because the real Dave had never once in three years said "can you just."

That near-miss is the reason I think password resets are the right first thing to automate, and also the reason most homegrown reset automation makes me nervous. Resetting a password is the easy half of the job. Being certain who is asking is the other half, and that is where the whole thing lives or dies.

Two request types, and why to start with exactly these

Password resets and access requests are the number one and number two ticket categories in most organizations I have seen numbers for. That alone would justify starting here, but volume is only half of why they are good candidates.

They are also low-judgment. "Reset my password" has no interesting decision inside it once you know who is asking. "Give me read access to the marketing analytics dashboard" has one decision, and in most cases that decision was already made months ago by whoever defined the group.

And they have clean success criteria. Either the person can log in or they cannot. Either the grant exists in the identity provider or it does not. Compare that to "my wifi is slow," where success is a matter of opinion and the ticket closes when everybody gets tired.

If you already manage support requests in Slack, you have the intake surface. What you are building is the part that happens after somebody clicks.

Make the intake a form

Prose does not classify. You cannot auto-resolve a request your automation cannot parse, so the first build is a modal, not a bot that reads sentences.

For a reset, you need less than you think: which system, and whether they still have access to their enrolled second factor. For an access request: which system, which resource, how long, and why. Four fields and a submit button.

Use constrained inputs everywhere you can. A dropdown for the system. A searchable picker for the resource, populated from the actual group list rather than typed by hand. A duration select with three fixed options instead of a free text field where somebody will type "until the project finishes." A justification field with a minimum length, because a two-character reason is worse than no field at all.

There is a good argument for doing this in real code rather than no-code glue, and it comes from a K-12 team that automated their asset workflows. They picked an interactive script front end over a passive webhook for one specific reason: webhooks cannot do front-end input validation. They wanted to block a technician from entering an iPad asset tag at a laptop-only campus, before the bad data ever reached the API. "Consistency and input validation" was named as the single biggest reason they scripted it. Their annual inventory audit went from roughly three weeks to about one, and they credit most of that to catching errors at the point of entry rather than reconciling them later.

Validation at intake is the cheapest work in the entire pipeline. Everything you let through, you will chase.

Verify the human before you touch the account

This is where most Slack apps for IT support are dangerously naive, and it is the section to read twice.

A chat account is not an identity. Display names are editable. Photos are public. Guest and external accounts show up in the member list looking a lot like everybody else. And none of that matters compared to the actual common case, which is a legitimate account whose session has been stolen. The message really did come from your colleague's Slack. Your colleague did not send it.

So verify with something the requester holds, not something they know.

Good: a push to an already-enrolled MFA factor. A code from an authenticator app they registered before today. Managed-device attestation, where the request only proceeds from a device your MDM knows about. If you are using Okta Verify with FastPass, one gotcha to plan for is that a device does not count as managed until the user has performed at least one login or verification action on it. Installing the client is not enough.

Bad: employee ID, last four of anything, manager's name, office location, start date. All of that is either on LinkedIn or in the directory the attacker is already inside.

The awkward case: the person is locked out of the very factor you would verify with. That is your escalation path, and it should route to a human with a defined procedure, ideally a live video call or an out-of-band confirmation from their manager. Do not let your automation solve this one. Every published account-takeover story I have read went through exactly this door.

Then rate-limit. Two reset requests for the same account within an hour is a fine automation. Two reset requests for the same account within an hour, from different devices, is an alert.

Where the automation stops and a person starts

Auto-resolve when all four of these hold: identity was verified through a factor the requester already had, the request sits inside a policy somebody wrote down in advance, the target system has an API that can do the thing, and failure is safe.

Escalate when verification fails or is unavailable, when the resource is not on the pre-approved list, when the requested duration exceeds your cap, or when the requester is in a sensitive state such as an active offboarding or a legal hold. That last one requires wiring your HR system in, and it is worth it.

The API mechanics, concretely. The pattern is almost always the same three calls, and the middle one surprises people. A GET to retrieve the record. Usually a preliminary GET to resolve the human-facing identifier (a username, an email, an asset tag) into the system's internal unique ID, because the update call will refuse to accept anything else. Then a PUT to change state. Then a POST that appends a structured row to a log or a spreadsheet in real time, so the record exists even if the rest of the run fails halfway through.

Show your work while it runs. Borrow this from a team that built self-service asset scripts: render the steps as a live list and update the status of each one as it completes. Blank, then in progress, then a green check or a red X. The script writes to a local status file and the dialog watches it. This is a small piece of UI that produces a measurable drop in "hey, any update?" messages, because a person watching a green check appear has been told something. A person watching a spinner has not.

Handle your own credentials better than the ones you are resetting. Keep secrets out of scripts, and keep them out of plists, which are effectively cleartext. Read them from the environment rather than passing them as command-line arguments, because arguments are visible in the process list while the script runs and can be scooped up by ordinary process logging. Scope one narrow credential per automation task instead of one master credential doing everything. The original Windows LAPS stored rotated passwords as plain text in Active Directory attributes back in 2015, so the tool that invented this category got it wrong first. You have less excuse.

Every grant needs an expiry

An access grant with no end date is a permanent grant with good intentions attached.

Pick a default duration and make it short. One hour is the common default for elevated access in identity providers. One team running just-in-time local admin uses 20 minutes and has not had complaints.

Then make revocation redundant, three ways. A local timer that fires even with no network. An identity provider timer that also re-asserts default-deny as the standing state on every check-in, so a failed local revoke gets caught anyway. And a staleness check that hunts for the specific broken condition: this person has access, and their timer expired a long time ago.

Approvals. Route to the manager for anything role-based, and to the resource owner for anything system-specific. Post the outcome back into the original thread so the requester is not refreshing a portal, and include what was granted, for how long, and by whom. If the approver does nothing, the request expires rather than sitting open forever.

The record has to live somewhere other than the thread. Chat search is not a compliance source of record, and if you have not tried to reconstruct an access decision from six-month-old messages during an audit, take my word for it. There is also a hard retention wall waiting for you: Okta keeps user action history for 90 days and access request logs for a year before purging. If you need three years, write it somewhere you own.

Log the request ID, the requester, which factor verified them, the approver, the resource, the scope, the duration granted, the actual revocation timestamp, and which of your three layers did the revoking. That last field will tell you within a month whether your local timers are actually firing.

The ceiling. Do not automate any decision about whether a person should have the access at all. Automate the request, the verification, the plumbing, and the expiry. A new resource nobody has classified, an exception to a policy, a request that only makes sense if you know this team is reorganizing next month: those need a person, and pretending otherwise is how self-service IT gets a bad name internally. The organization I mentioned earlier that requires a written justification follows up on vague ones, and that follow-up is the whole control. It works because a human occasionally reads.

Start here on Monday

1. Pull your last 90 days of tickets and count exactly how many were password resets and access requests. You need the number to justify the build, and it is usually larger than your team's guess.
2. Write the policy before the code. Which resources are pre-approved, for whom, for how long, and who owns the exceptions.
3. Build the modal. Four fields, constrained inputs, no free text except the justification.
4. Wire verification first, before any write call exists in your codebase. If verification is the last thing you add, it will be the first thing that gets skipped under deadline.
5. Automate one system end to end. One. Get the GET, the ID resolution, the PUT, and the log row working for a single target before you generalize.
6. Add the live status list. It takes an afternoon and it is the part users will actually mention.
7. Put the audit record outside the chat thread on day one, not after your first audit finding.
8. Publish the escalation path in the same place as the request button, so the failure case has an obvious door.

The unglamorous version of a good idea

Every one of these automations replaces a small act of judgment with a written-down rule, and that is uncomfortable to do well because it forces you to admit how many of your rules were never written down.

I resisted this for years on the grounds that support is relational and forms are cold. I was wrong in a specific way. I had located the relationship in the wrong step, because it lives in the part where somebody replies fast, understands the actual problem, and does not make you feel stupid for asking. Automating the reset does not remove that. It just stops you from spending the good hours of your week reading passwords aloud over the phone.

Dave, by the way, got his password reset. He filled out the form, approved a push on his phone, and never spoke to me at all. Which is roughly the best possible outcome for both of us.

---

Foqal turns Slack and Microsoft Teams into a real IT front door, with structured intake, approvals, and a record that survives outside the conversation.