Access Control.

Nextly's access control system supports five rule types: public (anyone), authenticated (logged-in users), role-based (specific roles), owner-only (record creator), and custom (code-defined functions). These rules can be set per operation (create, read, update, delete) on each collection.

For code-first collections, you define access rules using simple booleans or access functions that receive the user and their roles. Functions can be synchronous or asynchronous. Call external services, check databases, or apply any custom logic. For UI-created collections, access rules are configured from the admin panel and stored in the database.

Field-level permissions let you control read and write access to individual fields per role. This is useful for hiding sensitive data like internal notes, salary, or API keys from unauthorized roles.

Key capabilities

• Role-Based Access (RBAC) — 3 default roles: admin, editor, viewer. Role-based rules use OR logic, so a user with any of the allowed roles gets access.
• Owner-Only Access — Restrict access to records owned by the current user. Configurable owner field (defaults to createdBy). Auto-applied to queries.
• Field-Level Permissions — Control read and write access to individual fields per role. Hide sensitive data in components from unauthorized roles entirely.
• Code + Database Hybrid — Define access rules in code for version-controlled collections, or configure them from the admin panel for UI-created collections.

Access control in a collection

Set CRUD permissions with simple booleans or access functions that receive the user and their roles. Return true to allow, false to deny.

import { defineCollection, text, select } from "nextly/config";

export default defineCollection({
  slug: "posts",
  fields: [
    text({ name: "title", required: true }),
  ],
  // Built-in Draft / Published lifecycle
  status: true,
  access: {
    // Anyone can read published posts
    read: true,

    // Only authenticated users can create
    create: ({ user }) => !!user,

    // Editors and admins can update
    update: ({ roles }) =>
      roles.includes("admin") || roles.includes("editor"),

    // Only admins can delete
    delete: ({ roles }) => roles.includes("admin"),
  },
});

Access functions receive user, roles, permissions, operation, and collection. They can be async: call external services, check databases, or apply any custom logic.

Five access rule types

Choose the right rule type for each operation. UI-created collections use these storable rule types; code-first collections can use these or custom functions.

• public — Anyone can access. No authentication required.
• authenticated — Only logged-in users can access.
• role-based — Only users with specific roles (OR logic: any matching role grants access).
• owner-only — Only the document creator can access. Uses a configurable owner field (defaults to createdBy).
• custom — Reference to a code-defined function for complex logic. Code-first collections only.

Down to the field level

Control read and write access to individual fields per role. Sensitive fields can be hidden from unauthorized roles entirely.

// Hide salary from all non-admin roles
{
  roleId: "viewer",
  collectionSlug: "employees",
  fieldPath: "salary",
  action: "none", // No read or write access
}

// Allow editors to write to the phone field
{
  roleId: "editor",
  collectionSlug: "users",
  fieldPath: "profile.phone", // Dot notation for nested fields
  action: "write",
}

Field actions: read (can see, can't edit), write (can see and edit), none (completely hidden). Dot notation is supported for nested field paths.

Default role permissions

• admin — Create, read, update, delete: all allowed. Full access (super-admin).
• editor — Create, read, update allowed; delete denied. Content management, no deletions.
• viewer — Read only. Create, update, delete denied.
• custom — Defined per collection.

The admin role has super-admin access that bypasses all checks.