Last updated on
Hun 30, 2026
Note
This document highlights the new features, experience changes, and resolved issues in the customer-facing application for the most recent release.
Developer-centric updates to the API and Webhooks are documented in the Acrobat Sign developer guide.
Not all features/changes are guaranteed to be enabled on the date of the release. Always refer to the US English version of the page as the most current and accurate version.
Adobe Acrobat Sign release v17.1.1
Production deployment: June 16, 2026
GovCloud deployment: June 18, 2026
Improved Functionality
- Recipient Filter in Reporting – Add recipient-based filtering to reports and data exports.
Add a Recipient filter to modern Reporting for Agreement and Transaction reports and Data Exports. Administrators can filter by recipient email to return all agreements that include the specified recipient, regardless of role or signing order. The filter supports autocomplete and multi-select behavior consistent with the existing Sender filter and applies to both visual reports and CSV exports.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: Enabled with Modern Reporting
Review the reporting overview >
Review the updated Create a Report document >
Review the updated documentation for Creating a Data Export >
Experience Changes
- Bio-Pharma (CFR) Support in Modern eSign – Adds signing reason capture and enforced sign-time reauthentication
Bio-Pharma signing settings, including signing reason capture and sign-time reauthentication, are now supported in the modern eSign experience. Agreements using these settings no longer fall back to the classic signing experience. No customer action or admin setting change is required.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: Support for Bio Pharma settings in Modern eSign is enabled by default.
Review the updated supported features list for Modern e-sign >
REST API/Webhook Updates
API and webhook updates for this release can be found in the Acrobat Sign API documentation.
- Suppress agreement notifications via API – Add granular control over recipient messaging
Using the REST v6 POST /agreements API, control which notifications are sent when creating agreements by suppressing specific email types for participants, CCs, or the sender. This reduces unnecessary emails and supports cleaner, more controlled signing experiences in integrated workflows.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: REST v6 API
Resolved Issues
| Issue | Description |
|---|---|
| 4545881 | Summary: Signers using Download and Sign in Acrobat could receive an "Adobe Acrobat Sign cannot recognize" error after uploading a digitally signed PDF when the Digital ID certificate did not include an expected signer name value, such as commonName, givenName, or pseudonym. The agreement could not be completed even though the signed PDF was uploaded. |
| Fix: Acrobat Sign now handles Digital ID certificates with missing signer name values without throwing an error during the upload validation process. Signing can complete successfully, though the signer name may not display if the certificate does not include one. | |
| 4547132 | Summary: When agreements were created through the POST /agreements API request and securityOption was set to null, external recipients could be assigned None as the authentication method even when account settings required Email OTP as the default authentication method. Internal recipient authentication was applied correctly, but external recipient authentication was not. |
| Fix: Acrobat Sign now correctly applies the account-configured default authentication method when API-created agreements include recipients with a null securityOption value. External recipients now receive the required default authentication method instead of None. | |
| 4553171 | Summary: In developer accounts using the new Create Template experience, reusable templates could show the [DEMO USE ONLY] prefix on the Manage page, but the prefix was not available when editing the template name. Users could not remove the prefix from the existing template name unless they replaced the full name or switched to the classic template experience. |
| Fix: The new Create Template experience now keeps the reusable template name and agreement name aligned for developer account watermark behavior. Users can edit the full template name, including the [DEMO USE ONLY] prefix, without switching to the classic experience | |
| 4556731 | Summary: After a sender replaced a recipient with themselves and then delegated the agreement to another recipient, the agreement returned to In progress, but the Upload Signed Document option remained unavailable. This prevented the sender from uploading a signed copy for eligible in-progress agreements after that delegation sequence. |
| Fix: Acrobat Sign now correctly restores the Upload Signed Document option after a recipient is replaced with the sender and then delegated to another recipient, when the agreement is eligible for signed document upload. | |
| 4557576 | Summary: When a signature block was assigned to a recipient group with multiple members, the email value in the signature block could be cut off instead of displaying clearly. This could make the recipient group information difficult to read before a group member completed signing. |
| Fix: Acrobat Sign now displays recipient group email information in signature blocks without abruptly cutting off the visible text. Long recipient group email values are handled so the displayed information remains readable within the signature block. | |
| 4561898 | Summary: Some recipients could encounter a server error after authentication or when finalizing signing for agreements that used specific PDF documents. The failure was caused by an issue handling PDF structure data during signed document generation, which prevented the signer from completing the agreement. |
| Fix: Acrobat Sign now handles PDF structure data more defensively during signing and document generation. The fix prevents structure tree conflicts from blocking completion, allowing recipients to authenticate, sign, and complete affected agreements successfully. | |
| 4562041 | Summary: Some webhook notifications could be delayed or fail to publish when Acrobat Sign received an internal server error while building the webhook payload. For the affected account, several events on March 19, 2026, were impacted, including AGREEMENT_WORKFLOW_COMPLETED and other agreement events, which delayed downstream customer workflows |
| Fix: Acrobat Sign now handles webhook payload generation failures more reliably so failed internal responses do not get cached in a way that blocks or delays event delivery. The fix was validated through regression testing and is intended to prevent affected webhook events from being delayed by the same payload-generation failure path. | |
| 4562458 | Summary: Recipients could receive an Invalid agreement ID specified error when opening a signing URL for agreements sent to inactive users on claimed account domains, when recipient authentication such as Email OTP or password authentication was used. The signing flow created a single-use pending user to continue the signing process, but the signing information request could read stale agreement data that did not include the newly created participation, blocking access until the signing link was regenerated or the data refreshed. |
| Fix: Acrobat Sign now retrieves current agreement participation data when opening authenticated signing URLs in this workflow. This prevents stale cached agreement data from causing invalid agreement ID errors and allows recipients to complete authentication and access the e-sign page successfully. | |
| 4566894 | Summary: Some expired agreements created from multiple templates could not be copied from the Manage page. When users selected Create a Copy, the copy operation failed with Unable to copy agreement. Please try again later because template access validation failed while copying agreements with more than one template. |
| Fix: Acrobat Sign now correctly validates template information when copying agreements that were created from multiple templates. Affected agreements can now be copied without triggering the backend session error. | |
| 4568666 | Summary: Webhook notifications could intermittently fail for agreements that included witness participants without an assigned user ID. The core agreement event was created, but webhook payload generation could fail when participant data was processed in an unpredictable order, causing some expected webhook events to not be delivered after AGREEMENT_CREATED. |
| Fix: Acrobat Sign now handles webhook participant data with missing user IDs safely during payload generation. This prevents witness placeholder participants from causing webhook payload failures and allows expected agreement webhook events to be delivered consistently. | |
| 4571682 | Summary: In some agreements where Power Automate modified recipient groups before a later form filler’s turn, read-only fields could fail to appear for the subsequent form filler. After the form filler completed their editable fields, those fields could also disappear from the agreement, even though the fields were still assigned correctly and marked visible through the API. |
| Fix: Acrobat Sign now preserves field visibility for subsequent recipient groups after recipient group membership changes. Read-only fields, signature blocks, dropdown selections, and other completed field values remain available for later recipients and in the downloaded PDF for the fixed scenarios. | |
| 4571845 | Summary: In-person signing can fail with a server error when the in-person signer email matches an existing user account on a different shard, preventing the agreement from being completed. |
| Fix: Updated in-person signer processing to correctly create and use a temporary signer record, preventing cross-shard user conflicts and allowing the signing session to complete successfully. | |
| 4573019 | Summary: Recipient group order can be calculated incorrectly after dynamic participant updates that remove a mix of recipients and recipient groups, causing the remaining group to display the wrong routing order. |
| Fix: Updated participant order recalculation so recipient groups retain the correct order after complex dynamic participant removals, including cases where a group is reduced to a single remaining member. | |
| 4572455 | Summary: Some signers could see an Unhandled Error or Something went wrong message after completing signing, even though the signature was applied and the agreement advanced to the next recipient. The issue occurred when dynamic participants were enabled and the signing flow tried to prepare the document for the next signer but could not find the expected signed document version. |
| Fix: Acrobat Sign now checks for the correct signed document version when preparing an agreement for the next signer. This prevents the signing flow from showing an error after a successful signature when dynamic participants are enabled. |
