Software Release Management Workflow

What happens if the readiness review finds gaps?

The release status is set to Returned and the requester gets a Fix Gaps task asking them to address the gaps and upload updated test evidence. Once that evidence is saved to the record, the workflow restarts from the readiness review status update so the release is re-checked. This loop can repeat as many times as needed until the readiness result comes back as Ready.

What if the release manager rejects the release?

The record's status is set to Rejected and the requester receives an email letting them know the release was not approved. The rejection outcome and any details entered during the approval step are kept on the record's timeline, so there is a clear history of the decision.

Can this handle a deployment that fails validation?

Yes. When the Deploy and Validate task records a Validation Result of Failed, the workflow routes into a Rollback task for engineering, which captures the Rollback Date and Rollback Cause on the record. The status is set to Rolled Back and both the requester and the stakeholder distribution list are emailed with the cause.

What happens after a rollback is completed?

Alongside the rollback notifications, the workflow creates a fire-and-forget Fix Issue and Resubmit task for the requester. This task isn't waited on, so it doesn't block the record; the Rollback Cause Reference entered on that task stays with the task itself rather than being saved to the release record.

Who is responsible for each step in this workflow?

A reviewer completes the Readiness Review task, a release manager handles the approval decision, and engineering completes both the Deploy and Validate task and, if needed, the Rollback task. The requester is only involved through the Fix Gaps task and the fire-and-forget resubmission task, both delivered as emailed tasks without needing a login.

What if the readiness result or approval outcome doesn't match Ready, Not ready, approved, or rejected?

Both routing points include an 'otherwise' branch, so the release can still move forward even if the value entered doesn't match one of the expected outcomes. This keeps the record from getting stuck at a decision point while still logging what was entered in the record's timeline.

Who gets notified when a release goes live?

The requester and the stakeholder distribution list both receive a live notification email, and a separate message is sent specifically to the stakeholder distribution list. Both emails go out automatically once the Deploy and Validate task records a Successful validation result and the status is set to Live.

Can we customise this workflow for our own release process?

Yes, a workspace can adjust the workflow by describing the change in plain English or editing the steps directly in the workflow editor, and earlier versions are kept. This makes it straightforward to add stages, change routing conditions, or adjust which fields the readiness, approval, or deployment tasks capture.

Does the requester need an account to submit or respond to tasks?

No. The requester submits the initial release request through a public request form, and later interacts through forms emailed to them, such as the Fix Gaps task. No login is required at any point in the process.

What does the record show if we need to review how a release was handled?

Each release is a record with a reference number, a current status, and a timeline showing what happened at each step, including readiness results, approval outcomes, deployment and rollback details. Table views and dashboards can show releases grouped by status, and each business should confirm what level of record-keeping meets its own requirements.