We've been running ServiceNow GRC's Policy and Compliance Management for about 18 months, integrated with DocuSign for our policy repository and attestations. The sync was stable, albeit slow. After the recent Madrid patch (to take the latest major release), the integration is broken. Documents are not syncing from DocuSign into the `sys_attachment` table for policy records, and the logs are a mess of vague "connection refused" errors, but our network team confirms all whitelisted IPs are open and the DocuSign side shows successful callbacks.
I've spent two days digging through this and the problem appears to be in the updated OAuth 2.0 authentication flow and how the MID server is handling the new handshake. The pre-update JWT-based workflow is deprecated, and the new implementation seems to have a mismatch between the expected token scope and what's being requested.
Here's what I've verified so far:
* DocuSign Connect is configured correctly, webhooks are firing, and we see successful POST attempts to our ServiceNow instance URL.
* The MID server (version 2.5.5) is running, shows "Up" status, and can reach both DocuSign and our ServiceNow instance.
* The OAuth 2.0 provider definition in ServiceNow has the correct redirect URI, client ID, and secret.
* The `eSignature - DocuSign` plugin is activated (version 2.0.2).
The critical error in the `syslog` table for the integration points to a failed authentication token refresh, but the OAuth adapter logs are useless. I suspect the token is being acquired for a user context that doesn't have the `webhook.manage` scope, or the MID server is failing to forward the necessary headers.
Has anyone else deconstructed this specific breakage post-update? I need concrete details on:
1. The exact required scope for the OAuth 2.0 authorization in the new setup. Is it just `signature` or `signature webhook.manage`?
2. Any mandatory changes to the MID server's `http.properties` or `oauth.properties` configuration for the new token endpoint.
3. Whether the "DocuSign Account" field on the policy record type needs to be repopulated or re-authorized after the update.
I can provide sanitized MID server logs and the relevant OAuth adapter failure snippet if needed. This is blocking our quarterly policy review cycle, and the official documentation is still referencing the old method.
—davidr
—davidr
That "connection refused" error is a red herring a lot of the time - it's the MID server's generic way of saying the OAuth handshake failed before it even got to the actual network call. I've seen this exact pattern with OAuth 2.0 upgrades in other integrations.
Have you checked the MID server's OAuth provider configuration specifically? The new flow might require a different scope string than what you had in the old JWT setup. DocuSign's side showing successful callbacks doesn't mean the token scope matches what ServiceNow expects on the receiving end. The MID server 2.5.5 also isn't the newest - I'd bump that to at least 2.7.x if you can, because there were some OAuth 2.0 handshake fixes in the 2.6 range.
What's the exact error in the MID server's debug log when it tries to exchange the auth code?
Automate everything.
Totally agree about the "connection refused" being a red herring. It's like the platform's polite way of saying "I have no idea what you sent me, but I'm not letting it in."
The scope mismatch you mentioned is often the silent culprit. In our upgrade, the new OAuth 2.0 flow required the full `signature impersonation` scope to be explicitly stated in the provider config, where the old JWT setup kind of implied it. The callback success from DocuSign just means the request was received, not that the resulting token has the right permissions for the subsequent data pull.
And yes, 2.5.5 is definitely getting long in the tooth for this. The 2.6.x line had some critical patches for exactly this kind of token exchange fragility. If OP's upgrade was to Madrid, they really should pair it with a mid server update. The logs around the auth code exchange are usually in `ecc_agent_detailed.log` if they have that enabled.