A structured RFC workflow for every production change: the right approvers, a risk assessment, a rollback plan written in advance, a maintenance window, and a review afterwards. All of it linked to the tasks and tickets behind the change.
One-week free trial of the Business plan. No card needed.
What you get
Heavy process gets ignored. Decuga keeps the record complete and the steps short: required fields where they matter, templates for repeat work, and approvals that go to the right people.
Standard for routine, pre-approved work. Normal for planned changes that need sign-off. Emergency for urgent fixes, with a single approver and a full review afterwards.
Rate each change Low, Medium, High or Critical, and record the systems and services it touches and who is affected if it goes wrong.
A description, an execution plan and a rollback plan are required to create a change, so nothing reaches approval without them. They are written in the same rich text editor as a task description.
Require as many approvals as the change deserves, and optionally approvals from Change Managers too. Each decision is recorded with a timestamp, and a rejection needs a reason.
Schedule when a change may happen with a start and an end in your time zone, and see what is planned across the project.
Connect the change to the sprint tasks that make it and the support tickets that caused it, so the trail is complete in both directions.
Start from five built-in templates (Emergency Hotfix, Database Maintenance, Infrastructure Scaling, Security Patch, Feature Flag Toggle) or save your own. Everything is editable.
After a change is completed or rolled back, record whether it succeeded, what you learned and whether the system is back to normal. Reviews are kept on the change permanently.
When a change is rolled back, Decuga records why, who did it, when, how long it took and whether the system is confirmed back to normal. A completed change that needs undoing gets a linked emergency change.
Every edit, status change, approver and decision is listed with who did it and when. Discussion continues in comments, even after the change is closed.
Approvers and the author are told when a change is submitted, approved, rejected, completed, failed or rolled back, in the app and in a Slack channel you choose.
A CI/CD pipeline with a project API key can report a deployment’s outcome. The Decuga assistant, in the app, Slack or an AI client, can create changes and move them through approval.
Change types
The type of a change decides how it is approved, not the other way round. Most teams run mostly Standard and Normal changes, and keep Emergency for real incidents.
| Type | What it is | Examples | Approval |
|---|---|---|---|
| Standard | Pre-approved, repeatable, low risk. Pre-authorised by policy, so no approval cycle. | A routine configuration change to a known-stable path; a scheduled dependency version bump. | None: it is recorded and carried out |
| Normal | A planned change that needs a full assessment before it goes ahead. | A third-party integration change; a schema migration; a new service in production. | The required number of approvers, plus Change Managers if you turn them on |
| Emergency | An expedited fix for a production incident. Implement first, document and review after. | A production hotfix during an active incident; rolling back a bad release; data corruption remediation. | One approver is enough to begin; the full review compensates |
The workflow
A change moves along a defined path, and the rules are the same whether you change the status in the app or through the API.
Prepare the change. Edit freely, link the tasks and tickets, and start from a template if one fits.
Submit for approval. The required approvers are asked, and each decides for themselves. The author cannot approve their own change.
It is approved as soon as the required number agree. A rejection needs a comment, and the change can go back to Draft to be revised.
Carry the change out in the scheduled window. The start time is recorded.
Record the outcome. A failed change can be rolled back using the documented plan, with the reason and timings recorded.
A post-implementation review captures what happened and what to do differently, and stays on the record.
Editing resets approval. If you change the details of a change that is waiting or approved, it goes back to Draft and the approvals are cleared, so nobody approves something that was altered afterwards.
Completed changes are locked. The details become read-only once a change is in progress. If a completed change must be undone, you open a linked Emergency rollback change.
A person cannot approve their own change. Each approver decides only for themselves, and a rejection must say why.
Anatomy of a change request
These are the fields on a change request. The description, execution plan and rollback plan are required, and can be edited but never emptied.
| Field | What goes in it | Why it matters |
|---|---|---|
| Title and description | What is changing, why it is needed, and what it modifies in production. | Ties the change to a reason and a requirement |
| Change type | Standard, Normal or Emergency. | Decides the approval path |
| Risk level | Low, Medium, High or Critical. | Shows the approval effort matched the risk |
| Affected systems and services, blast radius | Which systems it touches and who is affected if it fails. | Lets approvers judge impact |
| Execution plan | The steps to carry the change out. | Shows it was planned, not improvised |
| Rollback plan | How to undo it, and how you will know it needs undoing. | The first thing reviewers check on a risky change |
| Scheduled window | When it may happen, with start and end. | Keeps changes out of sensitive hours |
| Linked tasks and tickets | The work and the incidents behind it. | Traceability from incident to deployment |
| Assignee | Who carries it out. | One accountable owner |
Approvals
Approval should scale with risk. Set the numbers once for the project and every change carries the number that applied when it was submitted.
Use cases
Any change that can hurt production, customers or an audit deserves a record. These are the situations where teams get the most from it.
Engineering and SRE teams
Every deployment that can break something is a change request: planned, approved by the right people, scheduled, and reviewed afterwards.
Database and platform teams
Schema migrations, index rebuilds and infrastructure scaling are high-consequence and easy to forget. Give each a window, a plan and an owner.
Incident response
In an incident you do not wait for a committee. An Emergency change needs one approver to start, and the review afterwards makes sure nothing is lost.
Teams under audit or regulation
Who approved what, when, with what risk assessment and what rollback plan: the record builds itself as the change moves along.
E-commerce and seasonal businesses
During a freeze, only approved changes and emergency fixes reach production, and each one is recorded for the review afterwards.
Agencies and consultancies
When you change a client’s system, a change request is your proof that the work was planned, agreed and reversible.
Part of one workspace
Because change management shares an account with project management and the service desk, the trail is never copied by hand.
Link the tasks that make the change, and see the change from the task.
Link the ticket that reported the incident, so support, engineering and approvers see the same thing.
Branches and pull requests link to tasks through GitHub and GitLab, and a pipeline can report the deployment outcome.
Ask the assistant to draft a change, check what is waiting for approval, or approve it, from the app, Slack or an AI client.
Plans
Change management is part of the Business plan, with the SLAs, company accounts and analytics of the service desk. The price is per account, not per approver, and every paid plan has a one-week free trial with no card.
From $57 / month, flat
Up to 50 team members, scaling to 500
$28 / month, flat
Up to 20 team members
Prices in US dollars, per month, before tax. See the pricing page for every plan and for larger team sizes.
Keep reading
Change management documentation
Every field, status, rule and setting in detail.
ITIL change management for software teams
How the ITIL ideas apply to a modern engineering team.
Change management for engineering teams
A lightweight process that people will follow.
Change control for healthcare software
Traceability from requirement to release, and what a tool can and cannot do.
Peak-season freeze and change calendar
Run a freeze with change requests, not a rule nobody can follow.
Service desk
The tickets and customer portal that feed your changes.
Start a one-week trial of the Business plan and run your next deployment through a change request.