Users and security

Access control in Anythink works through a sophisticated but user-friendly system that gives you precise control over who can do what in your application. Whether you need simple role-based access for a small team or complex multi-layered permissions for an enterprise application, Anythink's security model adapts to your needs.

Built around the principle of least privilege, the system ensures users have exactly the access they need to be productive while protecting sensitive data and operations from unauthorised access.

Understanding the Access Control Layers

Anythink's security model works through four distinct but interconnected layers, each providing progressively more granular control over user access.

System-Level Access

At the highest level, users are granted or denied access to major system components:

• Dashboard Access (Breeze UI) - Can users access the visual dashboard interface?

• API Access - Can users make direct API calls to your endpoints?

• Administrator Privileges - Does the user have unrestricted access to everything?

These fundamental settings determine what parts of your Anythink instance a user can even see, providing the foundation for all other access controls.

Role-Based Permissions

The core of your access control strategy revolves around roles and permissions. Each role represents a collection of permissions that make sense for a particular type of user in your organisation.

Standard Resources

Every Anythink project comes with permissions for essential platform features:

• Documentation - Access to your project's documentation

• Entities - Creating and managing your data models

• Fields - Adding and configuring entity fields

• Workflows - Building and managing automation

• Modules - Installing and configuring platform extensions

• Files - Uploading and managing file assets

Administrative Resources

For users who need to manage the platform itself:

• Menus - Configuring dashboard navigation and role-specific interfaces

• Roles - Creating and editing user roles

• Permissions - Managing access control rules

• Users - Adding and managing user accounts

Each resource supports four standard actions:

• Read - View and browse existing items

• Create - Add new items

• Update - Modify existing items

• Delete - Remove items permanently

This creates a matrix of permissions like users:read, entities:create, or files:delete that you can assign to roles with surgical precision.

Entity-Level Security

Control access to entire data entities by enabling Row-Level Security (RLS) on specific entities through your data model configuration. When RLS is enabled:

• Entity becomes private by default - Only users with explicit access can see any records

• Granular record access - Grant access to individual records on a per-user basis

• Read-only or full access - Control whether users can modify records they have access to

• Administrative bypass - Administrators always have full access regardless of RLS settings

Field-Level Security

For even more granular control, you can restrict which specific fields within an entity a role can access. This is perfect for scenarios where different team members need access to the same data but with different levels of detail.

Field-level security works by:

• Defaulting to accessible - New fields are available to all roles unless explicitly restricted

• Protecting system fields - Core fields like id, created_at, and updated_at are always accessible

• Supporting real-time updates - Changes take effect immediately across all interfaces

• Search visibility control - Fields can be made publicly searchable or restricted through search configuration

Dashboard Personalisation by Role

Role-Specific Menu Configuration

Different roles can have completely different dashboard experiences through customised menu configurations:

• Hide irrelevant sections - Customer service roles don't need to see data modelling tools

• Highlight key features - Put the most important tools front and center for each role type

• Streamline workflows - Create focused interfaces that match how different users actually work

• Maintain consistency - Ensure similar roles across projects have similar experiences

This means your content editors see a dashboard focused on data management, whilst your administrators see system configuration options, and your analysts see reporting and search tools.

Building Your Role Strategy

Default Roles

Every new Anythink project starts with two fundamental roles that cover most basic scenarios:

Standard User

• Read access to documentation, entities, fields, workflows, modules, and files

• Create access to workflows and files

• Perfect for team members who need to use the platform but not configure it

Admin User

• Full administrator privileges with unrestricted access

• Can manage users, roles, permissions, and all system configuration

• Bypass all field-level and row-level security restrictions

Custom Role Design

For most real-world applications, you'll want to create custom roles that match your organisation's structure and workflow. Consider these common patterns:

Content Manager

• Full access to entities and fields (for data model management)

• Read-only access to users and workflows

• File upload and management permissions

• No access to roles or system configuration

Data Analyst

• Read access to all data entities

• File access for reports and exports

• No modification permissions for data models or workflows

• Perfect for team members who need to analyse but not change data

Customer Support

• Read and update access to customer-related entities

• Row-level security for assigned cases only

• No access to financial or administrative data

• Workflow permissions for status updates and notifications

Role Assignment Strategy

Think about role assignment as part of your overall user journey:

1. Default role for new users - What should someone get when they first join?

1. Promotion paths - How do users gain additional permissions over time?

1. Temporary access - How do you handle contractors or short-term team members?

1. Cross-functional needs - How do you handle users who need different access in different contexts?

Advanced Access Control Features

