Setup Considerations: workflow adoption

What this achieves

Every part of Humavera that needs an approval already has one built in, so a workflow of your own is an addition rather than a requirement. This page is about deciding which approvals justify one, and what you take on when you build it.

Decision 1: whether to build one at all

With no workflow bound, a request follows the approval path built into its own part of the product. Those paths are not placeholders — a leave request routes to the manager, a payroll run requires a second administrator, and a paid enrolment routes for approval by cost regardless of who requested it.

Build a workflow when the built-in path is genuinely wrong for you, not because a configurable one exists.

Option	Description
Keep the built-in path	Nothing to design, test, version, or maintain. It keeps working when people change job.
Bind your own workflow	Yours applies instead. Worth it where you need a second approver, a branch on value, or a deadline the built-in path does not impose.

Example: HC Corp leaves leave requests on the built-in manager route, and builds a workflow for promotions, where Finance and the People team both have to agree and the built-in path asks only one person.

Decision 2: how many workflows

One workflow with a condition usually beats two workflows that differ in one step. Two routes have to be edited twice, tested twice, and published twice, and eventually one of them is forgotten.

Example: promotions above and below a grade threshold are one workflow with a condition at HC Corp, not two. The alternative is two routes that drift apart the first time somebody edits only one of them.

Split into separate workflows when the request types are genuinely different, not when one value differs.

Decision 3: what happens when the person who built it leaves

Every workflow shows an owner. That is a label, not a safeguard.

Prefer approver settings that resolve from the request — the requester’s manager — over named people, so routes survive leavers without edits.
Write change notes on every publish, because they are the only record of intent.
Keep the description filled in. It is what the next administrator reads first.

Example: a route that names Daniel Okonkwo on its Finance step needs an edit the week he changes job. Nobody will be looking for it, and the first sign will be promotions that stop moving.

Decision 4: templates and generated drafts

A template or an AI-generated draft gives you a shape quickly. Neither gives you a policy.

Option	Description
Start from a template	Fastest for a common shape. Every approver, deadline, and condition in it is an example and must be replaced with yours.
Generate from a description	Useful when you know the policy in words but not the diagram. Costs AI credits, and needs the same review as a template.
Start from an empty canvas	Slowest, and the only one where nothing is inherited by accident.

Decision 5: when to switch a live request type over

Binding a workflow changes the route for requests raised from that point on. Requests already in flight finish on the path they started.

That means there is always a transition period where two paths are in use at once. Plan for it rather than being surprised by it: bind at a quiet point, watch the first instances, and tell the approvers who are about to start receiving tasks they did not receive before.

What is expensive to change later

Decision	Cost of changing later
Replacing a built-in path with your own	High. You now own the route, its versions, and everything it has to cover. Going back means deactivating the binding and accepting that history spans two shapes.
Splitting one workflow into several	Medium. Reporting and analytics are per workflow, so period-on-period comparison spans two records.
Approvers named as people rather than resolved from the request	Medium, and recurring at every leaver and promotion.
Adding a step to an existing route	Low to medium. A new version handles it, but requests already running will not include the new step.
Deadlines, reminders, escalation targets, and step names	Low.

What happens next

Once you have decided what deserves a workflow, design the route, test it against sample data, publish it, and bind it to one request type at a time. Watch the first instances through before binding the next.