The ticket said "Complete"
An identity governance platform provisions access, and reports the outcome back into ServiceNow so the originating ticket closes with the right status. That's the whole integration, in one sentence, and it's exactly the kind of integration everyone assumes is either working or obviously broken. This one was neither. It was silently reporting success and failure identically.
What was actually happening
The integration's status-check call was using the API's default response mode. Reading the vendor's own API documentation for that mode surfaced the actual definition being relied on: the status string meaning "Task Completed" is documented to cover every task reaching any end state: completed, failed, or discontinued, all three, indistinguishably. Not a bug. A deliberate, documented design for a coarser use case than "did this access actually get granted."
The response wasn't lying. It was answering a different, coarser question than the one the integration was actually asking of it, and nobody had noticed the two questions weren't the same.
Confirmed directly, not inferred: two real requests through the same integration, one a genuine successful grant, one a deliberate negative test where every underlying task errored out. Both closed in ServiceNow as "Complete." Identical status string, opposite outcomes.
The fix was one parameter: the hard part was finding it
A second, non-default parameter on the same API call unlocks a materially more granular set of status values, enough to actually distinguish a genuine success from a failure or a discontinued task, rather than collapsing all three into one word. Nothing about enabling it required a platform change, a support ticket, or a workaround. It required someone to read past the first page of the API reference and ask what "Complete" was actually promising.
Why this is a governance problem, not just an integration bug
A ticketing status looking wrong is an IT annoyance. A governance platform's own audit trail recording "access successfully provisioned" for a request that actually failed is a different category of problem entirely: it's the exact evidence an access review or an auditor would later rely on to confirm access was granted correctly. If that evidence is wrong at the source, every downstream certification built on it inherits the same false confidence, and nobody has a reason to go looking until something breaks in a way that's impossible to ignore.
Worth checking on your own integrations: for any platform-to-ITSM status handoff you rely on, ask specifically what the "success" status string is documented to mean, not what it's assumed to mean. A status field that can be true for three different underlying outcomes is a real, checkable thing, not a hypothetical risk.
Why this is easy to miss
Nothing about this integration looked wrong from the outside. Tickets closed. Dashboards were green. The failure mode only exists because two genuinely different outcomes produce the same visible signal, which means the only way to find it is to deliberately test the failure path, not just watch the success path work. A negative test that forces a real failure and checks what actually gets reported back is a cheap, five-minute check most integrations never get, precisely because the happy path always looks fine.
Key takeaways
- A platform's default API response can genuinely be unable to distinguish success from total failure: check what the documented status actually promises, not what it implies.
- This surfaced by testing the failure path deliberately, not by watching the success path work. Most integrations are never tested that way.
- A false "Complete" on a provisioning task isn't just a ticketing annoyance: it's audit evidence that's wrong at the source, and every access review built on top of it inherits the same false confidence.
- The fix here needed no vendor support ticket and no platform change: just reading what the coarse response mode was actually documented to mean, and switching to the granular one.