Skip to content

Custom Business Software

Workflow applications: the rules of the process live in the app

Some processes run on one coordinator's memory: which town wants a site plan, who signs what, what happens when an inspection fails. A workflow application writes those rules down as software. Each case gets the list of what it needs, each item an owner, and nothing moves until the step before it is really done. We write the rules down with the people who know them, then build them into software.
J-540 · furnace replacement · EastsidedraftingsubmittedEastside rules → 4 itemsApplication formcoordinatorEquipment spec sheetofficeLoad calculationT3Site plancoordinator1 missing · site plan · coordinatorSubmitSubmittedJ-541 · furnace replacement · RiversidedraftingsubmittedapprovedRiverside rules → 2 itemsApplication formcoordinatorEquipment spec sheetofficeSubmitSubmittedinspection Oct 30 · booked

A process that lives in one person's head

Every permit packet looks alike until it reaches the building department. Eastside wants a load calculation and a site plan; Riverside doesn't; Northside changed its form in the spring. The coordinator knows all of it. When they're away, packets go in incomplete and come back weeks later.

A workflow application holds those rules. A new job in Eastside gets Eastside's list. Each item goes to the person who supplies it. The packet can't be submitted until the list is complete, and a correction from the town reopens exactly the step it concerns.

Today, and with a workflow application

Today

  1. 01The coordinator starts a packet from last time's folder.
  2. 02Requirements are remembered, or looked up on the town's site.
  3. 03Documents are chased by text and email.
  4. 04Corrections arrive by email and wait in someone's inbox.

Incomplete packets go in, come back weeks later, and the job's start date slips.

With a workflow application

  1. 01A job that needs a permit opens a packet with its town's list.
  2. 02Each item is assigned to the person who supplies it.
  3. 03The packet can't be submitted until every item is attached.
  4. 04A correction reopens the step it concerns and notifies its owner.

Every packet complete the first time it goes in, whoever prepares it.

Six states, and what moves a case

Each state has one owner and one condition for leaving it. That's what makes the process visible.
DraftingCoordinatorEvery required item attached
ReadyOffice managerPacket reviewed and fee paid
SubmittedBuilding departmentApproval or a correction from the town
Correction neededCoordinatorCorrection attached and resubmitted
ApprovedDispatcherInspection booked with a technician
Closed—Inspection passed and recorded on the job

The rules, town by town

Rules are data in the app, not knowledge in a head. When a town changes its form, one record changes.

Northside

Required
application form, equipment spec sheet, contractor licence copy
Fee
paid online at submission
Inspection
booked by phone after approval
Kept current by
coordinator

The parts it's built from

Each part is built and tested on its own, so you can start with one and add the rest.
  1. Rules

    Workflow Applications

    Each town's list kept as data.

  2. Case

    Workflow Applications

    • the job
    • its town's rules
    • who supplies what

    item missing → submit stays locked

  3. Automate

    Workflow Automation

    Reminders, status from the town, the next step started.

  4. Connect

    API Services

    Packets open from jobs; approvals land on the schedule.

Underneath every stepIdentity & Access ManagementWho can submit, approve and change the rules.

What changes from one business to the next

The processWhich process, and where it starts and ends
RulesWhat each case needs, and what decides it
StatesThe steps, each with an owner and a condition to move on
PeopleWho supplies, reviews and approves

A common starting point is a Postgres database holding cases and rules, a Next.js application, n8n for reminders and status checks, and connections to the system that holds your jobs. These are starting candidates, not requirements.

Is a workflow application the right system?

Good fit

  • A process has several steps, several people and rules that vary by case.
  • Mistakes send work back weeks.
  • The rules can be written down, even if only one person knows them today.

Avoid when

  • Several processes need to share one queue and one set of records. Look at a workflow platform.
  • The process is one approval. Look at approval workflows.

How we'd approach it

Most of the early work is mapping the process, its rules and states, and the people responsible for each step.
  1. 01

    Understand

    As much as the problem needs

    We map how the work runs today: who does what, which systems hold the records, and where it breaks.

  2. 02

    Design

    Decided before it's built

    Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.

  3. 03

    Build

    Connected to what you use

    We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.

Questions about workflow applications

Couldn't we use a project management tool?

For tracking tasks, yes. It won't know that Eastside needs a site plan, or stop a packet going in without one.

What happens when a rule changes?

Someone with permission edits the rule. New cases use it straight away; cases already under way keep the rules they started with unless you choose otherwise.

Can the town's status come in automatically?

Where the town offers a portal or an API, yes. Otherwise a person records it, and the next step starts from there.

What about cases that don't fit?

A person can override a rule, with a reason. The override is recorded, and frequent overrides tell you a rule needs changing.

Get the process out of one person's head

Tell us about the process that depends on one coordinator. We'll show you how each case would move.

Start a project