> ## Documentation Index > Fetch the complete documentation index at: https://zite.com/llms.txt > Use this file to discover all available pages before exploring further. # Custom access rules > Let another system decide who can sign up, who can sign in, and who stays signed in to your Zite app. ## 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](/help/platform/access/share-to-web). Access to an [internal app](/help/platform/access/internal-apps) 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. | Rule | What it does | | ------------------ | ------------------------------------------------------------------------------- | | **Before sign up** | Decides whether someone new can sign up | | **Before sign in** | Decides whether an existing user can sign in | | **After sign up** | Runs after someone signs up | | **After sign in** | Runs after someone signs in | | **Session check** | Regularly re-checks signed-in users — can sign them out or update their profile | 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 Only let people already in an Airtable base, a CRM, or another table sign up. Block sign-in for anyone removed from that list, and sign them out if they're already using the app. Send everyone who signs up to another system, so your CRM or mailing list stays current. Add a row to a table in your database the moment someone signs up. Put a plan, department, or account number from your own data onto the signed-in user. Let a roster admit people your sign-up setting would otherwise turn away. ## Set up a rule 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. Name the table or service, name the field that holds the email address, and say what should happen when there's no match. ```text theme={null} Only let people whose email is in the Members table of my Airtable base sign up. Turn anyone else away. ``` 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. Use [Preview as user](/help/platform/access/authentication#test-sign-in-before-you-publish) to open the app as one of your users and confirm the rules behave the way you expect. Click `Publish` in the upper right. Rules take effect for real visitors once the app is published. ## Example prompts | What you want | What to ask for | | ------------------------------ | ---------------------------------------------------------------------------------- | | Gate sign-ups on a roster | `Only let people whose email is in the Members table sign up.` | | Block removed people | `Don't let anyone sign in unless they're in the Members table.` | | Sign people out when removed | `Sign people out if they're removed from the Members table.` | | Create a profile row | `After someone signs up, add them to the Profiles table.` | | Notify another system | `After someone signs up, send their email and name to our CRM.` | | Show extra details on the user | `Show each signed-in user their plan and account manager from the Accounts table.` | ## 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. Click `Users` 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. If an app has custom rules, its `Users` list shows a banner saying so. That list can't tell the whole story on its own — someone who isn't on it may still be admitted at sign-in, and someone who is on it may be blocked. ## How rules interact with your other settings Rules run **in addition to** [Who can sign up?](/help/platform/access/authentication#choose-who-can-sign-up), and they can override it. A **Before sign up** rule can let someone in that your sign-up setting would block. That's the point — it's how an app set to `Invite only` still admits everyone on your roster without you inviting them one by one. The practical pattern for a roster-gated app: set **Who can sign up?** to `Invite 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 with `Invite 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. ## If your app was migrated from Zite 1.0 Your app already has custom access rules — Zite generated them during migration to preserve how user sync worked. You don't need to set anything up. See [What happened to user sync](/help/platform/access/user-sync) for what those rules do and how to change them.