Field-Level Security Configuration

When standard role permissions aren't granular enough, field-level security gives you surgical control over data access. From the role management interface, you can:

• Enable/disable field access with simple toggle switches

• See system field protection - certain fields are always accessible and clearly marked

• Make bulk changes across multiple fields for efficient role configuration

• Preview access patterns before saving changes

This level of control means you can have a "Customer Service" role that sees customer contact information but not payment details, or a "Finance" role that accesses billing information but not personal notes.

Row-Level Security Implementation

Row-level security transforms how users interact with your data by creating personalised views of shared entities:

When RLS is enabled for an entity:

• Users only see records they've been explicitly granted access to

• Access can be read-only or read-write on a per-record basis

• Administrators can assign record access through the dashboard interface

• API responses automatically filter to only include accessible records

Managing RLS access:

• Add users to specific records through the dashboard

• Set read-only or full access per user per record

• Remove access when users no longer need specific records

• Audit who has access to which records for compliance

Multi-Project Access Patterns

For organisations using multiple Anythink projects, user access becomes even more sophisticated:

• Different roles per project - A user might be an admin in one project and a viewer in another

• Consistent user identity - One account works across all projects they have access to

• Project-specific permissions - Role configurations are isolated between projects

• Seamless project switching through the dashboard interface

API Integration and Programmatic Control

Permission Checking in Custom Applications

When building applications that consume your Anythink APIs, you can programmatically check user permissions:

GET /api/permissions/entity/{entityName}

{
  "read": true,
  "create": false, 
  "update": true,
  "delete": false
}

This allows your applications to adapt their interface based on what the current user is allowed to do, creating a seamless experience that respects your access control rules.

API Key Authentication

For service accounts and automated systems, API keys provide an alternative to user-based authentication:

• Scoped to specific users - API keys inherit the permissions of their associated user account

• Perfect for integrations - Connect external services without sharing personal credentials

• Audit trail friendly - API key usage appears in logs with clear identification

• Revocable access - Disable API keys instantly without affecting user accounts

Security Best Practices

Role Design Principles

Start minimal and expand

Begin with the least access necessary and add permissions as users demonstrate need for additional capabilities.

Use descriptive names

Role names like "Content Editor" or "Customer Support Agent" are immediately clear to administrators and users alike.

Document your access patterns

Keep notes about why certain roles have specific permissions - this helps when onboarding new administrators or auditing access.

Regular access reviews

Schedule periodic reviews of who has what access, especially for roles with elevated permissions.

Field-Level Security Strategy

Protect financial data by default

Consider making fields containing payment information, salaries, or financial projections restricted by default.

Think about compliance requirements

If your industry has specific data protection requirements, use field-level security to ensure only authorised personnel can access regulated information.

Consider user experience

Hiding too many fields can make interfaces confusing - strike a balance between security and usability.

Row-Level Security Guidelines

Enable RLS thoughtfully

Row-level security adds complexity to your application - only enable it for entities where record-level access control is truly necessary.

Plan your access patterns

Before enabling RLS, think through how users will gain access to records and who will manage those assignments.

Monitor performance

RLS adds database queries to check access - monitor your application performance and optimise as needed.

Operational Security

Use administrator roles sparingly

Administrator access bypasses all security controls - only grant it to users who genuinely need unrestricted access.

Implement the principle of least privilege

Users should have exactly the permissions they need to do their job, nothing more.

Plan for user lifecycle management

Have clear processes for what happens when users change roles, leave the organisation, or need temporary elevated access.

Regular security audits

Periodically review role assignments, especially for users with elevated permissions or access to sensitive data.

Anythink's roles and permissions system grows with your organisation, providing the security foundation you need whilst maintaining the flexibility to adapt as your needs evolve. Whether you're protecting customer data, ensuring compliance, or simply organising team access, the system provides the tools you need without getting in the way of productivity.

Anythink Auth supports common authentication methods including password, magic link and one-time passwords (OTP).

Authentication and authorisation

It's not just authentication though, there is also authorisation. Authentication is about checking if the user is who we think they are, Authorisation is about making sure they are only allowed to see the things they're allowed to see.

As with most modern authentication systems, Anythink uses JSON Web Tokens (JWTs) for authentication and these integrate seamlessly with our Anythink entities for auhtorisation, providing role based access restrictions to entities and row level security (RLS) for each field of an entity.

Auth also enables access control to your dynamic API. When using your API for restricted content, you can pass your users auth token (JWT) along with your requests and the data returned will be scoped to that user according to the row level security (RLS) policies you have specified when you configured your entities.