Approving as a Client
What an approval that names you looks like, how to approve, request changes or reject it with a reason, what your verdict does, and what the team sees afterwards.
By the end of this page you will know how an approval reaches you, how to answer it, what each answer does to the record, and how to read what others decided.
How an approval reaches you
A project's policy for a kind of approval can name stakeholder seats. When your seat is named and has your account linked to it, every record the team submits for that kind appears in your Approvals, and you are told through your notification destinations with a button straight to it. A seat without an account is listed on the team's side for the record and cannot decide; ask the team to link your account if you were invited after the seat was created.
Read the request
Open Approvals in the sidebar. Waiting on me lists what still waits for your answer: the record's reference and title, the project, who submitted it and when, how many approvals are in and how many the policy needs, and when the team expects an answer. Open a row for the flyout: the team's summary of what changed and why, the approvers named beside you with what each has said so far, and Open followed by the record's reference to read the requirement, rule or use case itself once it is visible to you.
Give your verdict
Three buttons sit on the approval bar:
| Button | What it does |
|---|---|
| Approve | Your approval is counted. The record is approved once the policy's rule is met: one approver, every approver, or a quorum. |
| Request changes | The request is held for the team to edit the record and resubmit it; you decide again on the next round. |
| Reject | The request is closed and the record returns to where it stood before it was submitted. |
Each opens a short confirmation with a Reason. The reason is required for a rejection or a request for changes on most projects, and the team reads it beside your name. You decide once per round; a resubmission after changes opens a new round and asks you again.
Your verdict is signed
Every verdict is written once with the time, the address and the browser it came from, behind a signature hash. The team can export who approved what and when; nothing you decided can be edited afterwards, by you or by them.
Afterwards
- Approved records appear in your project view from the moment they are approved, at the version you read.
- Raised by me stays empty for a guest; guests do not submit.
- A request the team withdraws leaves your queue without a word; a request that runs past its time is escalated to the team's lead, not to you.
- Your decisions stay listed on the request for everyone who can read it.
Related
- For clients — the guest's view of a project
- Approvals — the same engine from the team's side
- Signing off the scope — the scope baseline that comes to you for signature, and the change requests you raise
- Notifications — where the approvals alert class reaches you
How is this guide?
Last updated on
For Clients
The guest's view of a project: the approved record, the approvals assigned to you, and what stays on the team's side of the line.
Signing Off the Scope
What a frozen baseline is, how the sign-off reaches you and what your signature means, what a change request is and how to raise one, and what you read of each afterwards.