Choosing a Default User Role for a Custom Frontend

What you'll learn

The default user role in Knack is the role new users land in when nothing else has been decided for them, which makes it the one role you should give the fewest permissions. This article covers what the default role controls, why a permissive one is risky, and how to set up an approval step instead.

What the default role decides

Every Knack app has one role marked as the default. When someone signs up, and nothing has assigned them a specific role, that is where they land.

That matters more in a custom frontend than it does in a live app. Your frontend asks Knack for records, and Knack answers based on the role of whoever is signed in. A new signup with a powerful default role gets powerful answers, immediately, before any person has looked at their account.

Give the default role the fewest permissions

Set your default role to the least access that still lets someone sign in and see that their account exists. View only, or no access to your data tables at all.

The reasoning is about who lands there. Nobody chooses the default role. People arrive in it because a decision has not been made about them yet, and the appropriate access for a person nobody has reviewed is close to none.

A permissive default inverts that. It hands full access to exactly the people you know the least about.

Use an approval step as a buffer

Least-privilege on its own leaves a gap. Someone signs up, lands in a role that can see nothing useful, and has no idea what to do next.

Fill that gap with an approval step:

1. New signups land in the default role, which has minimal access
2. Your frontend shows them a pending-approval page rather than an error or an empty screen
3. Someone reviews the account and assigns a real role
4. The next time they sign in, they land in that role instead

This is a buffer, not a workaround. It gives you a place to decide who someone is before Knack starts answering their requests with real data.

Use Knack's account status, not your own status field

Knack has a built-in account status that controls whether a user can sign in at all. Use it for approval.

A status field you create yourself lives in your data. Your frontend can read it and choose to show or hide things, but the account still authenticates and Knack still answers its requests. That is a display decision, not a barrier.

Knack's own account status blocks sign-in before any of that happens.

The default role also affects new tables

When you add a new table to your app, Knack applies a set of starting permissions for each role. For the default role, those starting permissions come from how that role is configured.

So a permissive default role is not a one-time problem. It quietly grants access on every table you add afterwards, including tables you create months later without thinking about permissions at all.

Common mistakes

Leaving the builder's own role as the default. Whatever role you used while building tends to stay marked as default. Check it before launch.

Approving people with a custom status field. A field in your data can hide things in your interface. It does not stop Knack answering that user's requests. Use Knack's account status.

Sending unassigned users to an error page. A person who signed up successfully and is waiting for approval has done nothing wrong. Show them a page that says so.

Assuming the default only affects signups. It also shapes the starting permissions on every table you add later.

Next steps

• Checking That Your Access Rules Actually Work covers how to test what each role can really reach.
• Setting Up User Roles for a Custom Frontend covers designing roles around access needs.
• What Decides a User's Role covers how Knack assigns roles, and why your frontend cannot.