How deployments work
A deployment is a persistent, reusable way to run a workflow automatically: on a schedule, via an API call, from another workflow, or as a browser-based app. This guide explains the deployment types, what every deployment needs, whose permissions a deployment uses, and who can run and manage it. To learn how running a workflow works in general, see Running workflows.
Deployment types
Each deployment type targets a different use case.
| Type | Use when |
|---|---|
| Data apps | Non-technical users need to interact with a workflow through a browser UI |
| Service deployments | External systems need to call the workflow and receive a synchronous response |
| Scheduling | The workflow should run automatically on a fixed time interval |
| Trigger deployments | The workflow should run automatically when an event happens |
You can create multiple deployments of different types for the same workflow, and deploy different versions of it at the same time. A workflow's deployments are listed on its workflow page and on the team's Deployments page.
What every deployment needs
When creating a deployment, you need to select:
- A workflow version: a named, immutable snapshot of the workflow. Deployments cannot be created for unversioned workflows. See How to version your work.
- An environment where the workflow runs.
Deployment execution scope
The execution scope decides whose permissions a deployment runs with:
- Team scope (default): the deployment runs with team-level permissions.
- User scope: the deployment runs with the permissions of the user who executes it.
WARNING
Team-scope deployments can't access spaces restricted to admins. This keeps admin-only resources protected even when team-level permissions apply.
When to use each scope
Use team scope when the deployment should run independently of any individual user:
- Consistent execution: users outside the team can run the deployment, for example a shared data app, regardless of their own access to spaces or secrets, as long as they can access the deployment.
- Reliable scheduling: if the team member who created a schedule leaves the team, the schedule keeps running.
Use user scope when you need tight control over the identity and permissions of the user executing the deployment.
If you use Kerberos authentication, use user scope. Team scope isn't supported with Kerberos.
The execution scope also determines which secrets are available to the workflow during execution. See Secrets in deployments.
Change the execution scope
Choose the scope when you create the deployment. Afterwards:
- You can change a user-scope deployment to team scope only once.
- To change a team-scope deployment to user scope, delete it and create it again.
Set user execution scope for new deployments
- In the deployment panel, go to Advanced configuration
- Find Execution Scope under Additional settings
- Change the selection to User
Change an existing deployment to team execution scope
- Click the three dots menu on the deployment's row
- Select Edit, and go to Advanced configuration
- Find Execution Scope under Additional settings
- Change the selection to Team
Parameterize workflows with Configuration nodes
You can pass parameters to a workflow when it runs by using Configuration nodes.
Add Configuration nodes at the root level of the workflow, not inside a component. Each parameter can then be:
- Preconfigured with a default value, set in the node's configuration dialog.
- Set at execution time, in the panel that opens when you click Run on the workflow page or when you create a deployment.
Who can run and manage a deployment
Access to a deployment depends on the access level granted to a user or team: Run, Run & Inspect, or Manage. See Roles and permissions for what each level allows.
How users reach a deployment depends on its type:
- Data apps: users open the data apps they have access to from the Data apps page, grouped by category. See Find and open a data app.
- Service deployments: callers authenticate with their own application password from an external tool such as Postman. See Service deployments.
Next steps
Continue with one of these guides:
- Deploy your first data app: build and publish a data app step by step
- Troubleshooting: fix common deployment problems