You can ask for this instead. Ask Command Center "what is waiting on me?" or "why is this release blocked?". It shows every open gate: what is being decided, the risk, which checks are green and red, and what your CI said about exactly that commit. You can approve, reject or send work back from there too. That is the same recorded decision as on screen, and it requires a session with two-factor authentication.
What an approval is
A gate is a moment at which work stops until a decision has been recorded. With every decision FixControl records who decided, in which role, through which channel, on which evidence and under which policy version.
Not every step needs a person. This page says, per step, what the default is and what your organization can change.
The decisions
| Decision | When | By default |
|---|---|---|
| AI plan | Before the AI starts on risky work. | Requested for priority critical or a risk flag: payments, sign-in, security, migrations, data loss, personal data, infrastructure. Your policy can set this to always or never. |
| Code change (patch) | After the AI has made a change and the sandbox has tested it. | A person decides when the work has a risk flag, when the CTO Review agent objects, or when it was not proven that the application still starts. For other work the CTO Review agent may approve, only after a passing test of exactly that version. |
| Reply to a customer | Before a reply goes out. | A colleague sends it; the AI only makes a suggestion. Approval beforehand can be configured. See Replies to customers. |
| Opening a pull request | After the patch is approved. | A colleague opens it. Auto-deliver can be set per project. See Delivering changes. |
| Deployment | Where a deployment gate is set up. | Off. Where set up, an approval releases a paused rollout or pipeline; a rejection holds it. |
| Retry | When a required step of a mission fails. | Always a person. |
| UI change | When the check on screen changes is uncertain. | Always a person. |
| Development review | For development work that the project's policy says needs a second person. | Always someone other than who started the work. |
| Infrastructure action | A proposed restart of one workload. | Off. Where set up, the restart only happens after approval. |
Commit and merge approvals exist too, but they are off by default and set up for your workspace by FixControl. FixControl never merges by itself.
Where you find approvals
- Approvals (
/approvals) — everything waiting on a decision: open gates and customer replies. You reach it through the amber … waiting on you notice at the bottom of the sidebar. You open a gate with Open to decide; a customer reply is reviewed on the page itself. - On the issue or mission page — as a card next to the work.
- Notifications — in-app, for the people who may decide and for whoever started the work.
- E-mail — where your organization has an approval route with the Email channel, with single-use links (see below).
- Slack and Microsoft Teams — where a channel with the purpose Approval requests is connected to the project (see below).
Who may decide
By default, one active admin or manager of your organization decides a gate. Operators can read along, but not decide. The roles in an approval route (such as CTO, QA or Release Manager) are then only a suggestion of who should look; the card says so.
Staged approvals are off by default. An admin switches them on in the governance console (Settings → AI & approvals, tab Approvals, card How approval rules are applied: Enforce staged approvals). A gate with stages is then decided stage by stage, by whoever holds that role, one stage per person, each with its own deadline. A no from anyone allowed to decide rejects the whole gate.
If your organization uses project permissions, you also need a role in the project that allows the decision.
If nobody can decide — no active admin or manager — the gate keeps waiting and FixControl reports that.
Reviewing a plan
A plan appears as a card headed Awaiting plan approval. It contains the problem interpretation, the approach, the systems and files affected, the risk with its reasons, the validation strategy, the rollback plan, the customer impact, estimated time and cost, and open questions. Fields without a value show Not available; FixControl does not invent a value.
- Read the plan.
- Choose Approve plan, Request changes or Reject plan.
- With Request changes an explanation is required. The AI produces a new version (Plan v2, v3…) with your feedback folded in.
A new version invalidates an earlier approval: you always approve the version in front of you. Until the plan is approved, the card says Implementation is blocked by governance policy until this plan is approved.
Reviewing a code change
The patch is on the issue or work-session page and under Patches. You see the files, the diff, the confidence, the risk, what changed, and the test result. Confidence is not safety: read the risk too.
- Approve — the patch is accepted. Delivering it as a pull request is a next step.
- Reject — the patch is dropped.
- Request changes — in the work session: the agent produces a new version.
If the CTO Review agent asked for changes, you choose between Approve & revise (the agent produces a revised version) and rejecting.
Two rules worth knowing:
- A green test is needed. On projects with a validation profile, FixControl refuses an approval while the test of this version is not green. If the test status is temporarily unreadable, the approval is refused as well; try again shortly. Rejecting and requesting changes always work.
- The CTO Review agent's approval waits for the test. When the agent approves a patch, that only counts once the sandbox run for exactly that version has passed. If the run fails, times out, belongs to an older version, or did not prove that the application starts, the patch waits for a person and the panel says why.
The Patches page
Patches sorts patches into the tabs Pending (only the newest version per work session), Approved, Applied, Rejected, Archive and All. Archive takes a patch off the queues without a verdict; nothing is deleted. A patch that an open approval is still waiting on cannot be archived: reject it instead, so that approval is settled.
Deciding by e-mail
Where your organization has set up an approval route with the Email channel, deciders receive an e-mail with the issue, the risk, a verification summary and the buttons Approve, Reject and Open details. Each button is a single-use, expiring link tied to you as a user. When you click, FixControl checks again that you are still active, still a member and still allowed to decide. Requesting changes is only possible in the app.
Deciding in Slack or Teams
- Your chat account must be linked to your FixControl account (with
/fix link) and elevated by an admin. A linked but not elevated account can read along, not decide. - Your role in this workspace must allow the decision, at the moment you click.
- A button that opens a link asks you to be signed in to FixControl. The link itself does not prove who you are.
- Microsoft Teams does not support everything Slack does, such as the evidence window. Where Teams cannot show something, the card points to FixControl.
When nobody responds in time
By default a gate waits until someone decides. Your organization can set a time limit with an action: keep waiting, escalate, auto-reject or notify a fallback decider. Those limits are only applied automatically when an admin switches that on: Apply approval timeouts and escalations automatically on the same card. See Governance & policy.
FAQ
I can see the plan, but no buttons. Your role may not decide this gate, or another stage is up. The card says who can.
Does my approval still count if the plan changes afterwards? No. A new version needs a new approval.
Does an approved patch land in my codebase automatically? Not by default: after approval you open the pull request yourself. With auto-deliver, FixControl opens it straight away. Merging is always yours. See Delivering changes.
What is the difference between rejecting a plan and rejecting a patch? Rejecting a plan stops the work before there is code. Rejecting a patch discards a change that has already been made.
See also: Verification and results · Delivering changes · Governance & policy