Overview
Some apps need access decided somewhere other than Zite — an Airtable roster, a CRM, an HR system, an internal API. Custom access rules let your app ask that system at the moment it matters: when someone tries to sign up, when they sign in, and periodically while they’re using the app. You describe what you want in the chat. The Agent writes the rules, and they appear in your app’s authentication settings.Custom access rules apply to public apps. Access to an internal app comes from your organization’s permissions instead.
The five rules
An app can use any combination of these. Most apps that need custom rules use two or three.
The first two decide who gets in. After sign up and After sign in don’t block anyone; they run alongside, which makes them the right place to record something or notify another system. Session check is what catches someone who was allowed in earlier but shouldn’t still be there.
What you can do
Gate sign-ups against a list
Only let people already in an Airtable base, a CRM, or another table sign up.
Revoke access automatically
Block sign-in for anyone removed from that list, and sign them out if they’re already using the app.
Push new sign-ups outward
Send everyone who signs up to another system, so your CRM or mailing list stays current.
Create a profile record
Add a row to a table in your database the moment someone signs up.
Show details from your records
Put a plan, department, or account number from your own data onto the signed-in user.
Combine with your settings
Let a roster admit people your sign-up setting would otherwise turn away.
Set up a rule
1
Decide what should happen and when
Be specific about the moment. “Only people in the Members table can sign up” is a Before sign up rule. “Sign people out when they’re removed from the Members table” is a Session check rule. If you’re not sure, describe the behavior and let the Agent pick.
2
Ask in the chat
Name the table or service, name the field that holds the email address, and say what should happen when there’s no match.
3
Review the rules
Click
Users on the top nav bar, switch to Authentication, and scroll to Custom access rules. Each rule the Agent added is listed with a short description of what it does.4
Test before you publish
Use Preview as user to open the app as one of your users and confirm the rules behave the way you expect.
5
Publish
Click
Publish in the upper right. Rules take effect for real visitors once the app is published.Example prompts
Where to find your rules
Custom access rules appear in your app’s authentication settings once the app has them — the section is hidden on apps that don’t. ClickUsers on the top nav bar, switch to Authentication, and scroll to Custom access rules.
Click Chat about this to open the chat with the rules attached, which is how you change them without touching code.
How rules interact with your other settings
Rules run in addition to Who can sign up?, and they can override it. The practical pattern for a roster-gated app: set Who can sign up? toInvite only, then add a Before sign up rule that admits anyone on your roster. The roster and your invitations become the only two ways in.
When you invite someone from the
Users tab, Zite checks your Before sign up rule first and warns you if the rule would turn them away. You can send the invitation anyway.What rules can reach
A rule can use anything the rest of your app can use — your Zite Database, a connected Airtable base, and external services your app already talks to.Custom access rules live in a file in your app’s code, and the Agent writes and edits it for you. If you’d rather write it yourself, see the developer documentation for the rule signatures and return values.
If a rule can’t run
Rules fail open. If the system a rule checks is unreachable, or the rule takes too long, Zite treats the result as “no opinion” and falls back to your normal settings rather than locking everyone out. This is why pairing a roster rule withInvite only matters: if your roster is briefly unavailable, sign-up stays closed instead of opening to everyone. Rostered users see a temporary failure and can try again.
Session check results are cached for a few minutes, so removing someone from your roster signs them out within minutes rather than instantly.