Auth Plugin's Forgot Password and Reset Password Flow, Explained

• Forgot Password Form and Reset Password Form are two separate components. A visitor requests a reset on the first one and completes it on the second, they only function as one flow if the emailed link actually points at whichever page holds the Reset Password Form.
• Forgot Password Form's Redirect Path defaults to /, Button Label to "Send Reset Link," Email Placeholder to "Enter your email...", Success Title to "Check your email," and Success Message to "We've sent a password reset link to your e..." (fully editable).
• A Back Link toggle on Forgot Password Form reveals Back Text (default "Back to sign in") and Back Path (default "/sign-in") once set to Show.
• Reset Password Form's Redirect Path defaults to /sign-in, Button Label to "Reset Password," and a Password Rules toggle drives a live checklist: at least 8 characters, one uppercase letter, one lowercase letter, one digit, one special character.
• Both components' Code Overrides section opens on a generic "Examples" file by default, not Auth Plugin's own overrides, you have to switch the File dropdown yourself.

If you've already worked through the basic setup, dropping in a sign-in form and protecting pages, the password reset flow is usually next, and it's actually two components that need to be configured together. Every property in this post was confirmed directly against each component's live properties panel in the Framer editor, not the docs site, that's the source of truth used throughout.

Auth Plugin ships Forgot Password Form and Reset Password Form as two independent components. Nothing links them automatically, the connection is entirely a matter of where you place each one and what the emailed link points to. Here's the full sequence:

1. A visitor who can't sign in clicks a "forgot password" link, usually the Back Link on your Sign In Form.
2. They land on whatever page carries Forgot Password Form and submit their email.
3. Auth Plugin sends a reset email containing a secure token link.
4. Clicking that link has to open the page carrying Reset Password Form, the component reads the token from the URL automatically once it's there.
5. They submit a new password. Reset Password Form's Redirect Path (default /sign-in) sends them onward.
6. They sign in with the new password.

