# Review decision

> Approve or send back for rework.

A review ends in one of two decisions. The decision panel sits under the list of findings (on a phone it is pinned to the bottom of the screen), and above the buttons it says **what will happen and why a button is unavailable** — before you press anything.

The first sentence names where the changes will be published: for example, “Approval opens a PR in GitLab · ats-system/quotes-service”. If the source repository is not connected, it says that the changes will be merged into the project’s repositories.

## Approve

Publishes the changes to the source repositories (PR/MR) and closes ours.

**Unavailable while there are open findings** — that is `pending` + `to fix`
(see the [status glossary](/en/docs/review/findings)). In that case the button looks disabled, and above it the reason is written: “Approve” is unavailable: 2 findings are open: send them for rework or dismiss them”.

Two ways out right from the “Approve” dialog:

- **Dismiss all** — if the findings are not needed: they go to the archive, and the approval continues.
- **Send for rework** — if something has to be redone because of them (see below).

## Changes requested

A subtask with the findings is created, our pull requests are closed, development restarts.
This is the rework loop.

- **There are “to fix” findings** — the rework follows them.
- **There are no findings yet** — simply **describe what to redo**: your comment is saved as
  a finding and goes into the rework. There is no need to add a finding separately beforehand.

<Callout type="info">
**“Approve” is unavailable — what now?** It means there are open findings. Either **dismiss**
the ones you do not need (in the finding itself — “Dismiss finding”, or in the “Approve” dialog → “Dismiss all”), or **send them for rework** — then they will be addressed. “To fix” means “will go into the rework”, not “done”.
</Callout>

_Illustration: The review decision — “Approve” or “Changes requested”, under the list of findings_