Who can do what

Permissions in Standards come down to five actions. Roles are built by combining them, not the other way round.

The five actions

• Read: see records and what is in them.
• Create: add new records.
• Update: change the content of existing records.
• Delete: send them to the trash.
• Manage: the level above, which controls permanent deletion among other things.

These actions are granted object by object. You can read contracts without updating them, and create tasks without touching customers.

A second scope, the platform one, covers resources that are not records: the structure of the workspace, the settings.

What this looks like in practice

Three situations that come up everywhere.

The outside consultant reads the records of the case they work on, and nothing else. Read only, on a narrow scope.

The case owner reads, creates and updates within their area, but does not delete. Deleting stays a manager's move, even though the trash catches mistakes.

The administrator has all five actions, and can also change the structure of the workspace.

An agent has its own rights

This is the point to take away from this article, and it often comes as a surprise.

An agent does not borrow your rights. It is an actor in its own right, with its own identity and its own role, separate from yours. When it works, its access is checked against that identity, not against yours.

What the platform does keep is the delegation chain: who started the agent, and on whose behalf. So the log always lets you trace an action back to the person behind it.

When something looks blocked

Before asking for more rights, check three more common causes.

The field may be computed: by design, nobody can type into it.

The view may be read only: that is a display setting, not a permission. Another view of the same object may well be editable.

The field may be part of the foundation laid by your technical team, which the workspace protects so that nothing built on it breaks.