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.

01Protect real product objectsEvaluate permissions on the requested record, its owner, and the caller’s group membership.
02Grant access to selected records, files, and actions through ownership and group membership.Give owners and groups different abilities.
03Keep connected work alignedFiles and actions can follow the same subject and identity.
Why it matters

Apply the customer and record access policy consistently across APIs, files, actions, and realtime events.

Let each customer read invoices owned by their account or organization. Grant project members task-update permission and reserve project deletion for approved roles. A public visitor may read an article while an editor can publish it. Express invoice ownership, project roles, file sharing, and action access as record-level product rules.

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.

01

Express the product policy

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

02

Keep sharing understandable

Use record ownership and group membership to enforce the same permissions across every feature.

03

Reduce policy drift

Enforce record and action permissions in shared backend paths used by every client.

Make access visible

Show exactly who can do what with each business item.

Ownership, team sharing, public access, and administration stay attached to the customer, case, document, or order they protect.

Diagram showing a saved business item connected to its owner, a shared team, team members, public visitors, administrators, and specific access choices.
Choose who can do whatGive the owner, invited team members, visitors, and administrators the access appropriate to each saved item.Open diagram for full-size view
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.

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

Define a record rule once and enforce it across APIs, files, actions, administration, and live events.

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