Evaluating Against the Joins

Every product in this market has a feature list that satisfies every requirement. The joins are where they differ.

The identity questions

Can it hold an external identifier as the primary key, or does it insist on its own?

What happens when a person is rehired?

Can it receive joiner, mover and leaver events, or does it expect manual entry?

A product that cannot reference an external master identity will become the master by default, which is a decision you should make rather than inherit.

The reference data questions

Can departments, sites and cost centres be received rather than maintained?

Does it support effective dating on them?

What happens to historical records when a structure changes?

The third question is the one nobody asks and the one that determines whether last year's reports still reproduce.

The interface questions

What exactly crosses each boundary, field by field? Ask for the specification, not a diagram.

Is the import idempotent?

Is there a replay path for a failed period?

Is there a delivery log you can query?

Can an export be produced without the fields the destination has no use for?

The rule questions

Which calculations does it perform, and can each be switched off?

This is the question that prevents double-counted overtime, and the answer determines the rule register.

A product that calculates overtime and cannot be told not to forces the rule to live there, which may not be where you want it.

The trial

Do not demonstrate a module. Demonstrate a join.

Load your own people with your own identifiers.

Push a period through to a payroll-shaped output and reconcile it by hand.

Break something deliberately — a missing person, a changed department, a duplicate file — and see what the product does.

That afternoon tells you more than any feature matrix.

Red flags

Integration described as "we have an API" without a specification.

No answer on idempotency.

A module that insists on mastering identity or reference data.

Calculations that cannot be disabled.

And a demonstration that never leaves one module, which is a demonstration of the easy part.

Demonstrate a join, not a module

The trial that separates products.

Load your own people with your own identifiers.

Push a period through to a payroll-shaped output and reconcile it by hand.

Break something deliberately — a missing person, a changed department, a duplicate file.

An afternoon of that tells you more than any feature matrix, and no vendor demonstration will do it unprompted.

Turn the boundary into a test

For a concrete product reference, workforce software pricing guide can help turn this boundary into a test. Verify the current behaviour with representative fields and record what reaches the destination.