> ## Documentation Index
> Fetch the complete documentation index at: https://fabricate.build/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles and record access

> Define who can use each action and verify access on the server.

Authentication establishes who is signed in. Authorization decides what that person can do. If clients, staff, or administrators see different records, describe those rules explicitly when building.

## Write an access table

| Action           | Client                | Administrator                |
| ---------------- | --------------------- | ---------------------------- |
| Create a request | For their own account | If required by your workflow |
| Read a request   | Their own requests    | All requests                 |
| Change status    | No                    | Yes                          |
| Delete a request | Define your rule      | Define your rule             |

Use your own business rules. Do not grant broad access just because an interface needs an admin screen.

## Example prompt

```text theme={null}
Add client and administrator roles to the request portal.
Every request belongs to the authenticated client who created it.
Enforce ownership and role checks on every server route that
reads or changes requests. Reject signed-out requests and reject
clients trying another client's record identifier. Do not trust
a role or user ID supplied by the browser. Keep the interface
consistent with those server rules.
```

Roles and record rules are generated for your app; they require review and testing. They are not a substitute for an access-control review when the data is sensitive.

## Verify with separate accounts

Test a signed-out visitor, two different clients, and an administrator. Check list pages, detail pages, edits, deletes, and direct requests. A client must not become an administrator by changing a field in their profile or a request body.

## Public and private publishing are separate

Fabricate's [app visibility](/docs/deploy/visibility) controls who can open the published app. Your app's own roles control what its users can do inside it. A public app may still require sign-in for private records; a private Fabricate app is not a team invitation or client permission system.

See [Authentication](/docs/build/authentication) for the built-in sign-in behavior and [Test your app](/docs/build/testing-your-app) for a complete checking sequence.