Skip to content
Local environment Preproduction — not production data

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.

  • 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).
ExecutorDeveloperAdminOperator
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.

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.

WorkspaceExists fromOperatorFactorial team adminTeam’s main contactDeveloperExecutor
dev-{appId}the App is createdwritewritewritewriteread + run
prod-{appId}a release is requestedwritewrite
prod-{appId}the release is marked deployedwritewritewrite¹
deploy-{deployId} (development install)the installation is createdwritewrite¹write¹
deploy-{deployId} (customer install)the installation is createdwritewrite¹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.
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.

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.