A Task or Approval step assigns work to a person or a role. You'll run into these both on a deal's Automators tab and on My Tasks — the same task either way.
Plain tasks
If a task is assigned to a specific role rather than a person, and nobody holds it yet, anyone who matches that role sees Claim — whoever claims it first gets it. Once it's assigned to you, select Mark done to complete it. A team admin who isn't the assignee sees Complete on behalf of that person instead, with a confirmation first — this is recorded in the deal's activity log. Anyone else just sees who it's waiting on.
If the task is linked to a checklist item, marking it done also checks that item off on the deal's Checklist tab, dated today and credited to the automator — see The deal checklist. If the run is paused (by hand or because the deal is on hold) or needs attention when you mark the task done, the item is checked off once the run picks back up instead. A run that needed attention before it was paused still needs attention after you resume it — the item is checked off once that's sorted out.
If the item can't be checked off (or another action on the step can't run) when you mark a task done after the run has already moved past it — a task from a Recurring step, for example — the run keeps going and the deal's (or contact's) Activity shows a note saying which action didn't run, so you can do it by hand if it still needs doing.
Approvals
An Approval step asks one person to sign off before the run moves on: whoever holds the Approver role picked for the step in the builder. When the run reaches the step it goes straight to that person, showing Awaiting approval with Approve and Reject — there's nothing to mark done first. They get one notification asking for their approval. Everyone else sees who it's waiting on. If more than one person on the deal holds the Approver role, the approval goes to the one added to the deal first.
Approve moves the run on to the next step.
Reject requires a note explaining why. On an ordinary approval, the approval reopens with your note as a banner ("Rejected by [name]: [your note]") and an Attempt N badge if it's been rejected more than once. When it's ready for another look, select Mark done, then Approve.
Some approvals — a few in the starter library — use two people instead: one person does the work and selects Mark done, the approval shows Done — awaiting verification, and a separate verifier then sees Approve and Reject. On those, a rejection goes back to the person who did the work, who is notified with the note — every time, so a second rejection brings a fresh unread notification even if they already read the first — and the cycle repeats until the verifier approves. A checklist item linked to an approval is checked off only when it's approved — never when the work is marked done for review or rejected.
Some approvals are set up to send rejected work back to an earlier step instead — say, back to a pricing form. The Reject box tells the approver where the work will go ("This sends the work back to "Pricing form"…") and how many times it can go back. The person who gets it sees a banner on that step — "Sent back by [name]: [note]" with a Round 2 of 3 badge — and the deal's timeline lists each pass over the steps as its own entry — the first pass plain, then Round 1, Round 2 and so on, matching the badge. The same banner shows on the person's row in My Tasks. When they finish, the steps after it run again and the approval comes back to the approver. Once the approval has been sent back as many times as its limit allows, the next rejection goes to the same person instead and the run is flagged — see Needs attention on a run.
If the person set to verify an approval has left the team, admins see a banner explaining that, with a Reassign verifier button to pick someone else to take it over.
Tasks that require a document
Some task steps ask for a specific file — an A→B, B→C, or A→C (retail) contract, an addendum, an EMD receipt, a buyer's proof of funds, or photos — before the step can be considered done. On these, the task row shows Waiting for: [document kind] upload with an Upload button. Clicking it opens the same upload dialog as the deal's Documents tab, with the kind already picked for you.
Uploading a matching document completes the task automatically — you don't also need to click Mark done. If you upload the wrong kind by mistake, the file still gets attached to the deal, but the task stays open; you can still finish it manually with Mark done either way — the upload is a convenience, never a requirement that blocks completion.
A task that asks for Photos completes on the first photo you upload. Keep uploading the rest of the set as usual — the extra photos attach to the deal and don't change the task.
The Upload photos step in the Property Access, Photos & Deal Packet library automator works this way. Copies installed before this change still have an Upload photos step you finish by hand. To switch yours over, open it in the builder, make Upload photos a Task, and set Require file upload to Photos. (A copy that has never run can also be removed and installed again to get the new version.)
When you build an automator, pick the file a task waits for under Require file upload in the task step's settings. This works on a Task (including one with Requires verification), not on an Approval step: an Approval goes straight to its approver, who could approve before the file arrives, so the builder doesn't offer it there and publishing stops if one is set. If an automator published before this rule pairs a file with an Approval, the run shows This approval's file upload requirement isn't enforced while that approval is open — the setting does nothing there, so check the file is on the deal before you approve. On a Task, a matching upload completes the step automatically and the verifier sees the file afterward; it never blocks anyone from marking the task done.
Approvals and your plan
Approvals require the Pro plan. If your organization is on a plan without approvals, claiming an unclaimed approval-kind task and reassigning a verifier both show a message asking you to upgrade. This never affects an approval that's already assigned — marking it done, approving, and rejecting all keep working normally even if your organization changes plans partway through a run.
Common issues
- No Approve/Reject buttons showing — you're not the approver; only they can approve or reject. Check that the right person holds the step's Approver role on the deal's Employee tab.
- "No verifier is staffed to approve this step" — nobody on the deal can approve yet. When the approver is picked as a role or a seat, select Assign someone (or Assign TC when it's a deal seat), add the person, and the approval goes to them by itself. If the banner's main button is Retry now instead — a named teammate who has left the team, or a deal or run owner — select Retry now once the approver is in place. And if the right person is already on the deal but the run is still waiting, select Retry now (the second button on that banner). See Needs attention on a run.
- The "Nudge" button on a task you're waiting on someone else to finish sends them a real notification (their bell shows Waiting on You, and it links straight back to this step). It's limited to one nudge per run per hour — if you nudge again too soon, you'll see a message saying so.