Fini for password reset and account access

Fini handles password reset and account-access requests by triggering your existing reset flow through an Action, or by pointing the customer to your self-serve reset page, and it never asks for, accepts, or sets a password or MFA code in the conversation. Your identity system stays the only place where a user is verified and a credential changes; Fini’s job is to recognize the request, start the right flow for that account, and explain the next step clearly. That split is the whole design. A reset link sent to the email address already on file is safe to trigger from a chat, because only the owner of that inbox can use it. Changing the email on file, removing MFA, or unlocking an account on someone’s word is not, so those go to your team.

What Fini handles and what it hands to your team

Request	Who handles it	How
”I forgot my password”	Fini	A Tool node calls your `Send Password Reset` Action for the login email; the reset link goes only to the address on file.
”The reset link expired” / “I never got the email”	Fini	Re-triggers the same Action within a limit you set, and explains link expiry and spam folders from Knowledge.
”How do I change my password?” (signed in)	Fini	Answered from Knowledge with a link to your account settings page.
”I sign in with my company account”	Fini	Explains that the password is managed by the customer’s company identity provider and that their IT admin can reset it.
”My account is locked”	Fini, if your system has a self-service unlock flow; otherwise your team	Fini triggers the unlock-by-email flow as an Action, or escalates.
Lost MFA device, new phone, no backup codes	Your team	Escalated for identity verification. Fini can share your published recovery steps (for example, backup codes) from Knowledge.
Change of login email or phone number	Your team	A common account-takeover path; never automated on an unverified request.
”Someone else is in my account”	Your team, immediately	Escalated at the Planning step through Escalation Topics.

To confirm (internal, remove before publish): https://www.usefini.com/industries/finance says Fini handles “KYC-grade identity verification and MFA resets” end to end. Is there a supported MFA-reset pattern beyond calling the customer’s own recovery Action (for example, a documented verification sequence) that docs should describe here, or should MFA resets stay a human handoff as written?

How it works in Fini

Piece	What it does for account access	Where
Tags	A Rulebook-enabled group (for example `Account Access Intent`) with `forgot_password`, `reset_link_issue`, `account_locked`, `mfa_issue`, `change_login_email`, `account_takeover`, and `other`.	Tags
User Attributes	When the requester can be identified (email channel, helpdesk requester, or a logged-in widget user), an `Account Status` attribute exposes `auth_method`, `account_locked`, and `recent_reset_requests`.	Attributes
Actions	`Send Password Reset` and, if you have one, `Send Unlock Email`. Both call your identity system’s existing endpoints.	Actions
Intent Rule	A Fallback-rooted tree that sends SSO users to their admin, triggers the reset for everyone else, and falls back to the self-serve link.	Intent Rules
Prompts	Escalation Topics for MFA loss, login-email changes, and takeover reports, so the planner routes those to a human and skips knowledge search.	Prompts
Reply Rules	Internal Comment for `change_login_email`, so your team sees the draft but the customer doesn’t receive an automated answer.	Reply Rules
Guardrails	A custom rule that fails any reply asking for a password or code, plus a URL allowlist so reset links only point at your domains.	Guardrails
Knowledge	Articles on reset-link expiry, spam folders, SSO sign-in, and your published MFA recovery steps.	Articles

Design your reset endpoint for chat

Your Send Password Reset endpoint should behave the same way your public “forgot password” form does:

Send only to the address on file. The Action passes a login email; your system sends the link to that account’s registered email, never to an address supplied in the conversation that differs from it.
Return the same response whether or not the account exists. The Reply then uses neutral wording (“if an account exists for that email, a reset link is on its way”), so the conversation can’t be used to discover which emails have accounts.
Rate-limit on your side too. The tree checks recent_reset_requests when it can identify the account, but your endpoint should enforce its own limit.

Example behavior tree

Example to adapt. Tag values, field names, and Action names below are placeholders; replace them with the ones in your workspace.

Fallback  (root)
├── Steps  (Company SSO accounts: send to their admin)
│   ├── Check: Account Access Intent In forgot_password, reset_link_issue, account_locked
│   ├── Check: auth_method Equals sso
│   └── Reply: their password is managed by their company sign-in; contact their IT admin
├── Steps  (Over the reset limit)
│   ├── Check: Account Access Intent In forgot_password, reset_link_issue, account_locked
│   ├── Check: recent_reset_requests Greater Than or Equal To 3
│   └── Reply: explain the limit; link to the self-serve reset page
├── Steps  (Trigger your reset flow)
│   ├── Check: Account Access Intent In forgot_password, reset_link_issue, account_locked
│   ├── Read:  extract `login_email` (String, required)
│   ├── Tool:  Send Password Reset
│   │     in:  login_email
│   │     out: request_accepted, link_expires_in_minutes
│   └── Reply: neutral confirmation; link expires in ${link_expires_in_minutes} minutes;
│              check spam; never ask for the password or a code
├── Steps  (Ask for the login email)
│   ├── Check: Account Access Intent In forgot_password, reset_link_issue, account_locked
│   └── Reply: ask for the email they sign in with
└── Reply: link to the self-serve reset page

