Common connection failures reported by makers, with the cause and the fix for each.

Overview

Common connection failures reported by makers, with the cause and the fix for each.

Each section below is a real scenario: what you see, why it happens, and the fix.

Creating an Adobe Sign agreement fails with an INVALID_ORDER error

What's happening: The Create agreement action in an Adobe Sign automation fails with an error whose code is INVALID_ORDER and message "Order of a participant set can only be a positive integer."

Why: Each entry under Participant sets has an Order field that determines the signing sequence. Adobe Sign requires this value to be a positive integer starting at 1 — it rejects a participant set whose order is missing, zero, or negative.

Fix:

1. Open the Create agreement step and expand Participant sets.

2. For every participant set, set Order to a positive integer: 1 for the first signer, 2 for the second, and so on.

3. Make sure no participant set is left with a blank, zero, or negative order value.

4. Save and re-run the automation.

How to verify: Re-run the automation with test data — the Create agreement step should complete without the INVALID_ORDER error, and the agreement should appear in the Adobe Sign dashboard with participants in the expected signing order.

Still stuck? support@unifyapps.com

Updating an Adobe Sign agreement's state fails with an OPERATION_NOT_ALLOWED error

What's happening: A step that runs right after agreement creation — such as Update agreement state — fails with an error whose code is OPERATION_NOT_ALLOWED and message "Document processing is still in progress."

Why: Adobe Sign processes an uploaded document asynchronously after the agreement is created. If a follow-up action (updating State, fetching signing URLs, etc.) runs before that processing finishes, Adobe Sign rejects the request because the agreement isn't ready for that operation yet.

Fix:

1. Don't chain a state-changing step directly after Create agreement with no delay.

2. Add a wait/delay step, or poll the agreement (for example with Get agreement by ID) until it's ready, before running Update agreement state or similar follow-up actions.

3. Re-run the automation once the delay or polling step is in place.

How to verify: Run the automation end to end — the Update agreement state step (and any other follow-up Adobe Sign step) should complete successfully after the wait, with no OPERATION_NOT_ALLOWED error.

Key takeaway

Adobe Sign document processing is asynchronous, so a workflow that creates an agreement and then acts on it right away is racing that processing. Build in a wait or a status check between Create agreement and any follow-up action rather than assuming the agreement is immediately ready.

Send email fails right after generating a public file URL for the attachment

What's happening: The automation runs cleanly through the step that generates a public file URL, but the following Microsoft Outlook Send email step fails almost immediately with a generic connection/remote-call error. Earlier steps, including the one that created the URL, all show success — nothing points specifically at the attachment.

Why: The Send email action's Attachment URL field takes the public URL, and it has a separate File name of URL attachment field for the name the recipient will see. If you only map the URL and leave the filename blank, the action falls back to deriving a filename from the last part of the URL. A public URL produced by Generate public file URL commonly doesn't end in a normal, extension-bearing filename the way a plain download link would — so the derived name can be malformed, and that's what trips up the send. Mapping the filename explicitly avoids relying on that fallback.

Fix:

1. Open the Microsoft Outlook Send email action in your automation.

2. Confirm the Attachment URL field is mapped to the output of your Generate public file URL step.

3. Also map the File name of URL attachment field to an explicit filename — a static name (invoice.pdf), a dynamic one from earlier data, or a constructed one (e.g. combining a variable with a static extension). Make sure it includes the right file extension.

4. Fill in the rest of the email fields as usual (recipients, subject, message).

5. Save and re-run the automation.

How to verify: Run the automation and confirm the Send email step completes without error. Check the recipient's inbox for the email, confirm the attachment is present with the filename you specified, and open it to confirm it's the right file.

Key takeaway

When attaching a file by URL in the Outlook Send email action, don't rely on the action to figure out a sensible filename on its own — especially for URLs generated by a utility node rather than a normal file host. Always pair Attachment URL with an explicit File name of URL attachment, including the extension, so the attachment arrives correctly named and the send doesn't depend on how the URL happens to be structured.

