Home / Product / Permissions

Decide who can do what

Keep access rules attached to the product they protect.

Decide what guests, owners, and teams may see or change—and carry those choices from records into relationships, files, and product actions.

See what it changes Technical guide ↗

Permissions in a product

Recognize the personGuest, customer, owner, or team member

Understand the subjectA record and the relationships around it

Allow the right experienceView, change, connect, or run an action

One decision reaches the work it governs

01Protect real product objectsApply access to the record, not only the route.

02Share without opening everythingGive owners and groups different abilities.

03Keep connected work alignedFiles and actions can follow the same subject and identity.

Why it matters

Access should follow the customer and the record—not a maze of endpoints.

A customer should see their own invoices but not another company's. A project member may update tasks but not delete the project. A public visitor may read an article while an editor can publish it. These are product rules, not merely authentication settings.

Daptin expresses access around guests, record owners, and groups. It checks the resource class, the individual record, its relationships, and named actions at the points where those decisions matter.

Because a file is attached to a record and an instance action runs against a record, access can remain connected as the application grows beyond simple screens.

Express the product policy

Separate seeing, reading, creating, changing, deleting, relating, and executing.

Keep sharing understandable

Use ownership and group membership instead of inventing a permission system per feature.

Reduce policy drift

Apply access inside shared backend paths rather than duplicating it in every client.

How it fits

Part of one connected backend.

Permissions does more when it can reuse the records, people, access rules, and workflows already in your application.

Step 1Identify

Authentication establishes a guest or account.

Step 2Locate

The request identifies the table, record, relationship, or action.

Step 3Decide

Guest, owner, and group permissions are evaluated.

Step 4Continue

The permitted request reads data, changes it, fetches a file, or runs behavior.

What it enables

Use it in products people recognize.

Start from the experience you want to create; the backend capability supports the work behind it.

Private customer records

Each company reaches only the cases and files attached to its workspace.

Editorial workflow

Readers view published content while editors and approvers manage drafts.

Shared operations

Owners update their work while supervisors receive broader oversight.

Connected by design

Build the next part without starting over.

These capabilities share the same application context, so each one makes permissions more useful.

Know the boundary

What Daptin leaves in your hands.

Daptin supplies granular permission mechanisms, but safe defaults still depend on your model. Review guest access, administrator membership, relationship sharing, protocol-specific behavior, and every newly introduced action.

Understand the operating responsibility →

Build from one foundation

Make permissions part of the product—not another disconnected service.

Run Daptin locally, explore the live administration surface, and follow one complete application path.

Get Daptin Explore all capabilities