packages/twenty-docs/user-guide/permissions-access/capabilities/permissions.mdx
Twenty's permission system allows you to control access to three main areas:
To create a new role:
To delete a role:
Permissions determine what each role can access or modify within your workspace, including workspace objects records, settings, and actions.
The Objects section controls what this role can do with records across your workspace.
First, configure the baseline permissions that apply to all objects by default:
| Permission | Description |
|---|---|
| See Records on All Objects | View records in lists and detail pages |
| Edit Records on All Objects | Modify existing records |
| Delete Records on All Objects | Soft-delete records (can be restored) |
| Destroy Records on All Objects | Permanently delete records |
Select or unselect based on what should be the default behavior for this role.
<Note> **Example — Intern role**: An intern should be able to see all objects but not edit them by default. Enable "See Records on All Objects" but leave "Edit Records on All Objects" unchecked. </Note>After setting defaults, use the Object-Level sub-section to add rules that override the defaults for specific objects.
Click + Add rule and select an object to create an exception.
Example rules for an Intern role:
| Rule | Effect |
|---|---|
| Opportunities → disable "See Records" | Intern cannot see the Opportunities object at all |
| People → enable "Edit Records" | Intern can edit People records (but not other objects) |
Within each object-level rule, you can go further and configure field-level permissions to control access to specific fields.
| Permission | Description |
|---|---|
| See Field | View the field value |
| Edit Field | Modify the field value |
| No Access | Field is completely hidden |
Example — Restrict sensitive fields:
For the Intern role with People edit access, you might want to restrict certain fields:
This allows the intern to edit most People fields while protecting sensitive information.
Permissions cascade from general to specific:
More specific settings always take precedence.
To override inherited permissions:
When done, click Finish, then Save once redirected to the role page.
Control access to workspace settings in two ways:
Control access to general workspace actions:
Beyond workspace members, roles can also be assigned to API Keys and AI Agents. This is particularly helpful for teams who want to control exactly "who" can do what in their workspace—including automated processes and integrations.
The API key will now inherit all permissions defined by that role. Any API calls made with this key will be restricted accordingly.
<Note> API keys without an assigned role use default permissions. For tighter security, always assign a specific role to production API keys. </Note>The AI agent will only be able to access data and perform actions allowed by its assigned role.
<Note> For AI agents running within workflows, this ensures the agent cannot access or modify data outside its intended scope—even if the workflow has broader permissions. </Note>