ServiceNow implementations are mostly repeated configuration, rebuilt by hand per instance, promoted through update sets that drift from each other. It is the clearest example of work that looks bespoke and is not.
Available today
The adapter is real and something is incomplete, either a part of the destination or real-provider proof for part of the lifecycle. The gap is stated on the page rather than discovered during an evaluation.
What a forward deployed engineer does by hand today.
A scoped application or an integration built directly in the instance, developed in a sub-production instance and promoted through update sets. Nothing about this is a single install step.
The person whose calendar decides your go-live date.
The ServiceNow platform team, and a change request through the customer's own ITSM process. Which is, with some irony, managed in ServiceNow.
Whose identity the product acts as, and where that grant lives.
OAuth 2.0 against the instance, or basic auth against an integration user, which is still common and still what security review objects to.
The repeatable half, turned into software.
The instance OAuth flow, per-environment credentials, and validation that reads a real record and checks a named field survived the ACLs. ServiceNow cannot tell us which instance a grant belongs to, so it is configured before the installation starts and a missing one is caught then rather than after somebody approves something.
The half that is theirs and should stay theirs.
The instance, its update set process, its change windows, and every piece of configuration somebody added in 2018.
How capabilities map onto what the platform will let you do.
Roles and ACLs. A capability needs a role that needs an ACL that may or may not exist in this instance.
What has to execute before anyone is told it works.
Health checks against the instance, and execution in a sub-production instance before production is touched.
Rotation, expiry, revocation, and who notices first.
Instance-scoped OAuth tokens, or an integration user whose password is in somebody's vault.
What happens to this customer when you ship version four.
Update sets are already a version mechanism and they drift. A per-customer deployment record that knows which update set is actually applied is the missing half.
What actually goes wrong, named rather than generalised.
Update set collisions. Configuration present in the sub-production instance and absent in production. Platform upgrades changing behaviour under a working integration.
How you learn it broke without the customer telling you.
Health compares the scopes this installation holds against what the current package needs. HubSpot does not extend existing installs when an app adds a scope, so an older customer shows as needing a reinstall instead of the capability silently failing for them.
The adapter is real and something is incomplete, either a part of the destination or real-provider proof for part of the lifecycle. The gap is stated on the page rather than discovered during an evaluation.
The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling.
Lifecycle coverage
This label is generated from a proof registry in the deployment code, not written on this page. A destination cannot read Available until every lifecycle path above has actually run against the real provider, and a test refuses the claim without dated evidence.
Connect a source, publish, and send one link. Your next enterprise customer installs itself.
2 customer environments free, forever. No card required.
