Skip to Content
Product DocsInspection AppManager Requests

Manager Requests

Half-finished information is the most expensive thing in a renovation quote. A reviewer opens a completed review, finds the tech photographed the deck but never measured it, and now needs one number that only somebody standing at the pool can get. Before this loop existed that request went out as a text message, and the answer came back as a text message — so the photo landed in someone’s camera roll instead of the job record, and nothing on the review said it was waiting. This loop exists to solve that problem.

A Manager Request makes that ask a tracked object on the review. A reviewer names one or more people, says what is needed, and any of them can answer. The answer carries a required note and any photos taken, and those photos file into the account’s Job Documentation with the request recorded as their source. The reviewer accepts the answer to close it out.

Manager Requests are part of the review → proposal workflow and are limited to pilot divisions while it is evaluated. As with the rest of that workflow, availability follows the review’s division, not yours.

The lifecycle

The loop is strictly forward-only. A request never moves backwards: if an answer is inadequate, you do not reopen it — you raise a new request that supersedes the old one, which keeps the original ask and its answer readable forever instead of overwriting them.

Who may do what

The floors widen and narrow deliberately at each step.

ActionWho
Raise a requestAny Level 2+ — the same floor that reviews the work
Answer itAny current assignee, at any level, including Level 1; or a Level 5 recording a phoned-in answer
Reassign itThe raiser or any current assignee, while it is still open
Accept the answerThe raiser (whatever their level), an in-division Level 4+, or any Level 5
Cancel itOnly the raiser or a Level 5
Read itAny assignee or the raiser at any status, plus in-division Level 4+ and any Level 5

Two of these are worth dwelling on:

Accepting is wider than raising. If only the raiser could accept, one person’s absence — PTO, sick day, role change — would freeze every pool behind a request nobody else could close. An in-division Level 4+ manager can always close one out.

Cancelling is narrower than accepting. A Level 4 division manager can accept an answer but cannot cancel someone else’s request out from under them. Withdrawing an ask belongs to the person who made it.

Reassigning is how work is handed off. An assignee removes themselves and adds someone else — that is the mechanism, not a separate “forward” action. It is also how extra people get added to an ask.

A Level 1 field tech can answer a request without Job Documentation access, and the photos they take still file into the account’s Job Documentation. That is deliberate: the person standing at the pool is often the one with the fewest permissions, and requiring an access level to answer would defeat the whole loop.

Answering from the field

The assignee’s screen at /requests/[id] shows the ask, an offline-capable camera, and a required response note.

/requests            ── the inbox
  ├── Assigned to me      requests I hold that nobody has answered
  └── Waiting on me       requests I raised that have come back answered

/requests/[id]       ── the answer screen
  ├── what was asked
  ├── photo capture     (queues offline, uploads on reconnect)
  ├── response note     (required — Submit stays disabled without it)
  └── Submit ──> the raiser is emailed

The header carries a count badge whenever you have either kind of open work, and the home screen shows a matching card, so a request does not depend on anyone remembering to check a page.

Photo capture is not lifecycle-gated. Photos taken against a request file successfully even after it has been answered, accepted, or cancelled. This is deliberate: a tech who shot photos in a dead zone and reconnects an hour later gets their work filed instead of a permanent error their offline queue would retry forever. The photos land in Job Documentation regardless of what happened to the request meanwhile.

Where requests show up

An outstanding request is visible without opening anything:

  • A Request outstanding chip on the Renovation Reviews queue and on account rows, with a matching filter.
  • A warning in the Sent to Customer dialog when the field is still working. It warns; it never blocks.
  • The header badge and home-screen card, refreshed on each navigation.

The chip counts both open and answered-but-not-accepted requests, because an answer nobody has accepted is still live work on that review. The Sent-to-Customer warning counts open only — an answered request is back with the manager, so naming it there would tell them to wait on themselves.

An inspection with an outstanding request cannot be deleted by a Level 4. It escalates to Level 5 only. That escalation is deliberately not gated by the division switch — an outstanding request is live field work regardless of the flag — but the Cancel action is gated. Cancel every outstanding request on a division before switching that division off, or those inspections become permanently undeletable by anyone below Level 5, with no in-app way to clear the blocking rows.

The outstanding chip is also ungated, on purpose: it is the only ambient signal explaining why such an inspection suddenly cannot be deleted.

Pitfalls

  • Do not try to reopen a request whose answer was inadequate. Raise a follow-up instead; the loop is forward-only.
  • Do not assume a request is closed because someone answered. Submitted is not accepted — the review still shows an outstanding chip until it is accepted.
  • Do not switch a division off with requests outstanding. Cancel them first (see the warning above).
  • Do not expect an assignee to lose access after answering. Reading has no status check by design, so people can always see their own answered or cancelled requests.
  • Do not read a Sent-to-Customer warning as a block. It is advisory, and it counts only unanswered requests.
Last updated on
Review → Proposal PipelineReview Mode