Configure around policy, not custom code

Here is a policy we have been handed, in some variation, by almost every organisation we have deployed to: travel approvals vary by role, by value, by business unit, and by effective date. An executive booking a hotel is not the same decision as a field technician booking the same hotel, and last quarter's threshold is not this quarter's.

In most HR systems that is a change request. In HumanC it is configuration.

Three layers of governed flexibility

Configuration in HumanC is deliberately layered, so that "flexible" never means "ungoverned".

• Platform configuration — brand, language, timezone, codes, custom fields, email and approval settings.
• Roles and segregation of duties — who can view, change, approve or administer each capability.
• Data scope, audit and interfaces — organization scope, resource access, active assignments, change history and agreed interfaces.

A Vietnam HRBP gets Vietnam scope. A Payroll Admin gets compensation scope. An integration role gets exactly one approved interface. The flexibility is real, and so is the boundary around it.

What the travel policy looks like configured

The example above resolves into three configurable pieces: request and evidence (capture trip, cost and supporting documents), policy and routing (route by amount, policy and role), and scope and authority (apply by company, grade and country).

The employee then submits a request, a manager or Finance reviews it against limits they did not have to memorise, and the decision history is retained. Limits themselves sit in a matrix — hotel per night, transport, per diem — that varies by position, destination, grade, employee group, currency and effective date.

Fit local policies. Govern change. Scale without rebuilding.

Why this matters at implementation time

Configuration-first changes the shape of a rollout. Our delivery path runs in three stages, each with a deliverable that has to be signed off before the next begins.

• Discover & Design — confirm processes, policy variants, data owners and success criteria. Deliverable: a signed-off blueprint.
• Configure & Migrate — configure modules, prepare data and connect agreed interfaces. Deliverable: a configured solution with migrated data.
• Validate & Enable — run UAT, reconcile critical outputs, train users and prepare support. Deliverable: go-live readiness.

Configure first, validate with users, then scale by module. The reason that sequence works is the same reason the policy example works: nothing in it waits on core code.