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:
- Default role for new users - What should someone get when they first join?
- Promotion paths - How do users gain additional permissions over time?
- Temporary access - How do you handle contractors or short-term team members?
- 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.