Using Role Tables as Your People Records

What You'll Learn

In Knack, the people who sign in to your app belong in user role tables, and each person should live there once. This article explains why a second copy of the same people in a data table costs you records and breaks your access rules, and how to set your tables up so each person has one place.

User Role Tables Are Your People Records

A user role table holds the people who sign in with a specific role, like Staff, Patients, or Clients. It works like any other table, so it can hold every field you need about that person: phone number, title, start date, credentials, and connections to other tables.

That means you don't need a separate data table to hold extra details about the same people. The role table can do both jobs.

Role records are also owned by the user they represent. That's what lets access rules show each person their own profile and the records connected to them.

Keep Each Person in One Place

A common setup, especially in apps first built with a frontend builder, keeps the same people in two tables: a Staff data table with their details, and a Staff user role table for signing in. Avoid this.

When the same person lives in two tables:

• You pay for them twice. Both records count toward your record limit.
• Their information splits. Some details end up in one table and some in the other, and the two drift apart.
• Connections point to the wrong table. Appointments, notes, or timesheets connected to the data table don't connect to the person who signs in.
• Access rules miss. Knack decides what someone can see from their role record. Records connected only to the data table copy don't count as theirs.

How People Count Toward Your Record Limit

Every person who signs in already counts as more than one record. They have a record in Knack's Accounts table, plus one record in each user role table they belong to. See Managing User Records for details.

Adding a data table copy on top of that adds one more record per person.

For an app with 200 staff, a duplicate Staff data table adds 200 records you don't need. In larger apps with several kinds of people, it adds up fast.

Choose the Table Type Before You Build

A table is either a data table or a user role table, and it can't be converted later. If a data table holds people who should sign in, the only fix is to create a new user role table, move the people and their connections into it, and delete the old table.

Decide which tables hold people who sign in before anything is built. If you're working with a frontend builder, say so in your first prompt.

These tables hold people who sign in, so create them as Knack user role tables, not data tables: [list your roles].

Store every detail about each person directly in their user role table. Do not create a separate data table for the same people.

Point Your Connections at the Role Table

Every table that relates to a person should connect directly to that person's user role table. Appointments connect to Patients. Timesheets connect to Staff. Documents connect to whoever they belong to.

This keeps ownership and access rules simple. See Designing Your Data Model for Access Control for why direct connections matter.

Check Your App for Duplicate People Tables

If your app is already built, ask your frontend builder to look for duplicates before you change anything. This prompt is read-only.

Audit only. Make no changes.

List every Knack table that holds people: staff, clients, patients, families, contacts, or similar. For each one, tell me:
1. Whether it's a user role table or a data table
2. Its record count
3. Whether the same people also appear in another table, and which one
4. Which other tables connect to it

Do not show any record values or personal information.

Then open the Knack Builder and confirm what it found. If a data table and a role table hold the same people, plan to move the people and their connections into the role table.

Common Mistakes

• Keeping a "profile" data table next to a role table. Put the profile fields in the role table instead.
• Creating people who sign in as a data table. It can't be converted. Decide the table type before you build.
• Connecting records to the data table copy. Records connected there don't belong to the person who signs in, so access rules won't show them.
• Counting only data records when sizing your plan. Every person who signs in counts at least twice.

Next Steps

• Do I Need a Separate User Role Table?: Decide when an organization table and a role table belong together.
• Designing Your Data Model for Access Control: Connect your tables so access rules work the way you expect.
• What Decides a User's Role: Learn how Knack decides a user's role from their account.