Home · Solutions · Other solutions
Solution · Other solutionsThe desk's most frequent ticket becomes a two-minute Teams flow, even for systems outside SSO
Password reset in two minutes, without a ticket
Entra ID self-service covers the single sign-on share; a Teams card and UiPath Robots reset the legacy credentials, with a manager's recorded confirmation before any MFA re-registration.
Executive summary
The most frequent ticket on the desk still needs a phone call, three consoles and an identity check nobody records.
The first move is configuration, not a build.
Analyst time on resets falls to the exceptions: Entra ID takes the single sign-on share, robots the rest.
Microsoft Entra ID (self-service reset, Temporary Access Pass, sign-in logs); the warehouse admin console; the point-of-sale back office
Business problem
Identity & access
The reset ticket is trivial and constant. It peaks after holidays, phone upgrades and every password policy change, and it arrives by phone, because the person is locked out of everything else.
Three things keep it alive. Entra ID self-service reset is switched on, but half the workforce never registered their authentication methods, so it fails when needed. Several systems keep their own credentials outside single sign-on, and only two analysts can reset them. And re-registering MFA after a lost or replaced phone needs proof of identity, which the desk approximates with questions a colleague could answer.
The desk knows this is a social-engineering risk and does it anyway, because the alternative is a store that cannot trade. Temporary passwords travel by email in plain text, and nobody can show an auditor who verified whom.
How it works today
- PersonA locked-out store employee calls the regional desk number and borrows a colleague's login until someone answers
- PersonThe analyst asks for the employee number and the manager's name, then resets the Entra ID password
- Risk of errorThe employee is still locked out: the failed account was the warehouse system's, and only two analysts hold that admin role
- WaitingThe ticket waits for one of the two; on Monday mornings and after phone upgrades that is hours
- SystemThe second analyst opens the legacy console, resets the credential and emails a temporary password in plain text
- PersonThe new phone fails MFA; an analyst removes the registered methods with no recorded proof of who asked
- Risk of errorThe ticket closes with no record of the identity check; the shift has run on a borrowed login for an hour
Why the current process costs more than it appears
Behind every exception is an hour nobody logged.
- Desk minutes are the small part. A locked-out store employee is idle on a shift that does not wait, and one who borrows a colleague's login defeats every control built on identity.
- Peaks after weekends and phone upgrades push every other ticket back a day; the reset queue sets the whole desk's response time.
- Two analysts with the warehouse admin role means a reset backlog whenever one is on leave, and a standing temptation to hand the role to more people.
- Auditability is close to zero: a reset is evidence of nothing unless the identity check is recorded, and it is not.
- Asymmetry is the real exposure. One convincing phone call to the desk can open an account, and helpdesk impersonation is a documented route into a company.
Cost of inaction
Password policy will tighten, because the security team is right to tighten it, and every tightening adds resets to a desk that answers them by phone; each new store and seasonal hiring wave adds more. The two analysts with legacy admin rights become the chokepoint of every Monday morning, and the temptation to spread those rights grows, which widens the risk instead of closing it. Meanwhile the unrecorded identity check stays the softest entry point into the company, and the day someone uses it, the incident review will ask why a known weakness persisted for another year.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A regional retail chain, 5,800 employees in 240 stores and a head office; Microsoft 365 with Entra ID single sign-on for most applications; a warehouse management system and a point-of-sale back office with their own credentials; shared devices, high turnover.
Around 1,200 reset requests a month, most by phone, about 14 minutes of analyst time each; four in five could run without an analyst once the non-SSO systems and the MFA check are covered.
Knowledge questions on the phone, an Entra ID reset, a second reset in a legacy console by one of two analysts, a temporary password by email, MFA methods removed on request.
Two analysts holding the legacy admin rights; an identity check that proves nothing and records less; registration that never reaches new store staff before their first lockout.
Entra ID self-service reset enforced at sign-in; an "Unlock me" card in Microsoft Teams that a UiPath Robot turns into a reset in the warehouse or point-of-sale system, with the one-time password sent to a verified channel; a manager's confirmation and a Temporary Access Pass before any MFA re-registration; every step in the Orchestrator audit log.
In the modelled case 960 of the 1,200 monthly requests never reach an analyst, a locked-out employee works again in minutes, and every MFA re-registration carries a named confirmer and a timestamp. The figures are a model, not a measurement.
Proposed solution
The first move is configuration, not a build. Self-service password reset and combined registration in Microsoft Entra ID are enforced at sign-in, so registration reaches everyone, including store staff in their first week, and the single sign-on share of the calls goes.
For the systems outside single sign-on we build a Teams flow. The employee, or the manager on their behalf when everything is locked, opens an "Unlock me" card in Microsoft Teams, a UiPath Apps form pinned as a tab in the store's team. A UiPath Robot identifies the person from the HR record and Entra ID, checks for a sign-in risk flag, resets the credential in the warehouse or point-of-sale console, and sends the one-time password to a verified channel: a private Teams chat, or an SMS to the number on file. Never by email.
MFA re-registration after a lost or replaced phone is the one step that needs a person, and it gets the right one: the manager recorded in HR confirms in Microsoft Teams, and only then does the robot issue a time-limited Temporary Access Pass. Who requested, who confirmed and what was reset goes to the Orchestrator audit log; analysts see failures and unusual patterns, nothing else.
Microsoft Entra ID self-service password reset, combined registration, Conditional Access, Temporary Access Pass; Entra ID Protection sign-in risk (P2); UiPath Apps forms in a Teams tab; Action Center tasks completed in Teams; Orchestrator queues, credential store and audit log
The "Unlock me" card and its routing rules; the robots that reset credentials in the warehouse and point-of-sale back office; one-time password delivery; manager confirmation; the audit and exception report
User, manager and risk-state lookups through the Integration Service connector still named 'Microsoft Azure Active Directory'; Temporary Access Pass issuance and the private chat through Microsoft Graph; SMS through Azure Communication Services; the manager hierarchy from HR
How the automated process works
- PersonThe employee, or the manager on their behalf, opens the "Unlock me" card in Teams and picks the system
- AutomationThe flow identifies the person from the HR record and Entra ID and checks for a sign-in risk flag
- AutomationA single sign-on account goes to Entra ID self-service reset; for most requests the flow ends there
- SystemFor the warehouse or point-of-sale back office, a UiPath Robot resets the credential under a service account with reset rights only
- AutomationThe one-time password goes to a verified channel, a private Teams chat or an SMS to the number on file, and expires on first use
- PersonAfter a lost or replaced phone, the manager confirms the person in a Teams task; only then does the robot issue a Temporary Access Pass for MFA re-registration
- AutomationWho requested, who confirmed and what was reset goes to the Orchestrator audit log; failures and repeated attempts reach an analyst
Human-in-the-loop model
Automation handles
- Routing single sign-on accounts to Entra ID self-service reset, resetting the rest under a restricted service account
- Delivering one-time passwords through a verified channel; issuing the Temporary Access Pass once the manager has confirmed
- Writing the audit record: who requested, who confirmed, what was reset, when
People decide
- Manager confirmation of identity before MFA re-registration
- Analyst review of failed resets and repeated attempts on one account
- Security decisions on accounts flagged by sign-in risk
Before and after
Systems and integrations
Everything below runs on licences and systems you already hold, or would need anyway.
Inputs
- the "Unlock me" card in Microsoft Teams
- the desk phone script, redirected to the card
- the HR record with manager and mobile number
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Apps
- UiPath Action Center
- UiPath Integration Service
- Microsoft Graph
Target systems
- Microsoft Entra ID (self-service reset, Temporary Access Pass, sign-in logs)
- the warehouse admin console
- the point-of-sale back office
- Azure Communication Services for SMS
Human touchpoints: the manager's confirmation task in Teams; the chat or SMS carrying the one-time password; the analyst's exception queue; the monthly exception report
Technologies used
self-service reset and registration enforced at sign-in; Conditional Access; Temporary Access Pass; sign-in risk (P2)
Areset credentials in the legacy consoles; queues, credential store, audit log
Athe "Unlock me" request form, pinned as a tab in Microsoft Teams
Athe manager's confirmation task, completed in Teams, approver identity recorded
Auser and manager lookups in Microsoft Entra ID; Teams notifications
ATemporary Access Pass issuance; the private Teams chat carrying the one-time password
Arequest card, manager confirmation and delivery chat, in the window staff already use
ASMS with the one-time password where Teams is unavailable
AIllustrative economic model
A model, not a promise.
Store time stays out of the calculator on purpose; the rows price desk minutes only. Four resets in five, 960 of the 1,200 a month, stop needing an analyst once Entra ID covers the single sign-on share and robots the rest, at the full 14 minutes each, because the analyst's part disappears rather than shrinks; today those 1,200 cost the desk 280 hours a month. €44 an hour is a fully loaded desk analyst cost, and the 25 minutes an employee loses per lockout, at €31 an hour, is priced in section 14. Licensing, implementation and the exposure of an improvised identity check are excluded. Nothing was measured at a client, and the four-in-five share depends on how many systems sit outside single sign-on.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Analyst time on resets falls to the exceptions: Entra ID takes the single sign-on share, robots the rest
- Locked-out frontline staff are back in minutes, from a Teams card their manager can open for them, not a phone queue
- The identity check for MFA becomes a recorded manager confirmation, which closes the helpdesk-impersonation route
- Temporary passwords stop travelling by email: the robot delivers them to a verified channel and they expire on first use
- The two admins who held the warehouse reset role stop being a bottleneck: the robot holds the role, they hold the review
The management view
- Three consoles and a phone line become one entry point and one log; volumes per system and per store are visible for the first time
- Failing registration campaigns and the legacy system behind most lockouts show up in the same report, which is where the next decision comes from
- The CISO gets evidence: every MFA re-registration carries a named confirmer and a timestamp, and repeated attempts on one account are surfaced
Board-level KPIs
Security and governance
Where the data sits and who can see it.
- Robots hold reset permissions only, under a dedicated service account per system, with the secret in Orchestrator's credential store or Azure Key Vault and never in a workflow
- One-time passwords are generated per request, expire on first use and never reach a ticket or an email; the Temporary Access Pass is single-use and time-limited by policy
- MFA re-registration always requires the confirmation of the manager recorded in HR, captured in Teams with the approver's identity
- Accounts flagged by Entra ID Protection for sign-in or user risk leave the flow and go to security; Conditional Access keeps applying regardless of the reset
- Every action is logged in Orchestrator and in the Entra ID audit and sign-in logs, retained under your Microsoft Purview policy; data stays in the EU region of UiPath Automation Cloud and inside the Microsoft 365 EU Data Boundary
Why now
Helpdesk impersonation is a documented attack route, described in public advisories from national cyber agencies, so auditors and insurers now ask how identity is verified before a reset; an employee number is not an answer they accept
Self-service reset and combined registration in Entra ID are mature and already licensed in most Microsoft 365 tenants; what is missing is enforcement and the systems outside single sign-on, which robots can operate without an API
Desk minutes alone come to €9,856 a month in the modelled case, before the 400 hours of store time the same resets cost each month; both are paid now, for a control that proves nothing
Relevant executive roles
The most frequent ticket disappears from the desk without a portal project
Three consoles and a phone line become one flow with one log, and the legacy-admin bottleneck goes away
The identity check before an MFA reset becomes a recorded control instead of an analyst's judgement
Common questions and objections
For accounts behind single sign-on, yes, provided registration is enforced. The tickets you still see come from the systems outside it and from MFA re-registration, which is what this adds.
A manager confirming a named report in Teams is a stronger and more accountable check than an analyst asking for an employee number. Every confirmation is logged against the manager, and repeated confirmations for one account surface in the exception report.
That is what the robot is for. It operates the same console your administrators use, under a restricted account with reset rights only, and logs every reset.
When this is not the right solution
- Every system is already behind single sign-on and registration is complete; this is a configuration task, not a project
- Reset volume is below a hundred a month, or the legacy system is being retired within the year
- Policy forbids any automated handling of credentials, even under a restricted service account
A question for the next management meeting
Were the desk to stop answering password calls tomorrow, which of our systems would still lock a store manager out, and who would prove that the caller is who she says she is?
Implementation approach
The first week looks the same at every client: we look at the data.
We deliver
- Reset volumes per system and Entra ID registration coverage, read from one month of tickets
- Self-service reset and combined registration enforced at sign-in, which removes volume before anything is built
- A robot for each system outside single sign-on, with a restricted service account and exception handling
- The "Unlock me" card in Teams, routing rules, one-time password delivery, manager confirmation and Temporary Access Pass issuance
- Testing, deployment, desk training, the phone script redirected to the card, and a monthly exception report
We need from you
- One month of reset tickets and the list of systems outside single sign-on
- A service account for the robot in each legacy system, limited to resets
- The manager hierarchy from HR, and a security sign-off on the identity flow
- One legacy system and one region of stores for the pilot
Stages
Discovery
One month of reset tickets by system; registration coverage; identity-check rules agreed with security
Entra first
Enforce self-service reset and combined registration at sign-in; measure the drop in single sign-on calls
Build
Teams card, routing rules, the first legacy robot, manager confirmation, Temporary Access Pass issuance
Pilot
One legacy system and one region of stores; analysts shadow every robot reset at first
Scale
The remaining systems one at a time; the phone script switched to the Teams card
Optimisation
Monthly exception report, registration campaigns where coverage lags, rule tuning
Quick win. Effort depends on how many systems sit outside single sign-on and whether each has a console a robot can operate; the Entra ID part is configuration.
Anyone in the store knows her employee number. The desk still accepts it as proof.
Show us last month's reset tickets and the list of systems outside single sign-on. We mark which resets Entra ID already covers, which need a robot, and where your identity check breaks.
Send us last month's reset ticketsThe neighbouring process usually has the same problem
New starters wait days for access; leavers keep theirs for weeks. Both are the same missing handover.
View solution Other solutionsThe service desk request that never becomes a ticketFour IT tickets in ten follow a known procedure, and every one of them still queues for an analyst.
View solution Other solutionsApplication access granted by policy in minutes, with proofAccess is granted from interpreted emails, approvals are chased, and the auditor finds the evidence missing.
View solutionIndustries we deliver this in most oftenManufacturing & industryTransport & logisticsServices & ITShared services