Who can see what, down to the record
Roles carry entity-scoped permissions, row-level security restricts which records a user can see, and group-scoped reads extend that to a team without opening every record to every teammate. All three are enforced at the API, not reimplemented in your app.
The same task, three ways
Every task works three ways, and all of them change the same project. Here's one: a support role that can read and update orders, with each person seeing only the orders they're given.
The Anythink dashboard
Create the role, switch on row-level security, then grant access record by record.
The Anythink CLI
Scriptable, so the same access rules can go into every project.
$ anythink roles create support --description "Support agents"# 12 is the id that roles list shows for support$ anythink roles permissions add 12 orders --actions read,update$ anythink entities update orders --rls true$ anythink data rls orders 42 --user 72- ✓Role support can read and update orders
- ✓Row-level security is on for orders
- ✓User 72 can see and edit order 42, and no other order
Claude, through MCP
Describe the access you want. It runs the same commands and tells you what it did; you can check every change in the dashboard.
you › “Create a support role that can read and update orders. Turn on row-level security for orders, then give user 72 access to order 42 only.”
- ✓Role support created with read and update on orders
- ✓Row-level security switched on for orders
- ✓User 72 granted access to order 42
- ✓Administrators still see every order
Access control that matches how teams actually share data
Roles and permissions control what an action can do. Row-level security controls which records it can do it to.
Permissions named entity:action
Every permission follows the same shape — blog_posts:read, orders:update, anythink_group_data:read. Assign them to roles, assign a role to a user, and every API call, workflow step and dashboard view checks the same permission set.
Custom roles, entity-scoped
Create as many roles as your team structure needs. Each permission on a role is scoped to one entity and one action, so an editor role can read and update articles without being able to delete them.
Row-level security set at creation
A Create Data workflow step can set row-level security on the record it just created — auto_set_rls plus the field that links it to a user — so a new record is scoped to its owner the moment it exists, not in a follow-up write.
Managing access after the fact
An Update Data step manages RLS on an existing record with rls_mode: add, remove or set — grant a second user access, revoke it, or replace the access list outright, from inside a workflow.
Group-scoped reads
Pass ?group_scope=<group_id> on a read and a user sees records shared with that group, provided they hold a membership role in it with the anythink_group_data:read permission. Being a group's admin doesn't grant this by itself — membership and the read permission are checked separately.
Enforced at the API, not in your app
Permissions, row-level security and group scope are all checked server-side on every request. There's no separate authorisation layer to keep in sync with your frontend — the same rules apply whether the call comes from the dashboard, the API, or a workflow.
In practice
Permissions, row-level security and group reads as they're actually configured
anythink workflows step-add 33 create-ticket \ --name "Create ticket" \ --action CreateData \ --params '{ "entity": "support_tickets", "data": { "subject": "{{ $anythink.trigger.data.subject }}" }, "auto_set_rls": true, "rls_user_field": "created_by" }' \ --start --enabled
What you can build
Multi-team SaaS with per-user isolation
Set row-level security on every record at creation, scoped to the user who created it. Each user sees only their own records, enforced at the API, with nothing to configure per request.
Team workspaces without opening every record to everyone
Put teammates in a group, grant the group's members the anythink_group_data:read permission, and reads scoped with ?group_scope can return records shared with the group — distinct from the per-user grants a record might also carry.
Role-gated write paths
An editor role gets articles:read, articles:create and articles:update, but not articles:delete. The same permission check runs whether the write comes from the dashboard, a direct API call, or a workflow step.
Frequently Asked Questions
How are permissions named in Anythink?
{entity}:{action} — for example blog_posts:read or orders:update. Permissions are assigned to roles, and each user has one role that determines what they can do.
How does row-level security work?
When RLS is set on a record, only the users or groups granted access can read or write it. A Create Data workflow step can set this automatically at creation (auto_set_rls, rls_user_field); an Update Data step changes it afterwards with rls_mode: add, remove or set.
Can I create custom roles with specific permissions?
Yes. Create unlimited custom roles, each with its own description and active status. Permissions are entity-scoped and assigned to the role; each user is assigned exactly one role.
What's the difference between group-scoped RLS and a normal role?
A role determines what a user can do across the system. Group-scoped RLS determines which records within an entity a specific group can see, on top of that. A user needs a membership role inside the group and the anythink_group_data:read permission to read group-scoped records — admin rights over the group itself don't imply that.
Can a group have write access to shared records?
Not today. Group-scoped access currently covers reads. Writes are scoped to the user or users set directly on the record's row-level security, not to the group as a whole.
Still have questions?
Get in TouchMore in the same project
Every feature reads from the same data model, so each one you add works with the rest.
Ways to build with it
The dashboard, the CLI, MCP and the SDK, plus guides for moving from other platforms.
Who it's for
How founders, agencies and enterprise teams use Anythink.
Documentation
Guides and reference at docs.anythink.cloud.
Ready to build with security built in?
Set up roles, permissions and row-level security in the dashboard, so each user gets the access they need and nothing more.