02
The workflow comes first. The stack follows.
Henswick turns the mapped workflow into a working system, using the right combination of interfaces, workflow logic, connectivity and the business applications you already run.
From workflow map to system design
Map the work first. Then define the system around it.
Henswick does not start by choosing software. It starts by defining operational logic: what triggers each step, who owns it, what gets checked, and what happens when the work doesn't fit.
Fig. 1 · Discovery input becomes design decisions
Discovery input
-
Systems
Where the work lives today
-
Handoffs
Where work passes between people
-
Ownership
Who holds each step
-
Approvals
Where a person decides
-
Exceptions
Work that doesn't fit the path
-
Friction
Re-keying, chasing, waiting
Henswick
↓ Henswick defines the operating logic
Design decisions
-
Interfaces
Where people see and act
-
Triggers
What starts each step
-
Routing
Who gets the work next
-
Responsibilities
One named owner per step
-
Validation
What is checked, and when
-
Exception handling
Where off-path work goes
-
Completion states
What “done” actually means
Software is chosen after these decisions are made, not before them.
The capability stack
The capability stack changes. The approach doesn’t.
Every workflow draws on the same four layers. Which parts of each layer get used depends on the work, not on a fixed platform.
Fig. 2 · Four layers, combined differently for each workflow
Layer 01
Interfaces
Where people see and act on the work.
Browser extensions · Internal tools · Forms · Client portals · Operational screens
Layer 02
Workflow
The logic that decides what happens next.
Routing · Approvals · Validation · Orchestration · Exception handling · Status progression
Layer 03
Connectivity
How information moves between systems.
APIs · Webhooks · Ready-made connectors · Workflow platforms · Custom integrations
Layer 04
Systems
What already holds the records. These stay in place.
CRM · ERP · Finance · Project systems · Administrative portals · Legacy applications · Internal databases
Same four layers. Three different builds. · Illustrative
Build A
Intake and approval
Interfaces
Client portal
Workflow
Validation, approval routing
Connectivity
Webhooks
Systems
CRM, finance
Build B
Record sync between systems
Interfaces
No new interface needed
Workflow
Validation, status progression
Connectivity
APIs, ready-made connector
Systems
ERP, project system
Build C
Exception handling in the field
Interfaces
Browser extension, operational screen
Workflow
Routing, exception handling
Connectivity
Custom integration logic
Systems
Legacy application, internal database
Systems stay in place
You keep the systems. Henswick connects the work between them.
Henswick is not trying to replace a CRM, ERP, finance system, project system, portal or legacy application. It extends and connects what you already own.
Fig. 3 · The workflow layer sits between your systems
Existing systems
- CRM
- Project system
- Client portal
- Legacy application
01
They stay exactly where they are. Nothing is ripped out or replaced.
Work moves in
Henswick workflow layer
Rules, routing and approvals, built around how your team works.
- Information
- Approvals
- Tasks
- Status
02
Information, approvals, tasks and status move through one defined layer.
Results written back
Downstream systems · remain systems of record
- ERP
- Finance
- Project records
- Internal database
03
Completed work is recorded where it always has been.
Henswick extends and connects what you already own. It doesn’t replace it.
Implementation
Build the system around the work.
Henswick designs and deploys workflow systems around a defined operational problem, and builds each part the work needs. This is implementation, not a strategy deck.
Fig. 4 · One workflow, built · what is implemented at each step
Internal tools
One shared view of status, ownership and exceptions across every step.
1
Entry
Work arrives
Built
Forms, portals or browser-based workflows capture the work in a controlled format.
2
Check
Work is validated
Built
Validation rules stop incomplete or inconsistent work before it moves on.
3
Route
Work is directed
Built
Routing logic sends it to the right owner, with the context attached.
4
Decide
A person signs off
Built
Approval points put people in the loop where it matters, with exception paths for the rest.
Exceptions go to a named owner
5
Record
Work is completed
Built
System connections and custom API layers write the result back to the system of record.
Custom code
Only where the logic needs it.
The result is a system in use, not a recommendation document.
Reusable by design
Reuse what should not be rebuilt every time.
Where the same operational problem appears again and again, Henswick can use or develop reusable parts, so a new build starts further along instead of from zero.
Fig. 5 · Parts drawing · assembled per workflow
Reusable parts
A growing set, developed as work repeats
P1
Workflow components
Routing, validation and approval steps that recur.
P2
Browser extensions
Small tools that work inside the apps people already use.
P3
Internal utilities
Helpers for checks, formatting and data clean-up.
P4
Operational interfaces
Forms, queues and status views.
P5
Integration patterns
Established ways of connecting a type of system.
↓ Assembled for the workflow
Assembled for this workflow
Supplier request · illustrative
P4
Operational interface
Request form and status view.
P1
Workflow component
Validation and approval routing.
P5
Integration pattern
Write the approved record back.
Custom
This workflow only
The rules specific to this business.
- Reused part
- Custom to this build
Custom where necessary. Reusable where sensible.
Design boundaries
Every build needs clear boundaries.
Implementation is more than connecting one system to another. The design fixes what the build is responsible for, who is accountable around it, and exactly where it ends.
Fig. 6 · The perimeter of a build
Source of truth
Your system of record
Read from, and written back to.
Trigger
A defined event
Nothing starts on assumption.
Inside the build
The controlled system
- Owner
- Approval
- Permissions
- Exception path
Completion
A defined end state
Recorded where it belongs.
Boundary
Henswick stops here
The edge is written down.
01
Source of truth
Which system holds the authoritative record for each piece of information. The workflow reads from it and writes back to it. It never keeps a competing copy.
02
Workflow trigger
The exact event that starts the work: a form submitted, a status changed, a record created. Nothing runs on assumption.
03
Ownership
One named owner for every step and every outcome, so work is never waiting on “someone”.
04
Human approval points
The decisions that stay with people, and what each approver sees before they decide.
05
System permissions
What the workflow may read, create and change in each connected system, and nothing beyond that.
06
Exception paths
Where work goes when it doesn’t fit the rules: to whom, with what context, and how it rejoins the flow.
07
Completion criteria
What has to be true before the work counts as done, and the record that shows it.
08
Where Henswick stops
The edge of the build is written down: what is delivered, what stays with your team, and which systems are left untouched.
Build output
A build plan that can actually be implemented.
Design ends with a technical specification the build can follow. Each rule, interface and owner is written down, so implementation is direct rather than interpreted.
Build plan · Technical design sheet
Illustrative extract · Supplier request
Contents
01
Workflow architecture
Steps, states and how they connect.
02
System interfaces
What is read and written, and where.
03
Trigger logic
What starts each step.
04
Data movement
Which fields move, in which direction.
05
Validation rules
What must be true before work moves on.
06
Approval points
Where a person decides.
07
Exception behavior
Where off-path work goes.
08
Ownership
Who holds each step.
09
Deployment plan
How the build goes into use.
Rule register · Extract
03
When
A supplier request is submitted in the portal.
05
If
Tax ID, bank details and category are all present.
05
Else
Return it to the requester with the missing fields listed.
06
If
The value is above the approval threshold.
06
Then
Route to the finance lead for a decision.
04
Then
Write the approved record to the ERP and update the request status.
07
If
No decision within two working days.
07
Then
Escalate to the named backup owner.
Document
Build plan
Status
Design complete
Chapter
02 of 05
Design produces something buildable.
Next chapter / 03
- 01
- 02
- 03
- 04
- 05
Prove the workflow under real operating conditions before it becomes part of the business.
Start here
Have a workflow mapped and ready to build?
Henswick can turn the operating logic into a working system around the tools your team already uses.
Discuss your workflow