Who decides whether a job needs photos?

A photo requirement is rarely a whole-business rule. One client wants proof on every visit; one contractor needs closer supervision; one job is a five-minute favour. Biloh resolves the requirement per job through four levels — job, series, client and contractor, then your tenant default — and where a client and a contractor disagree, the stricter rule wins.

Requiring a photo when a job is completed sounds like one switch. In practice it is at least four different conversations: a client who wants photographic proof of every visit; a contractor you want closer evidence from while they settle in; a recurring service where the photo is the deliverable; and the one-off job where insisting on paperwork is friction for no return.

So the requirement is not a single setting. Biloh resolves it per job, at the moment of completion, from four levels:

  1. The job — an explicit requirement on this one visit wins outright.
  2. The recurring series — the contract service line the job was spawned from.
  3. The client and the contractor — both can carry a rule; where they differ, the stricter applies.
  4. Your tenant default — what happens when nothing more specific is set.

The default default is deliberately permissive: completion is one tap, no photo and no note. Field speed is the point — a requirement is something you add where the evidence is worth the taps.

Why the strictest rule wins rather than the most specific

Levels 1 and 2 are overrides: the more specific statement replaces the general one, which is what you expect from any settings cascade. Level 3 is different, because a client and a contractor are not in a hierarchy — they are two parties to the same visit, and each may have been promised something.

Consider a client whose agreement says every visit is photographed, and a contractor with no photo rule. If "most specific wins" were applied naively, whichever level the system happened to read last would decide, and a contractor-level record with no requirement could quietly cancel a commitment made to the client. That is a compliance failure disguised as a configuration nicety.

So at that level the rules merge, strictest-first:

  • require photos — true if either party requires them.
  • minimum photo count — the higher of the two.
  • require notes — true if either requires them.

The plain-English rule: one party relaxing a requirement can never cancel another party's requirement. Only an explicit decision at a more specific level — this series, or this job — can do that, and both of those are deliberate acts with an audit trail.

One enforcement point, so every route agrees

A resolution rule is only as good as the number of places that honour it. Completion can be recorded from several directions: a contractor tapping Mark complete in the portal, an operator recording a completion on their behalf from the office, or an AI assistant completing a job by chat over MCP.

All of them funnel through one completion write path, and the requirement is enforced there — not in the portal's form validation. That is what makes the guarantee real: there is no route that skips the rule, because there is no second implementation of completion. A short attempt returns a clear failure naming what is missing ("2 photos required, 1 attached") rather than a silent pass. See one write path, many callers for the general pattern.

Because the resolved requirement is computed server-side, the surfaces can also show it before anyone tries: the portal renders the exact number of photo slots the job needs and keeps the submit button disabled until they are filled, so a contractor in the field learns the rule at the start of the task instead of at the end.

Setting it

Any of the four levels is editable from the app or by asking an assistant in chat — "require a photo on completion for that client," "drop the photo requirement on tomorrow's job at the depot" — and both routes reach the same resolution logic. The in-product help centre carries the step-by-step for each level.

What this is an example of

The cascade is one instance of a platform-wide rule: behaviour that varies between businesses is configuration, not code. A requirement model with four levels and a merge rule costs more to build than a single boolean, and it is the difference between a product that fits one operator's habits and one that fits an industry's contracts.

Related

Last updated 2026-07-30