Redirecting Users After Sign-In

Control where users land after they sign in to a custom frontend built on Knack. Send each role to the right home page, return users to the page they were trying to open, and handle signed-out visitors.

What You'll Learn

When someone signs in to a custom frontend, Knack sends them back to your app, and your app decides where they land. This article covers where users go by default, how to send each role to its own home page, how to return users to the page they were trying to open, and what to do with signed-out visitors.

Where Users Land by Default

Signing in takes users off your app to Knack's hosted sign-in screen, then back again. Knack returns them to the address registered for your app's sign-in, and your app takes it from there.

By default, most apps send everyone to one general home page. That works for many apps. It doesn't work well when different roles need different screens, or when users arrive from a bookmark or a shared link.

Send Each Role to Its Own Home Page

Your app knows which roles the signed-in user has as soon as they return. It can use that to send each role to the right place.

After a user signs in, send them to a home page based on their Knack role:
- [Role 1]: [page]
- [Role 2]: [page]
- [Role 3]: [page]

Get the user's roles from their Knack session. If the user has no role assigned yet, send them to a page that says their account is waiting for access. Don't show an error or an empty screen.
📘

The home page doesn't grant access

Sending a role to a page only decides what they see first. Knack's access rules decide what data they can reach on any page. See What Decides a User's Role.

Return Users to the Page They Were Trying to Open

If someone opens a link to a specific record or page while signed out, they'll land on the general home page after signing in, not the page they clicked. Because sign-in leaves your app and comes back, the destination has to survive the round trip.

Ask your frontend builder for a redirect-back mechanism. That phrase tells it what to build: remember the page the user was trying to reach, then send them there after sign-in.

Add a redirect-back mechanism for sign-in.

When a signed-out user tries to open a page that requires signing in, remember that page, send them to Knack sign-in, and return them to that page after they sign in. If they don't have access to that page, send them to their home page instead.

Only redirect to pages inside this app, never to an outside address.

Keep a Page for Signed-Out Visitors

Knack hosts the sign-in form, so it's tempting to remove your app's own sign-in page. Keep a page for signed-out visitors anyway.

When someone opens a page that requires signing in, your app needs somewhere to send them. That page catches people arriving from bookmarks, shared links, or yesterday's open tab. It usually just needs a Sign in button that starts Knack sign-in.

📘

One Sign In button is usually clearer

Separate "Staff sign in" and "Patient sign in" buttons don't choose anyone's role. Knack decides that from the account. Unless you have a reason for separate buttons, use one.

Test Where Users Land

Test on your published app, not your frontend builder's preview, since sign-in doesn't complete in the preview.

  1. Sign in as each role and confirm you land on that role's home page
  2. Sign out, open a link to a specific page, sign in, and confirm you land on that page
  3. Sign in as a user with no role and confirm you see the "waiting for access" page
  4. Click Sign in, press the browser's back button, and confirm the button still works

Common Mistakes

  • Removing your app's signed-out page. Visitors arriving from links have nowhere to go.
  • Treating the home page as security. A role landing on the right page doesn't protect anything. Access rules do.
  • Redirecting to any address in the link. Only send users to pages inside your app.
  • Testing in the preview. Sign-in won't complete there.

Next Steps


Did this page help you?