How this runs: SSO users are caught first, so the agent never sends a reset email to an account whose password your system doesn’t own. Customers who already requested several resets get the self-serve link instead of another email. When auth_method or recent_reset_requests isn’t populated (the requester couldn’t be identified yet), those Checks fail and their branches are skipped. The reset branch needs a login email; if the Read can’t find one, the branch fails and the next branch asks for it. Tree variables don’t carry over between messages, so on the customer’s next message the rule runs again from the root with the email now in the conversation. If Send Password Reset fails, the reset branch fails too and the Fallback moves on to the ask-for-email branch, whose intent Check passes, so the customer is asked for the email again. To hand off instead, wrap the Tool and its Reply in a Fallback whose second child is a Reply saying a teammate will follow up.

If the reset flow asks the customer to go to their inbox and the conversation goes quiet, a Reply node can send one follow-up after a delay with Follow up after inactivity. See Rulebook → Inactivity follow-ups.

Guardrails and escalation

Tell the agent never to handle credentials

In Main Guidelines → Guardrails, add a subsection: never ask for a password, one-time code, MFA code, recovery code, or security answer; if the customer shares one, don’t repeat it and tell them to change it. See Prompts → Main Guidelines.

Check every reply for it

On Guardrails, add a Custom rule with an evaluation instruction such as “Fail if the reply asks the customer to share a password, one-time code, MFA code, recovery code, or security answer, or repeats one back.” Add pass and fail examples to calibrate it. Add a URL allowlist with your app and identity domains so the agent can only link to real reset pages.

Escalate the high-risk requests

In the Planning Prompt, add Escalation Topics for lost MFA devices, requests to change the login email or phone, and any report that someone else has access to the account. The Planning Prompt guidance lists identity issues and account-takeover signals as high-risk operations for exactly this reason.

Route escalations to the right queue

For widget conversations, a Business Rule creates the ticket in your helpdesk. For native tickets, map mfa_issue and account_takeover to your identity or trust team with Agent groups. See Fini for escalation and human handoff for the full handoff setup.

Guardrails check what the agent sends; they don’t remove what a customer types. If a customer pastes a password into the conversation, it is part of the transcript. Your Main Guidelines instruction should tell the agent to advise the customer to change it. See Data handling for how conversation data is stored.

What you need

What	Why	Where
A reset endpoint	The `Send Password Reset` Action calls it. It should send to the address on file, return a uniform response, and rate-limit.	Your identity system
A credential scoped to that endpoint	The Action’s Data Step sends it in Headers. Issue a key that can trigger reset and unlock emails and nothing else, never one that can change credentials or MFA settings.	Your identity system
A self-serve reset page URL	The fallback in the tree and the link in Knowledge articles.	Your app
A Rulebook-enabled tag group	The intent Checks read it. Write tag descriptions that separate `forgot_password` from `mfa_issue`.	Tags
Knowledge articles	Link expiry, spam folders, SSO sign-in, and MFA recovery steps you publish to customers.	Articles
A test account	Verify each branch, including the SSO branch and the rate limit, before publishing.	Your identity system

What to measure

Intent rule breakdown in Analytics: the reset rule’s AI Resolve Rate, Escalated Rate, and Volume.
Conversation status. Reset conversations often end with the customer leaving to check their inbox. Compare Resolved by AI with Waiting for Customer for this intent; a large waiting share inflates deflection rate without telling you whether customers got back in.
Escalation reasons. The Customer requested human (after attempt) reason on reset conversations usually means the email didn’t arrive or the Reply wording was unclear.
Guardrail activity. Hits on the credential custom rule over 7d and 30d. Any hit is worth opening in Inbox.

Add the rule to a Test Suite set with the Safety & boundaries and Tool use correctness judges, including a scenario where the customer volunteers a password. Run it with Simulate rule execution, or point the Action at a test identity environment: Test Suite runs don’t dry-run your Actions, and Execute live actions calls your real APIs.

End-to-end: cancellation flow

The closest walkthrough: intent, identify, one API call, confirm. Password resets share this shape.

Intent Rules

Fallback trees, Read nodes, and inactivity follow-ups.

Guardrails

Custom rules and the URL allowlist.

Prompts

Escalation Topics and Main Guidelines.

Widget

Identify logged-in users with a signed JWT when the request comes from inside your app.

Use cases

Walkthroughs

Industry setup

How-tos

Fini for password reset and account access

What Fini handles and what it hands to your team

How it works in Fini

Design your reset endpoint for chat

Example behavior tree

Guardrails and escalation

What you need

What to measure

End-to-end: cancellation flow

Intent Rules

Guardrails

Prompts

Widget

​What Fini handles and what it hands to your team

​How it works in Fini

​Design your reset endpoint for chat

​Example behavior tree

​Guardrails and escalation

​What you need

​What to measure

​Related

End-to-end: cancellation flow

Intent Rules

Guardrails

Prompts

Widget

What Fini handles and what it hands to your team

How it works in Fini

Design your reset endpoint for chat

Example behavior tree

Guardrails and escalation

What you need

What to measure

Related