Where Your App's Logic Belongs: Knack or Your Custom Frontend

What You'll Learn

When you build your app's screens in a frontend builder like Lovable, Base44, or Claude Code and use Knack as your backend, every rule in your app needs a home. This article shows you which rules to set up in Knack, which ones your custom frontend can handle, and how to plan for Knack form actions and Flows.

How to Decide Where a Rule Belongs

Think of Knack as the vault and your frontend as the lobby. The lobby controls how things look and how people move around. The vault controls what's allowed, no matter which door someone uses.

Ask one question: "If someone skipped the screens and went straight to the data, would this rule still need to hold?"

Yes: set it up in Knack.
No: your frontend can handle it.
Both: some rules belong in both places. Hide a button in your frontend so the screen looks right, and block the action in Knack so it's actually protected.

If you're still not sure, try one of these:

Does this change data, or only what someone sees? Changing data usually belongs in Knack.
Should this happen no matter how the record gets saved? Records can come from your frontend, an import, a Flow, or another integration. If the rule should apply to all of them, set it up in Knack.

Rules to Set Up in Knack

These rules protect your data or keep it accurate. Knack applies them every time a record is saved, including saves from your custom frontend.

Who can see, add, edit, or delete records. Set this in Data Access Control and turn on enforcement.
Who owns each record. The Owned By field decides who counts as the owner.
Which role a user has. Knack decides this from the user's account, not from a label in your frontend.
Who created or updated a record, and when. Knack's system fields capture this automatically.
Validation rules. Knack checks them when your frontend saves a record.
Conditional rules. Knack applies them when your frontend saves a record.
Calculations. Formula and equation fields keep every screen and report on the same number.
Automations. Knack Flows run when your frontend adds or changes a record. They can send emails and connect to other tools.
Scheduled tasks. They run based on triggers in your data, and can send emails too.

What Your Custom Frontend Handles

These rules shape how your app looks and feels. They don't need Knack.

Layout and design: pages, navigation, colors, dashboards, and print views.
Form flow: multi-step forms, field order, and helpful messages.
What happens after saving: confirmation messages and where the user goes next.
Display touches: badges, sorting, and friendly date formats.
Convenience filters: like "My upcoming appointments," as long as Knack already controls who can see those records.
Starting values: defaults and pre-filled fields the user can change.

Handling Knack Form Actions in a Custom Frontend

Knack forms include Submit Actions, Record Actions, and Email Actions. When your frontend builder creates your forms, those actions don't come along. Each one still has a clear home.

Knack form action	What it does	Where to set it up
Submit Actions	Shows a message or sends the user to another page after saving	Your frontend
Record Actions for starting values	Fills in a value the user can change	Your frontend
Record Actions for who and when	Records who created or updated a record, and when	Knack system fields (automatic)
Record Actions for values that must always hold	Sets a status or field based on other values	Knack conditional rules
Record Actions for connected records	Updates a parent record or adds a log record	A Knack Flow
Email Actions	Sends an email after saving	A Knack Flow or scheduled task

📘
Why important values belong in Knack
A value your frontend sets can be changed by any user with edit access to that record. Values Knack sets through system fields, rules, and Flows are applied every time the record is saved.

Updating Many-to-Many Connection Fields

A many-to-many connection field holds more than one connected record, like a patient connected to several providers. In a Knack form, Record Actions can add a connection, remove one, or replace them all. From your custom frontend, plan to send the full list of connections every time you update the field.

⚠️
Not yet tested: sending only the new connection
We believe an update from your frontend replaces the field with exactly what it sends. If that's true, sending only the new connection would remove the existing ones without any warning. Until this is confirmed, always send the full list, then check the record in the Knack Builder.

Here's a prompt you can give your frontend builder:

When adding a connection to a many-to-many connection field, first read the record's current connections. Send the full list back, with the existing connections plus the new one. Never send only the new connection. Tell me which record you tested so I can confirm in the Knack Builder that the existing connections are still there.

For history, like a list of visits or notes, store each entry as its own record in a connected table. Each record stays separate, so nothing gets overwritten.

Planning Your Knack Flows

Knack Flows run automations when records change. They can update records, send emails, and connect to other tools. Flows are set up in your Knack account, and your frontend builder can't create them for you, so plan them before you build.

For each automation, write down three things:

Trigger: what happens to which record, like "a Visit is added" or "Status changes to Closed."
Action: what Knack should do, like update the connected Patient, send an email, or send data to another tool.
Recipient: who or what receives it, like a staff member's inbox or another tool.

To send emails, connect your email provider, like Gmail, in your Flow.

⚠️
Keep sensitive information out of emails and connected tools
Before an email or connected tool receives patient or personal information, review your compliance requirements. If you're not sure, leave that information out. For example, send "A new visit was added. Sign in to view it." instead of including patient details. For HIPAA apps, see Flows and Third-Party Compliance.

Everyday Examples

The rule	Where it belongs
Only managers can approve a request	Knack, plus hide the button in your frontend
Clients only see their own records	Knack
Show a thank-you message after saving	Your frontend
Record who last updated a record and when	Knack system fields
Set Status to Closed when an outcome is entered	Knack conditional rule
Update a patient's last visit date when a visit is added	Knack Flow
Email a provider when a status changes	Knack Flow, without patient details in the email
Total hours on a timesheet	Knack formula or equation field
Show a red badge on overdue tasks	Your frontend
Hide the delete button from staff	Both
Sort a list by last name	Your frontend

How to Check Your Setup

Frontend builders sometimes report changes as complete when they aren't. Always confirm in Knack.

Save a test record from your published app, then find it in the Knack Builder.
Check that Knack applied your rules: system fields filled in, conditional rules applied, and validation errors shown for bad values.
Confirm your Flows ran: check the connected record, the email inbox, or the connected tool.
Test as each user role on your published app, not in your frontend builder's preview.

Next Steps

Checking That Your Access Rules Actually Work: Confirm Knack is enforcing who can see and change your records.
How to Ask Your AI Builder to Work with Knack: Write prompts that point your frontend builder at the right app, table, and field.
Knack Flows: Documentation Hub: Set up triggers, actions, and email for your automations.