Approach / 03 of 05

01 Discovery
02 Design & Build
03 Testing
04 Governance
05 Support

A workflow isn’t finished when it works once.

Henswick tests the paths, exceptions, dependencies and failure conditions around a workflow before it becomes part of day-to-day operations.

From design to testable behavior

A design becomes real when every path has a result.

The design says what the workflow should do. Testing shows what it does when data is missing, systems stall and people don’t answer.

Fig. 1 · A design, marked for test

01
Trigger
A defined event starts the work.
Test
Does the trigger fire twice?
02
Route
The work goes to the right place.
Test
Does the record already exist?
03
Validate
The data is checked against the rules.
Test
Is required data missing?
04
Approve
A person decides where needed.
Test
What if the approver doesn’t respond?
05
Record
The outcome is written back.
Test
What if the downstream system is unavailable?

Every stage of the design carries a question the test has to answer.

Validation

Test the workflow, not just the connection.

A connection test shows that two systems can talk. A workflow test shows what happens to the work when they can’t, or when something arrives that the design didn’t expect.

Fig. 2 · Test matrix

Validation sheet · Test matrix

Illustrative extract · Supplier request

Condition

What is tested

Expected behavior

Result

Normal path
Tested
A complete request moves from trigger to record.
Expected
Every step completes in order. One record is written.
Confirmed
Missing data
Tested
A required field is blank at intake.
Expected
Work is held. The requester is told exactly which field is missing.
Held
Duplicate event
Tested
The same trigger arrives twice.
Expected
The repeat is recognized. No second record is created.
Matched
System unavailable
Tested
The downstream system does not respond.
Expected
State is preserved. The write is retried, then routed to a person.
Retried
Permission failure
Tested
The workflow lacks the rights to change a record.
Expected
The write is refused cleanly. The owner is told what was blocked.
Routed
Human approval
Tested
The approver declines, or never answers.
Expected
A decline returns with a reason. Silence escalates after the agreed time.
Escalated
Exception path
Tested
Work arrives that fits none of the rules.
Expected
It lands with a named owner, with full context, not in a dead end.
Routed
Retry / recovery
Tested
A failed step is repeated.
Expected
It repeats safely: no duplicate writes, same final state.
Confirmed

Every condition has an expected result. Every result is observed.

Exception paths

The happy path is usually the smallest part of the test.

A request that arrives complete, is approved on time and lands cleanly is the easy case. Most of the testing effort goes to everything that can interrupt it.

Fig. 3 · One request, every path

01
Request received
Clean path: continues
- Duplicate request
  Hold
  Matched to the first request. Nothing is created twice.
02
Validated
Clean path: continues
- Missing field
  Return error
  Sent back to the requester with the missing field named.
03
Approval
Clean path: continues
- Approver unavailable
  Route to person
  Passed to the named backup after the agreed time.
04
Downstream update
Clean path: continues
- Downstream timeout
  Preserve state · Retry
  Work done so far is kept. The write is retried, not restarted.
- Record conflict
  Route to person
  Held with both versions for a person to resolve.

Failure behavior is part of the workflow design.

Recovery

Failure should have somewhere to go.

A failed step should never be a dead end. Recovery is tested as behavior: the failure is forced, then the path back to a valid state is observed.

Fig. 4 · The recovery path

01
Fail
A step cannot complete: a timeout, a refused write, a missing approval.
02
Preserve state
Hold what was already done. Nothing is lost, nothing is repeated.
03
Route
Notify the person who owns the exception, with full context.
04
Correct / retry
Fix the cause and retry safely, or reconcile the records by hand.
05
Resume
Work continues from where it stopped, not from the beginning.
06
Confirm
The final state is checked against the expected result.

From the first failure to a confirmed result, work is neither lost nor done twice.

Controlled deployment

Move into production in controlled stages.

Going live is a decision, not an event. Each stage widens the scope only when the one before it has behaved as expected.

Fig. 5 · Release sequence

Release record · Controlled rollout

Illustrative extract · Supplier request

Validate

Test against known conditions.

Test conditions only

Proceeds when

Every condition behaves as expected.

Controlled rollout

Limited users, limited volume, observed behavior.

Limited scope

Proceeds when

Real use matches the tested behavior.

Production

The workflow becomes operational.

Full scope

Proceeds when

The named owner approves the release.

Observe

Confirm expected behavior under real use.

Full scope · Observed

Closes when

Behavior is confirmed and ownership passes on.

After launch

Launch also establishes who owns what next.

A tested workflow still needs someone responsible for it. Before it goes live, these responsibilities are named rather than assumed.

Responsibilities named at launch

01
Monitoring
Who watches the workflow once it is live.
02
Incident response
Who is told, and who acts, when something breaks.
03
Workflow changes
Who changes the rules, and how a change is released.
04
Documentation
What is written down, and where it is kept.
05
System changes
Who adjusts the workflow when a connected application changes.
06
Operational ownership
Who is accountable for the workflow, day to day.

Two ways to run it

Client-operated

Henswick builds, tests, documents and hands over.

Henswick-managed

Henswick remains involved after launch.

Deployment readiness

A release record built around operating reality.

Before a workflow goes live, the evidence sits in one place: what was tested, what was observed and who owns it from here.

Fig. 6 · Deployment readiness record

Deployment readiness record

Illustrative extract · Supplier request

Record

Workflow version

Supplier request · v1.3

Rollout scope

Procurement team · new requests

Owner

Procurement lead

Recovery path

Return to manual intake. Queued requests preserved.

Production state

Approved for controlled rollout

Verification

Test conditions run

Complete

Exception paths

Verified

Permissions

Checked

Retry behavior

Confirmed

Approvals

Verified

Condition register · Extract

Condition

Expected

Observed

Status

Missing data

Expected

Held. Requester told which field.

Observed

Held. Requester told which field.

Confirmed

Duplicate event

Expected

One record created.

Observed

One record created.

Confirmed

Downstream timeout

Expected

Retry, then route to a person.

Observed

Retried twice. Routed to owner.

Confirmed

Approver silent

Expected

Escalate to backup after two days.

Observed

Escalated at two days.

Confirmed

Document

Deployment readiness record

Status

Deployment approved

Chapter

03 of 05

Launch is a recorded decision, not a hope.

Next chapter / 04

Governance & Controls

Define the ownership, approvals and boundaries that keep automated work accountable.

Start here

Need confidence before a workflow goes live?

Henswick can validate the operating paths, failure conditions and deployment plan before the workflow becomes part of day-to-day work.

Discuss your workflow