What Decides a User's Role

What you'll learn

Knack decides a user's role from their account, and your front end reads that decision rather than making it. This article covers where roles actually live, what your app can and cannot do with them, and why a screen that looks like a staff screen does not make anyone staff.

The role lives on the account, in Knack

When someone signs in, Knack tells your app which roles that person has. The answer comes from their account record in your Knack app, which you or an administrator set up.

Your front end receives that answer after sign-in. It arrives as a list, because a person can hold more than one role at once.

Your app's job is to react to it. Show a patient the patient view. Show a provider the provider view. Nothing your app does changes what that list contains.

Your app cannot grant a role

This is the part worth being precise about.

A button labelled "Sign in as staff" does not make anyone staff. A page at /admin does not grant administrator access. A view built for providers, shown to a patient, does not turn them into a provider.

Those are all just parts of your interface. The role came from Knack before your app drew anything, and Knack applies it to every request your app makes on that person's behalf.

What your app should do with the role

Two things, and no more.

Route them to the right view. One purpose-built view per role, rather than one view that hides parts of itself. If someone holds several roles, let them choose which one they are working in.

Handle the case where there is no role. A user whose account exists but has no specific role assigned still signs in successfully. Give them a real landing page saying their account is awaiting a role, rather than an error or an empty screen. See Choosing a Default User Role for a Custom Frontend.

What your app should not do is decide what data that person can see. Knack decides that separately, through Data Access Control, and applies it to every response your app gets back.

Roles and record access are different questions

A role answers "which part of the app is this person for?"

Record access answers "which specific records may this person touch?"

They are related and they are not the same. Two patients hold the same role and see completely different records. A role gets someone into the patient view. Data Access Control decides that they see their own three appointments and not the other twenty-two.

Changing someone's role

Roles are changed in Knack, on the account. Not in your app.

Your app can offer a request, a form, or a message asking for a change. Something in Knack then has to act on it. A field in your data saying "requested role: Provider" is a note, not a permission.

Common mistakes

Building one view with role checks inside it. Build a separate view per role. It is clearer to read, and it keeps you from accidentally showing a section to the wrong role.

Treating a role as a security boundary on records. It controls which view someone gets, not which records they receive.

Storing a role in your own data. The role on the Knack account is the real one. A copy in your own table will drift, and Knack will ignore it.

Sending a user with no role to an error page. Their sign-in worked. Tell them what is happening instead.

Next steps

• Checking That Your Access Rules Actually Work covers testing what each role can really reach.
• Choosing a Default User Role for a Custom Frontend covers where new users land before anyone assigns them a role.
• Designing Your Data Model for Access Control covers the table structure that makes record-level rules possible.