The Outlook Send Mail action fails even though I already added the Mail.Send scope

What's happening: An automation's Microsoft Outlook Send Mail action errors out, even though the connection's OAuth scopes include Mail.Send. The same action works fine on other Microsoft connections, which makes it look like an account- or tenant-specific problem rather than a platform issue.

Why: The Send Mail action needs more than permission to send — it also needs permission to read/write mail on the mailbox, because of how the action interacts with the mailbox during send. If the connection's OAuth consent only includes Mail.Send, Microsoft grants that scope but the action still fails, because the Mail.ReadWrite scope was never requested or approved. Some existing connections appear to work without explicitly configuring Mail.ReadWrite if they already carry broader permissions from an earlier authorization — which is why this can look inconsistent across connections until you check the actual scopes each one was authorized with.

Fix:

1. Open the Microsoft Outlook connection used by the automation and go to its Details tab.

2. In the connection's scope/permission configuration, make sure both of the following are present, not just one: - Mail.Send - Mail.ReadWrite

3. Because the connection is likely still Active, click Disconnect first to unlock its fields, then re-enter the scopes.

4. Click Authorize (or Re-authorize) to run the Microsoft consent flow again — Microsoft will prompt for approval of the updated permissions.

5. Re-run the automation's Send Mail step to confirm it now completes.

How to verify: Run the automation again and confirm the Send Mail step finishes without error, and that the email actually arrives in the recipient's inbox (or shows up in the sender's Sent Items). Also check the automation's run logs — there should be no permission-related failure on that step.

Key takeaway

Don't assume Mail.Send alone is sufficient just because it's the scope named after the action you're using — the Send Mail action requires Mail.ReadWrite as well. When troubleshooting a failing Outlook action, check that every scope the action needs is present on that specific connection, since two connections to the same app can be authorized with different scopes and one may appear to "just work" from permissions granted earlier.

An on-prem SAP RFC connection repeatedly goes Inactive, and reauthorizing it fails

What's happening: A SAP RFC connection to an on-premises SAP system goes Inactive repeatedly. Trying to fix it the normal way — opening the connection and running Authorize / Re-authorize — fails quickly instead of bringing the connection back to Active, leaving any automation that depends on it blocked.

Why: As part of reauthorizing a connection, the platform runs a connection test against the app to confirm the credentials and network path work before marking it Active again. For an on-premises SAP RFC connection, that test involves the platform reaching the SAP Gateway host over the network. If the on-prem SAP server or the network path to it responds slowly or unreliably, that test can fail rather than eventually succeeding — even though the SAP server itself might have answered given more time. This shows up as the connection staying Inactive and reauthorization attempts failing right away rather than eventually succeeding.

Fix:

1. Check the network path between the platform and the on-prem SAP gateway — a firewall, VPN, or proxy that's intermittently slow or dropping traffic can cause exactly this symptom.

2. Confirm the SAP system itself is up and responding normally to other RFC traffic, not just to the platform.

3. Retry Reauthorize on the connection once connectivity looks stable.

4. If reauthorization keeps failing quickly for an on-prem SAP RFC connection even though the SAP system and network otherwise look healthy, contact support@unifyapps.com with details of the connection and the network path so the cause can be investigated for your environment.

How to verify: After reauthorizing, the connection's status should show Active, and automations that use it should run without connection errors. Check the connection's Activity tab to confirm no further unexpected drops to Inactive.

Key takeaway

An on-prem SAP RFC connection depends on the platform being able to reach your SAP gateway reliably during the reauthorization check. If your SAP server or network path is consistently slow or unreliable to respond, repeated Inactive/reauthorize-fails cycles are a sign to loop in support rather than keep retrying the same way — the underlying cause is likely in how your environment's network path behaves, not something changeable from the connection form.