Roles & permissions

Your role belongs to your development team, not to a single workspace: whatever role you hold, you hold it everywhere the team grants you access. What changes from workspace to workspace is whether you have access at all — and that is what moves as an App progresses from development to a released, installable product.

The roles

Executor — can read everything in the workspace and run processes, but cannot change them.
Developer — the working role: writes processes, modules, team variables, schedules and dependencies, and publishes workspace versions.
Admin — a developer who also manages the team: invites members, changes their roles, and can delete the workspace.
Operator — the Factorial Code platform team. Reaches every workspace, and owns the things no team can do for itself (creating workspaces, billing).

What each role can do in a workspace

	Executor	Developer	Admin	Operator
Read processes, modules, variables, versions, logs	✓	✓	✓	✓
Run, re-run and cancel executions	✓	✓	✓	✓
Write processes, modules, variables, schedules, dependencies	—	✓	✓	✓
Publish a workspace version, move a version alias	—	✓	✓	✓
Change workspace settings	—	✓	✓	✓
Manage members, delete the workspace	—	—	✓	✓
Create workspaces, change the billing plan	—	—	—	✓

Roles are cumulative: an admin can do everything a developer can, and a developer everything an executor can.

Who reaches which workspace

Each App has a development workspace from the start, a production workspace from its first release, and one workspace per customer installation — see Workspace hierarchy for how they inherit from each other.

Workspace	Exists from	Operator	Factorial team admin	Team’s main contact	Developer	Executor
`dev-{appId}`	the App is created	write	write	write	write	read + run
`prod-{appId}`	a release is requested	write	write	—	—	—
`prod-{appId}`	the release is marked deployed	write	write	write¹	—	—
`deploy-{deployId}` (development install)	the installation is created	write	write¹	write¹	—	—
`deploy-{deployId}` (customer install)	the installation is created	write	write¹	write¹	—	—

¹ One person per team, not the whole roster: the main contact is the team’s stored admin, or its first member when no admin is stored — so on an external team it may not be an admin at all. It is the address the platform notifies about the App, given access to what those messages talk about.

Two things follow from that table:

Everyone on the roster works in dev-{appId}, each with their own role. This is where you build, and the only workspace a developer or executor ever writes to.
Production is admin territory. A team admin with a Factorial address gets write access on prod-{appId} as soon as a release is requested, which is what lets them promote the App themselves. Everyone else’s route into production is a Factorial operator.

What a Factorial team admin can do beyond building

The same people who can promote a release — a team admin with a @factorial.co, @factorial.com or @factorial.dev address on the App’s own development team — also own a few actions that reach customers directly. Admins of external teams and plain developers do not get them, and everyone else’s route to any of them is a Factorial operator.

Link or unlink the App’s DatoCMS record — the Factorial-curated record that supplies its localized marketplace content. Everyone else asks for the link with the console’s Request DatoCMS link button.
Suspend, deprovision or remove a customer installation. Doing the same to a development installation is open to any member of the App.
Delete an App that already has customer installations, which destroys those customers’ workspaces. Deleting an App with no customer installations is open to any member of the App.

How that plays out over an App’s life

App created            Release requested       Marked deployed          Customer installs
     │                        │                       │                        │
     ▼                        ▼                       ▼                        ▼
dev-{appId}             prod-{appId}            App is published         deploy-{deployId}
├─ admin      write     ├─ operator   write     ├─ main contact  write   ├─ operator      write
├─ developer  write     └─ Factorial            └─ live on the           └─ main contact  write
└─ executor   read         team admin  write       Marketplace

Requesting a release is open to any member of the App: it snapshots the development workspace as a workspace version and creates prod-{appId}. Promoting that version into production, and marking the release deployed, is the step that takes a Factorial team admin or an operator — marking the first release deployed is what publishes the App and makes it installable by customers.

Getting the role you need

Team admins manage their own roster from the Factorial Code console: they invite members and change roles. If your team has no admin yet, or you need something only the platform team can do, ask a Factorial operator.