Client Approval Workflow in Atarim
One button in the collaborate bar turns “looks good to me” into a dated, recorded sign-off your whole team can see.
Approval in Atarim is a status on a page rather than a separate approvals queue. Someone opens the page in the collaborate view, sets its status from the bottom bar, and that choice is recorded with a name and a timestamp. When the status reaches Approved, Atarim emails everyone set to be notified on the project.
The useful part is that clients get a deliberately simplified version of the same control. Where your team sees four statuses, clients and guests see plain-English choices — which is the difference between a client who signs off and a client who asks what “needs review” means.
The Four Page Statuses
Every page carries one status at a time. Three of them are working states; only the last one triggers anything.
| Status | Means | Visual cue |
|---|---|---|
| No Status | Nothing has been set yet. This is the starting state. | Plain control, no highlight. |
| In Progress | Work is underway on this page. | Orange border. |
| Needs Review | Ready for someone to look at. | Gold border. |
| Approved | Signed off. Sends the approval email. | Green fill. |
Where the Control Lives
The control sits in the bottom bar of the collaborate view, on the page it applies to. There is no central approvals screen — you approve a page while looking at it.
Instructions:
- Open the project you want to work in.
- Open the page in the collaborate view.
- Find the status control in the bottom bar. It is labelled Page Status before anything is set, and shows the current status once one is. Its tooltip reads Set the status for this page. Page approvals are a plan feature, so on plans without them a signed-in user gets an upgrade badge here instead of the control; guests are not affected. When you open a project from the Projects screen, the statuses are in the toolbar at the top of the page instead, behind an icon button that shows the current status.
What Your Client Sees
Clients and guests get a simplified version of the control, worded as plain statements rather than workflow jargon. This is the version to design your process around, because it is what the person actually approving will be looking at.
| What clients and guests see | What it sets |
|---|---|
| Click to approve (the default label) | Nothing yet. This is the prompt before a choice is made. |
| This page is approved | Sets the page to Approved and sends the approval email. |
| I’m done reviewing | Sets the page to Needs Review, signalling they have finished commenting. Guests who open a shared link see this option. Clients you invite don’t, by default. |
Once a client or guest has chosen, the button label reflects it, This page is approved or I’m done reviewing, rather than switching to the internal status name.
Setting Page Status as a Team Member
Logged-in team members see the full four-option list. Which statuses you can set depends on your role. This isn’t a setting in Workspace Permissions, so an Administrator can’t switch single statuses on or off for a role.
Instructions:
- Open the page in the collaborate view.
- Select the status control in the bottom bar. The dropdown lists the statuses your role is permitted to set.
- Choose a status. It saves immediately — there is no separate confirm step. The control’s label and colour update to match.
What Happens When a Page Is Approved
Approval is the only status that triggers anything, and it triggers several things at once.
| What happens | Detail |
|---|---|
| An email goes out | Subject: You have a new page approved on [project name], sent to everyone set to be notified on the project. |
| Additional recipients are copied | Any addresses in your workspace’s additional recipients setting are added as BCC. |
| The email names who approved it | It includes the approver’s name, the page name, the project, and a direct link back to the page. |
| Tasks on the page are listed | The email includes the tasks belonging to that page, so recipients can see what was outstanding. |
| An activity record is written | Recorded as Page [name] has been approved on [project]. |
| The approval is timestamped | The date and time are stored against the most recent task on the approved page. |
| White label is respected | Where white label is enabled for the project, the approval email follows it. |
Approving a Page Atarim Has Not Seen Before
Atarim tracks pages as it encounters them. If you set a status on a page with no existing record, it creates one at the same time — browse to the page in the collaborate view, set a status from the bottom bar, and the page is added to the project with the status you chose.
Design Status on Designs Projects
Designs projects carry the same control, applied to the design currently in view rather than to a web page. It is labelled Design Status there, with the tooltip Change status for the current design in view, and it writes the status to that design.
Benefits of a Recorded Approval
| Benefit | In practice |
|---|---|
| Sign-off has a date and a name | The approval record answers “who signed this off, and when” without searching an inbox. |
| Approval happens in context | The client approves while looking at the page, not from a description of it in an email. |
| The team hears immediately | Everyone notified on the project gets the approval email without anyone forwarding it. |
| Clients are not asked to learn a system | Plain options mean the approval step does not need explaining twice. |
| Progress is visible per page | Statuses let you see which pages are still moving and which are settled. |
Example Use Cases
| Situation | How to use the workflow |
|---|---|
| A staged site awaiting client sign-off | Set each page to Needs Review, share the link, and ask the client to use This page is approved. |
| A client who keeps reopening settled pages | Point at the approval record — it carries their name and the date. |
| A round of feedback rather than a sign-off | Ask guests for I’m done reviewing, which marks the page Needs Review without approving it. |
| A launch checklist across many pages | Work through pages, moving each from In Progress to Needs Review to Approved. |
| A stakeholder who needs a copy of every sign-off | Add their address to additional recipients so they are copied on approval emails. |
Known Limitations
- There is no central approvals screen. Status is set on the page, in the collaborate view.
- The control is hidden on mobile, for clients as well as for your team.
- Workflows cannot trigger on page approval. Automation triggers cover task status, not page status.
- Approving does not complete tasks on the page.
- Only Approved notifies anyone. Needs Review is silent, so asking for review still needs a message.
- Page matching is URL-based, so the same page reached by a different URL may be tracked separately.
- Approval emails are suppressed for some enterprise integrations, where the platform handles its own notifications.
FAQs
Does my client need an Atarim account to approve a page?
No. Clients you invite can approve without signing up, and so can guests who open a shared link. Guests are not subject to the plan gate on the control.
What is the difference between “I’m done reviewing” and “This page is approved”?
I’m done reviewing sets the page to Needs Review and signals the guest has finished commenting. This page is approved sets it to Approved and sends the approval email. Clients you invite see only This page is approved by default.
Who receives the approval email?
Everyone set to be notified on the project, plus any additional recipients configured for the workspace, who are added as BCC.
Can I approve a page on my phone?
No. The status control is hidden on small screens for everyone, clients included.
Does approving a page close its tasks?
No. Task statuses are unchanged. Complete them separately if you want them closed.
Can I un-approve a page?
You can set it back to another status from the same control, provided your role is permitted to set that status.
Can a workflow run when a page is approved?
Not currently. Automation triggers cover task events such as status changes, not page approval.
Will the approval email carry our branding?
Yes, where white label is enabled for the project. Verifying your workspace mailbox also means it sends from your own address.
Common issues
- The status control is not in the bottom bar — check you are on a desktop browser. The control is hidden on small screens.
- The control shows a plan badge instead of statuses — Page Approvals is not included on the current plan. The badge names the minimum plan needed.
- A status is missing from the dropdown — your role is not permitted to set it. This isn't a setting in Workspace Permissions, so ask an administrator about your role.
- The client sees only one option — that is the client view working as intended. Clients see This page is approved. Guests who open a shared link also get I’m done reviewing.
- No approval email arrived — confirm the page reached Approved rather than Needs Review, and that the recipients are set to be notified on the project.
- Tasks are still open after approval — expected. Approving a page does not change task statuses; complete them separately.
- The same page appears twice with different statuses — it was reached by two different URLs. Approve from the clean URL you shared with the client.
- A design sign-off did not notify the team — the approval email belongs to page approvals. Follow a design sign-off with a comment on the task.
Conclusion
The approval workflow is deliberately small: one control, four statuses, and one of them that notifies people. What makes it work in practice is the guest view — a client who is shown a plain choice approves far more readily than one asked to interpret a workflow.
Set the expectation before you send the link, tidy the task list before you ask, and the approval email becomes a genuine record of sign-off rather than another notification. Discover Best Practices For Client Communication
Tips & best practices
- Tell guests which of the two options you need before sending the link.
- Use Needs Review as your “ready for you” signal, and send a message alongside it — the status alone notifies nobody.
- Tidy task statuses before asking for sign-off, since the approval email lists them.
- Approve from the same clean URL you shared, so the status lands on the page the client saw.
- Add a stakeholder to additional recipients rather than forwarding every approval by hand.
- Remember to complete the page’s tasks after approval — nothing does it for you.