Recommended page structure, based on the example paths in Auth Plugin's own forgot password guide and reset password guide: /sign-in for your Sign In Form, /forgot-password (or the docs' shorter /forgot) for Forgot Password Form, /reset-password (or the docs' /reset) for Reset Password Form. Nothing forces these exact paths, Auth Plugin doesn't hardcode them, what matters is that wherever Reset Password Form actually lives matches what the reset email links to.

The docs page documents a much shorter and differently named property list for this component. Treat your own panel as the source of truth.

• Redirect Path: defaults to /. The form's visible success state is the inline Success Title and Success Message, not this redirect, so when it actually fires isn't obvious from the panel alone. Verify in preview before depending on it.
• Button Label: defaults to "Send Reset Link."
• Email Placeholder: defaults to "Enter your email..."
• Success Title: defaults to "Check your email." The headline a visitor sees the moment they submit, their first confirmation the request went through.
• Success Message: defaults to "We've sent a password reset link to your e..."
• Back Link: a Show/Hide toggle. Off, there's no way back to Sign In from this form; set to Show, it reveals Back Text (default "Back to sign in") and Back Path (default "/sign-in").
• Six style objects: Label Style, Input Style, Focus Style, Button Style, Error Style, and Success Style, each controlling the appearance of that part of the form independently.

Success Title and Success Message are both plain editable text fields, not fixed copy. Once someone submits their email, the form swaps to a confirmation state built from those two fields, "Check your email" as the headline and the longer message underneath explaining a link is on its way.

That makes them worth rewriting to match your product's voice, "You're all set, check your inbox" instead of "Check your email." Since Success Message is a single text field, keep it short enough to read cleanly inside the form's existing layout, and pair any wording change with the Success Style object if you want the confirmation state to look visually distinct.

The docs page documents an even shorter and differently named set of fields for this component. Treat your own panel as the source of truth here too.

Don't move, rename, or delete this page after launch. If the page carrying Reset Password Form moves after visitors have already received reset emails, the link in those emails stops resolving to a working form, old links point at wherever the page was when the email was sent, they don't update. If a setup breaks this way, the setup errors post covers troubleshooting it.

• Redirect Path: defaults to /sign-in. This is what sends the visitor to sign in with their new password right after a successful reset, get it wrong and they land somewhere unrelated at the exact moment they're ready to log in. Leave it alone unless your sign-in page lives somewhere else.
• Button Label: defaults to "Reset Password."
• Password Placeholder: defaults to "Enter new password..."
• Confirm Placeholder: defaults to "Confirm new password..."
• Password Rules: a Show/Hide toggle. Controls whether visitors see a live requirement checklist while typing, see below for what it validates and what's still unconfirmed about Hide.
• Six style objects: Label Style, Input Style, Focus Style, Button Style, Error Style, and Validator Style, the last one styling the Password Rules checklist specifically, not shared with the other five. If you're matching brand colors across the form, that's the one to check separately.

With Password Rules set to Show, Reset Password Form displays a live checklist under the password field that updates as the visitor types. The five conditions it checks:

• At least 8 characters
• One uppercase letter
• One lowercase letter
• One digit
• One special character

Whether Password Rules set to Hide is a display-only change or an enforcement change is genuinely two different questions, and only one is confirmed. Confirmed: with Password Rules set to Show, the checklist updates live as the visitor types. Not confirmed: whether Hide only removes the visible checklist while the same five rules still apply on submit, or removes the requirement entirely. Both are plausible reads of a Show/Hide toggle. If you're considering Hide, verify actual submit behavior on your own instance first, don't assume either answer.

Both components include a Code Overrides section in their properties panel. On a fresh instance it opens on a generic "Examples" file (withHover, withRandomColor, withRotate), not Auth Plugin's own overrides. Switch the File dropdown to reach ShowWhenAuthenticated, ShowWhenGuest, IdentityName, IdentityEmail, and TriggerSignOut instead, the same behavior across Auth Plugin's components generally. The Code Overrides post covers what each one does.

Run this end to end before calling the flow done, and again after any change to page paths or redirect settings, since that's exactly what the callout above warns about breaking:

1. Request a reset from Forgot Password Form using a real email you can check.
2. Confirm the email actually arrives (check spam if it doesn't show up right away).
3. Click the link in that email.
4. Confirm it lands on the page carrying Reset Password Form, not a broken link or the wrong page.
5. Complete the reset with a new password.
6. Confirm you can sign in with that new password on your Sign In Form.

• Assuming the docs page lists every property. Relying on docs.authplugin.com alone for either component's fields means missing real ones, Back Link, Password Rules, Validator Style, and more, none of which appear on the docs pages. Check your own live panel instead, treat it as the source of truth.
• Leaving Code Overrides on the Examples file. The File dropdown opens on Examples by default, so without switching it you end up wiring withHover, withRandomColor, or withRotate onto an element instead of an actual Auth Plugin override. Switch the File dropdown to reach ShowWhenAuthenticated, ShowWhenGuest, IdentityName, IdentityEmail, or TriggerSignOut.
• Forgetting Back Link has to be set to Show. Back Text and Back Path don't appear until that toggle itself is on, so a visitor who lands on Forgot Password Form with Back Link left off has no path back to Sign In. Set it to Show if you want that path available.
• Hiding Password Rules without confirming what happens on submit. Whether Hide is purely cosmetic or actually changes enforcement isn't confirmed either way, so a password that looks like it should pass might not, or the reverse. Test actual submit behavior on your own instance before setting Password Rules to Hide.

Do Forgot Password Form and Reset Password Form need to be on the same page?
No, and normally they aren't. They're meant to live on separate pages, the reset email's link is what connects a visitor from the first to the second.

What happens if I never set up a page for Reset Password Form?
The reset link Auth Plugin emails won't have anywhere valid to send the visitor. If a setup breaks in a way that shows a redirect or error rather than the form itself, the setup errors post walks through diagnosing that.

Can I change the Reset Password Form's password requirements?
The confirmed control is the Password Rules Show/Hide toggle, which shows or hides the live checklist for the five fixed conditions (8 characters, uppercase, lowercase, digit, special character). There's no confirmed way to change what those five conditions are.

Why does the Code Overrides section show unfamiliar override names by default?
It opens on a generic Examples file, not Auth Plugin's own, see the tip above, or the Code Overrides post for the full list of overrides Auth Plugin actually documents.

Configuring this flow correctly comes down to three things: put Forgot Password Form and Reset Password Form on separate pages (recommended: /forgot-password and /reset-password, or the docs' shorter /forgot and /reset), leave Reset Password Form's Redirect Path at /sign-in unless your sign-in page lives elsewhere, and never move or rename the Reset Password Form's page once real reset emails are going out. Both components' docs pages list a shorter, differently named property set than what's actually in the live panel, Back Link, Password Rules, Validator Style, and the rest are real, confirmed properties your panel has even though the docs page doesn't mention them.

Before calling it done, run the test from the checklist above end to end: request a reset, confirm the email lands, click through, complete the reset, and sign in with the new password. If something breaks along the way instead of just needing customization, the setup errors post is where to look next.