Client sign-off

An agency's client does not have a Tempio login and does not want one. Client sign-off is how they sign a change off anyway: the workspace sends them a link, the link opens one page showing exactly what is about to change, and they approve or decline it there.

It is not a second gate. A sign-off satisfies one stage of an approval chain — the stage whose approver is "the client, by email" — so a client's approval runs through the same machinery a member's does. Same plan, same record, same apply.

Client sign-off is on the Scale plan and above.

Asking for a signature

A change waiting at a client stage carries a Request sign-off button on its own page. Its row in the queue says it is waiting on the client and opens that page. The button opens one field: the address to send the link to.

• When a chain is holding the change, the stage already names the addresses. The first is filled in, the rest are one click, and an address the stage does not name is refused — the chain is the workspace's rule about who signs, and this form is not a second place to widen it.
• When no chain is holding the change, a workspace owner can still ask a client to sign it. Doing so adds a one-stage client plan to the change, so from that moment it is held exactly like a chained one: it waits until the client answers.

Owners and admins can request a sign-off on a chained change. The ad-hoc request is owner only, because it does not just send an email — it decides that this change now needs a signature.

A client is asked about a change group whole: a batch is one review and one signature, the way it is one apply. Asking for sign-off on part of a batch is refused.

Only one link is out at a time per address. While a request is unanswered the page’s details say where it went and when it expires, and Resend and Revoke stand where the button was, because two links to one person are two ways to spend the same signature. A stage that names several clients and asks for several signatures can have one link out to each.

What the client is sent

One email, to one address. It says:

• whose workspace is asking;
• what the change is — "5 changes, one review", or the operation's own name;
• how many changes the link covers and what they move, in the ad account's own currency;
• the day and time the link stops working, stamped UTC;
• the link.

It carries no diff — the changes are read live on the page, not frozen into a message that might be opened a week later — and the link appears in the button and nowhere else. Not in the subject line, which is logged by every relay it passes and quoted into every reply, and not in an unsubscribe header: this is a request addressed to one named person, not a list, so there is nothing to unsubscribe from.

What the client sees

The link opens a page with no sign-in, no workspace picker and none of the hub's furniture. On it:

• the workspace's name and what is being signed;
• which stage of the chain this is, so they know whether anyone else has yet to sign;
• every change, before and after, in the ad account's currency;
• a field for their name, so the record says who signed;
• Approve and Decline.

Approving applies the changes if it was the last signature the chain wanted, and records the signature and waits if it was not. Declining ends the chain: the change is rejected, and the workspace has to draft it again. Either way the record names the address that answered.

The page is not indexed and the link is not listed anywhere.

What the link cannot do

A sign-off link is a credential for one decision on one change, and that is the whole of its reach:

• it reads and answers one change group and nothing else in the workspace — not the account, not the metrics, not another draft;
• it can be answered once. A second attempt says the sign-off has already been answered;
• it expires after seven days. An expired link says so and does nothing;
• it is never stored. Tempio holds a SHA-256 hash of the token, so reading the database approves nothing;
• it is rate-limited, per link and per address it arrives from, so a link that leaks cannot be hammered.

What the record says

Requesting a sign-off, approving one and declining one are each a line in the audit log, with the address and the stage. The signature itself is a decision row against the change, recorded as a client decision and pointing at the request that carried it — so the Approval section on the change’s page names the address that answered beside every other signature.

change_request.reviewedBy is null on a change a client cleared, and that is the correct record rather than a gap: the column is a foreign key to a user, and a client holds no seat for it to point at. approverKind carries the meaning instead — it reads client, and the decision row beside it names the request, the stage and the address.

An agent reading list_drafts sees that a change is waiting on a client, which address it went to and when the link expires. It never sees the link. There is no tool that asks for a sign-off, and there is no tool that answers one.

See Approvals for the chains a client stage belongs to, and Drafts for the lifecycle every approved change goes through afterwards.