BuzbyTimeRead the requirements guide

Choosing and running the software · 4.3

Integration, and what it costs

Integration, and what it costs. What decides it, what it costs, and what usually goes wrong. For another implementation reference, see the Monitask overview.

The connector is not the costThe part that is underestimated

Integrations are sold as a line item and paid for as an ongoing obligation. The connector is configured once; the reconciliation, the mapping maintenance and the failure handling continue for as long as both systems exist.

Budget the second, not the first, and ask any supplier what their customers actually spend on keeping an integration working. A useful outside reference is Freshworks.

Five systems this usually touches

Payroll. The highest-consequence connection, because an error is somebody's wages.

Accounting or invoicing. Where attribution becomes money.

Project or job systems. The source of the list people record against.

Identity. So that leavers actually lose access.

Calendar. Frequently proposed as a source of time entries and frequently a poor one, because a calendar records intentions.

Decide the source of truth first

For every field that exists in two systems, one of them owns it. Write that down before configuring anything.

Undeclared, this resolves itself badly: both systems accept edits, the sync overwrites in whichever direction ran last, and somebody spends a week each month reconciling a discrepancy nobody can explain.

Three failure modes

Silent failure. The sync stops and nothing says so. Discovered at month end, having lost three weeks. Ask specifically how a failure is surfaced and to whom.

Duplicate creation. A retry that creates rather than updates. Visible as a payroll figure nobody can reconcile.

Mapping drift. A project renamed in one system and not the other, so entries land against something unrecognisable.

All three are ordinary. What distinguishes a good arrangement is that each is detected rather than prevented, because none can be prevented entirely.

Who owns it when it breaks

Between two suppliers, an integration frequently belongs to neither. Establish before signing which party fixes it, within what period, and who to call at three in the afternoon on payroll day.

Where the answer is that you own it, that is fine and it needs a named person internally with the access to do something.

One-way where possible

A one-directional flow is dramatically simpler to reason about, to debug and to explain. Two-way sync is occasionally necessary and usually chosen because it sounds more capable.

Ask what would break if the connection were one-way. Frequently the answer is nothing anybody would notice.

Reconciliation as a habit

Monthly, compare a total in both systems. Five minutes, and it catches every failure mode above within a month rather than within a year.

Start with fewer

Every integration configured at launch is one more thing that can fail during the fortnight when people are forming an opinion of the system.

Connect payroll first, live with it for a period, then add the next. The delay costs a little convenience and it isolates every problem to one cause.

Manual is a legitimate integration

A monthly export and import, performed by a person, is slower and it is visible, debuggable and free. For a small organisation with one payroll run a month it is frequently the right answer, and no supplier will propose it.

Identity in particular

Connecting to your identity system means a leaver loses access automatically, which is the single most valuable integration for reasons that have nothing to do with time.

It is also usually the easiest, and it is frequently the last one anybody gets to.

Documenting the mapping

Which field in one system corresponds to which in the other, and who decided. In your documentation, not only in a configuration screen, because the person who set it up will not be the person debugging it.

Payroll integration deserves its own paragraph

It is the connection where an error becomes somebody's wages, and the failure modes are the ones people notice on payday.

Run it in parallel for a full cycle before relying on it: the old process and the new one, compared line by line, with somebody checking rather than assuming. One month of double work, and it catches the rounding difference, the overtime rule mismatch and the person whose record did not transfer.

Organisations that skip the parallel run generally discover all three at once, in public.

Rate limits and volume

An integration that works with fifty people may not with five hundred, and the failure appears as a sync that takes longer each month until it does not finish. Ask about volume at the size you expect to be in two years rather than the size you are.

A monthly check that takes five minutes

Compare one total in both systems. Record that you did it and the result, in the same place as the retention schedule.

It sounds trivially small and it is the mechanism by which silent failures become known within weeks instead of within a year.

Where to start

Draw the systems and the arrows between them on one sheet, with the owner of each field written on the arrow. Most integration problems are visible on that sheet before anything is configured.

One line to carry

The connector is configured once and reconciled forever. Budget the second, name its owner, and check one total a month.

The integration nobody plans for

Whatever spreadsheet somebody in finance maintains, which turns out to be load-bearing. It is not on any architecture diagram and it will need its input from the new system.

Find it by asking finance what they do at month end, in detail.

Also in choosing and running the software