The 70% Threshold: When a Partial Integration Does More Harm Than None

An integration that half-works can cause more problems than no integration at all.

The pattern

There is a pattern that surfaces regularly on enterprise implementations. A use case gets scoped, an integration gets built, and it handles the primary scenario well. The build goes live. Everyone moves on.

Then the edge cases arrive.

Take creating a bonus payment in a payroll system, triggered from Workday. The creation flow works. But when a payroll officer needs to update that payment, or cancel it, the integration may not cover those actions. Those steps have to happen directly in the payroll system, outside of Workday entirely.

The result is a fragmented experience. Staff learn the boundary, but retention of that knowledge moves with your staff. The boundary is invisible until someone steps over it. Errors follow. Workarounds get built on top of workarounds.

The rule, more precisely

The 70% rule isn’t really about how much of an integration you build. It’s about how much of the underlying business process flow the integration can carry end to end. An integration can be technically complete, everything it was scoped to do works exactly as built, and still only cover 70% of the actual process a person has to follow to get their job done. The gap sits in the steps either side of the build: the change, the correction, the exception, the thing that happens the week after go-live and every fortnight after that.

That distinction matters because it’s easy to sign off a build as successful against its own scope and still leave the business carrying a broken process.

Where this shows up in practice

This is exactly the kind of gap I worked through on a payroll case, where the client’s downstream payroll system could handle payroll changes, but only as at the start of the pay period, not mid-period. The integration ran through Workday, PECI, Workday Studio, out to ADP Payforce. There was extended back-and-forth on what could realistically be built to close that gap. We landed on supplementary reporting rather than building the level of integration complexity that mid-period change handling would have required, because that complexity would have created a maintenance burden far more complex than the team was ready to support.

I’ve seen the same pattern on a separate client, where one-time payments could be integrated cleanly into ADP Workforce Now, but updates and deletes couldn’t be. Different vendor product, same shape of gap.

In both cases, when that gap surfaces, it typically costs the payroll team around a day of effort from one resource to work around manually. In organisations running fortnightly payroll, where the processing window is tight and time-critical, that’s not a rounding error. It’s a recurring, predictable cost that never appeared in the original build estimate.

The threshold

The threshold worth applying before committing to a build is this: if an integration cannot cover at least 70% of the primary business process end to end, is the employee experience worth the remaining 30%? You are substituting potential volume for complexity, and it’s worth being honest about which one you’re actually optimising for.

Sometimes a partial integration, or a supplementary process like reporting, is still the right call. But that decision should be conscious, documented, and understood by the business, not an assumption buried in a requirements document.

Why the coverage gap matters more than the failure rate

The integrations that cause the most pain are rarely the ones that fail outright. Outright failures get noticed, escalated, and fixed. It’s the ones that half-work, and leave people unsure of when to trust them, that quietly erode confidence in the system. A payroll officer who has been burned once by an integration that silently didn’t cover their scenario will start double-checking everything it does, including the parts that work fine. That’s a productivity cost that never shows up in a project retro, because it never gets reported as an incident.

A quick framework for scoping conversations

• Create — does the integration handle the primary, happy-path creation of the record or transaction?

• Update — can the value, timing, or details be changed after the fact, and does the integration carry that change through, or does it stop at the point of change?

• Cancel / delete — can the action be reversed or removed, and does the integration reflect that downstream?

• Timing edge cases — does the process behave differently depending on when in the cycle it happens, such as mid-period versus start-of-period, and is that difference covered?

• Who owns the manual fallback — if a scenario isn’t covered, is it documented who does it, how, and how long it takes?

• What does the fallback cost, repeated over a year — a one-day manual workaround feels trivial once. Multiplied across every pay cycle for three years, it’s a maintenance cost the business signed up for without knowing it.

If you can’t answer all six with confidence before build and test ends, that’s the 30% you’re about to leave uncovered, and it’s worth naming before it becomes someone’s Tuesday-afternoon fire drill.

Before signing off a build as covering a business process, it’s worth walking the full lifecycle of the scenario, not just the trigger event.

Building with this lens

Building with that lens from the start is a core part of how Santinon Consulting approaches integration design: scoping the full lifecycle of a use case, not just the happy path, and being explicit with the business about where the 30% sits and what it costs to leave uncovered versus what it costs to close the gap.

Related reading: What I Learned Inheriting 100 Integrations and Every Integration Has Two Costs.

If you are scoping a build and want that kind of thinking in the room early, get in touch.