Environments and promotions
Every workflow has three environments: Development, Staging and Production. A version moves from Development to Staging to Production through promotion requests, and the workspace promotion policy decides which of those moves wait for an approver.
- Development and Staging each hold one version of the workflow, or nothing.
- Production is always the workflow's Active version: the one webhooks, schedules and the other automatic triggers execute. Promoting a version to Production activates it.
Runs keep the version they started with, so a promotion never changes a run that is already in progress.
Open the Environments panel
In the visual builder, select Environments in the toolbar. The panel lists the three environments in order. For each one it shows the deployed version (or Nothing deployed), when it was deployed and where it came from (for example From Staging). Open loads that version on the canvas.
Two notes can appear on an environment:
- This version was deleted after it was deployed. — the version no longer exists, so it cannot be promoted further. Deploy or promote another version.
- Activated directly, not through a promotion. — Production was changed with Activate instead of a promotion, so there is no promotion record for it.
Deploy to Development
Deploy on the Development row puts a version into Development. Any saved version can be deployed there; it needs permission to edit the workflow and never needs approval.
Promote a version
The button between two environments moves the version up one step:
- Promote to Staging moves the Development version to Staging.
- Promote to Production (or Request, when approval is needed) moves the Staging version to Production.
You can add a note for the approver. If the policy needs no approval for that step, the promotion applies at once. Otherwise it waits under Waiting for approval until someone reviews it, and the panel shows Promotion requested.
A promotion cannot be started when the source environment is empty, when the target already holds that version, when the deployed version was deleted, or while another promotion to the same target is waiting.
Approve, reject or withdraw
Pending requests are listed under Waiting for approval with the version, the requester and the note.
- Approve deploys the version to its target now. Approving a Production promotion makes it the Active version.
- Reject leaves everything where it is. You can add a reason; the requester can ask again later.
- Withdraw lets the requester cancel their own request.
Approving and rejecting need publish rights on workflows, which is the Admin level (see Permissions and Access Control); workspace owners and admins have it by default. By default you cannot approve your own request, so every gated promotion needs a second person.
The promotion policy
Promotion policy (workspace) applies to every workflow in the workspace. Only members with publish rights can change it.
| Setting | Default | What it does |
|---|---|---|
| Production promotions need approval | On | Promotions to Production wait for an approver. |
| Staging promotions need approval | Off | Promotions to Staging wait for an approver. |
| Requesters may approve their own promotions | Off | When off, the approver must be someone other than the requester. |
| Change Production only through promotions | Off | When on, Activate in the builder and the Versions panel is refused, so the Active version changes only through an approved promotion. |
Turn on Change Production only through promotions when you want every production change to have a requester, an approver and a record.
Promotion history
Promotion history lists every request for the workflow, newest first, with its status (Applied, Approved, Pending, Rejected or Withdrawn), the people involved, their notes and when it happened. Promotions and policy changes are also written to the workspace activity log.
Keep workflows in Git
Git in the builder toolbar opens the Git sync panel, which links the workspace to a GitHub repository, so versions are also kept as files in your repository.
- Create a GitHub connection under Credentials with access to the repository's contents (the
reposcope). - In the Git sync panel, choose Link repository, pick the connection and enter the repository as
owner/name, the branch and, optionally, a folder. Linking checks that the connection can read the branch. The link applies to every workflow in the workspace, and only members with publish rights can change it. - Choose when FluidGrids commits: Commit when a version is published, Commit when a promotion applies, or both. Push commits the version on the canvas at any time.
Each workflow is stored as <folder>/<workflow key>.json in the workflow export format. The panel shows every push (Pushed, Up to date or Failed) and the file's Git history. For any commit you can Compare with the version on the canvas, or Restore as draft: the file at that commit becomes a new draft version, and nothing is activated. A failed push never undoes the publish or promotion that caused it.
Unlink stops all commits for the workspace; commits already in the repository stay there.