Multi-Tenant Apps with a Custom Frontend: Choosing the Right Setup

What You'll Learn

This article is for multi-tenant apps built with a custom frontend, using a frontend builder like Lovable, Base44, or Claude Code with Knack as your backend. A multi-tenant app serves more than one group, like several clinics, locations, or client businesses. You'll learn which kind of multi-tenant app you're building and how to set up access in Knack so each group sees the right records.

What a Multi-Tenant App Is

A tenant is one group inside your app. It might be one clinic, one location, one team, or one client business.

In a multi-tenant app, each group works in the same kind of app, but they shouldn't all see the same records. For example, staff at your downtown clinic see downtown's appointments, and leadership sees every clinic.

Set Access in Knack, Not in Your Screens

Who can see and change records is set in Knack's Data Access Control. Your frontend decides what each screen shows, but it doesn't control access.

• Filtering chooses which records a screen shows. Think of it as a curtain.
• Data Access Control decides which records a user can reach at all. Think of it as a lock.

Your screens decide what each person sees first. Data Access Control decides what each person can reach at all. Set up access in Data Access Control first, then build your screens around it.

Which Kind of Multi-Tenant App Are You Building?

"Each clinic should only see its own patients" can describe two different setups. The right configuration depends on which one you have.

One organization with several locations

One business owns every location. Examples include a health system, a group practice with five offices, or a franchise owner.

• Leadership, billing, and admins usually see every location.
• Staff mostly work in their own location.
• Patients or customers may move between locations.

Separate businesses served by one provider

Each client is its own business. Examples include a consultant who provides an app to 20 independent practices, or a software company whose customers are clinics.

• Each client owns its own data.
• Nobody at one client should ever see another client's records.
• Each client may want its own branding, its own users, or to take its data with it if it leaves.

These questions help you tell them apart:

• Who owns the business, one organization or each location?
• Does anyone need to see records across every location? Who?
• Do people or records move between locations?
• If a location leaves, does it take its data with it?
• Does each location want its own branding or sign-in page?

Setting Up One Organization with Several Locations

Use one Knack app for the whole organization. Because every location belongs to the same business, access is set at the organization level.

• Give leadership, billing, and admin roles access to all records.
• Give staff roles access to the organization's records, so they can help across locations when needed.
• Build your screens so each person sees their own location first, like "Appointments at my location."

Setting Up Separate Businesses

Use a separate Knack app for each client business, each with its own frontend.

• Each client's data stays completely separate.
• Each client gets its own users, roles, and sign-in setup.
• If a client leaves, their app and data can move or close without affecting anyone else.

Common Access Patterns That Work Well

These patterns fit most multi-tenant apps, whichever setup you choose.

Each person sees only their own records

This fits a patient portal, a client portal, or a directory where people edit only their own profile. Give the role access to records they own and No Access to all other records. Then make sure each record's Owned By field is set to that person.

Each staff member owns their own work

This fits sales reps with their own leads, field workers logging their own visits, or providers with their own appointments. Give the staff role access to records they own. Give managers access to all records.

Staff create records for someone else

This fits a front desk booking an appointment for a patient. Records are owned by the user who created them, so set Owned By to the person the record belongs to. See Who Owns a Record Created from a Custom Frontend for how to set this up.

Leadership sees everything

Create a separate Admin role with access to all records. Keep this role small.

Access that changes with a record's status

Some records need different access at different stages. For example, a clinical note the author can edit as a draft, but only view once it's signed. Split these into two tables, like Draft Notes and Signed Notes, and give each table its own access.

Records shared by a team or passed between groups

Some apps need a small team to share the same records, or need records like referrals to move from one group to another. Our team can help you plan the best configuration for these.

Setup Checklist

• Connect every table directly to its owner or parent. Don't rely on access following a chain of connections through several tables.
• Set access for every role on every table, including the Public role for people who aren't signed in. Public should be No Access unless a table is meant to be public.
• Turn on enforcement. Setting up the access grid and turning it on are separate steps.
• Check Owned By on imported records and on records staff create for someone else.
• Turn on connected lookups if you need them. If a screen shows records through a connection, like "Transfers connected to my location," turn on "Allow connected field lookup without table access" in your Data Access settings.

How to Check Your Access Rules

Your app showing the right records isn't proof that it's secure. Test it directly.

• Create a test login for each role. Add a test user for every role in Knack, using fictional details.
• Sign in to your published app as each test user, not inside your frontend builder's preview.
• Try to reach another group's records on purpose. If you can, your access isn't set up correctly.
• Confirm the settings yourself after your frontend builder says it configured access. Check them in the Knack Builder.

Next Steps

• Checking That Your Access Rules Actually Work: Test that Knack is enforcing who can see and change your records.
• Designing Your Data Model for Access Control: Connect your tables so access rules work the way you expect.
• Who Owns a Record Created from a Custom Frontend: Set Owned By correctly for records staff create.