BranchFlow

For dispatchers and maintenance leads

A request is not yet a job. Keep the two apart.

Branches ask for things constantly. BranchFlow holds requests separately, lets an authorised person approve or decline with a reason, and turns approved requests into work that carries the original detail.

What we can state plainly

Each line here is something the running system does today, not an ambition.

  • Requests, approved work and corrective actions are distinct record types.
  • Approval and decline decisions are recorded with a reason and an actor.
  • Templates prefill steps, priority and required evidence so jobs are consistent.
  • Work can depend on other work, so sequence is visible rather than assumed.

How it works in practice

  1. 1

    Request raised

    A branch asks for repair, supplies or a vendor visit.

  2. 2

    Reviewed

    An authorised person approves or declines with a reason.

  3. 3

    Work created

    A template turns the request into work with steps and evidence rules.

  4. 4

    Tracked to closure

    The request stays linked to the work created from it.

What you get

  • Ten record types

    Issues, requests, corrective actions, inspections findings, planned work and more.

  • Templates

    Reusable work definitions for common jobs across the estate.

  • Dependencies

    Mark work that cannot start before another job finishes.

  • Idempotent conversion

    A request converts once; repeat clicks do not create duplicates.

The screens behind this page

Every entry names a real screen in the application and its state today.

  • /workAvailable today

    Branch requests with approval, decline and template-based work creation

    Available today: requests are reviewed before any work is created.

    Data shown: Sample requests awaiting a decision

  • /queueAvailable today

    Shared queue with priority, owner and response clock

    Available today: one queue with owners and response clocks.

    Data shown: Sample work queue

  • /verifyAvailable today

    Independent verification before closure

    Available today: closure requires a second person.

    Data shown: Sample verification decision

What's included

What you get on day one, and what we connect to your own systems during onboarding.

Included

  • Request intake, approval and decline
  • Template-based work creation
  • Dependencies and record types

Connected during setup

  • Approval limits tied to your own finance rules need your thresholds

Common questions

Who can approve a request?
Only roles you authorise. The decision and the reason are stored against the request.
Can we set spending limits?
Yes. Approval limits are configured per organisation and checked before work or purchase proceeds.

How access and records are handled

Each organisation's records are separated in the database, and people only see the branches they are assigned to. Status changes, approvals, rejections and verifications are recorded with who did them and when. We do not claim any external certification or audit at this stage; if you need a formal security review, ask us and we will tell you exactly what exists today.

Walk this part of the system yourself.

The demonstration workspace is loaded with clearly labelled sample branches and records, so you can test this workflow end to end before deciding anything.