Last updated on
Mar 19, 2026
Adobe Acrobat Sign Release Notes: 2026
Adobe Acrobat Sign release v17.0
Production deployment: Febbruary 3, 2026
GovCloud deployment: February 10, 2026
Improved Functionality
- Grouped Checkboxes in Authoring and Templates – Senders can now create checkbox groups through the modern Request Signature and Library Templates, authoring environments with validation rules such as selecting exactly, at least, at most, or a range of X out of Y options. Send in Bulk, Web forms, and Custom Workflows are supported through the use of Library Templates. This enhancement ensures consistent form logic and improves data accuracy across signing workflows.
- Allowed IP ranges – Expanded control over API and mobile access - Administrators can now explicitly control whether IP restrictions apply to API-based clients, including Acrobat Sign mobile applications and certified integrations.
- Authentication support for modern e-Sign – Modern e-Sign now supports three authentication methods: Acrobat Sign authentication, password, and phone-based 2FA.
- Adding Recipient Groups in Hybrid Routing for modern Request Signature – Recipient groups can now be included in hybrid routing, allowing multiple recipients or groups to act in parallel within the same routing step. Group modes support either one or all members to complete the action, providing greater flexibility for complex approval and signing workflows.
- Copy terminal agreements sent from Request Signature—Senders can now create a new draft agreement by copying a previously completed, canceled, or expired agreement. All recipients, settings, files, and form fields are automatically prefilled. The copied agreement opens in the Compose page for quick edits before sending, reducing setup time, minimizing errors, and improving productivity for repetitive workflows such as renewals or corrections.
- Disable the Download agreement link for In-Progress Agreements – Administrators can now remove the “Download a copy” link from post-signing confirmation pages at the account or group level, preventing recipients from downloading agreements from the post sign page.
- Resources Tab in Top Navigation – A new Resources page is available in the top navigation for admins and users, providing direct access to Acrobat Sign educational content, webinars, blogs, and product update videos. The page organizes tutorials by user level—beginner, experienced, and administrator—and links directly to additional support documentation.
- Dynamic Participation for In-Flight Agreements – Remove Recipients – Senders can now remove recipients from agreements that are already in progress without canceling or restarting the transaction. When a recipient is removed, Acrobat Sign automatically revokes their access, updates reminders, audit trails, removes the assigned fields, and transitions the agreement seamlessly back to its active signing state. This flexibility helps organizations maintain accuracy in live routing workflows—such as when a signer becomes unavailable—while preserving legal integrity, compliance, and a complete audit history.
- Require digital signatures for individual recipients during agreement configuration - Senders can now require digital signatures for selected recipients, ensuring stricter signing requirements where needed without impacting other recipients. The signing experience adapts automatically, enforcing required digital signature fields and exposing identity checks when supported, reducing errors and improving compliance for regulated workflows.
- Digital Identity Providers as Default Authentication Methods – Administrators can now select a Digital Identity Gateway provider as the default signer authentication method for internal and external recipients in Send Settings. The configuration applies automatically to agreements, web forms, bulk sends, and workflows, ensuring consistent and compliant recipient verification. This enhancement simplifies authentication setup, enforces organizational identity policies, and improves support for government and enterprise customers that rely on Digital Identity-based authentication.
- Verified Form Fields Using Identity-Verified Data – Form authors can now create verified form fields that automatically populate with data returned by an identity provider (such as OneID) during signer authentication. These fields can be set as read-only or editable, ensuring verified identity data is accurately captured and optionally locked against edits (e.g., name, address, or account number). This strengthens identity assurance, reduces manual entry errors, and streamlines compliance for workflows that require validated signer data.
- Recipient Groups in CSV File for Send in Bulk – Senders can now define recipient groups directly within the Send in Bulk CSV file, enabling multiple recipients to act at the same routing step. Each group can be configured in ONE or ALL mode—requiring either one member or all members to complete their action before routing advances. Group definitions, validation, and audit tracking are all handled per CSV row, with errors reported through downloadable validation files.
- Library Template – Share with Multiple Groups – The modern Create Library Template experience now supports sharing templates with multiple groups within an account, matching the functionality previously available in the classic workflow. Users can select one or more groups when creating or editing a template, ensuring consistent behavior across groups. This enhancement eliminates fallback to the classic experience, improves collaboration, and simplifies template management for multi-group organizations.
- File Attachments for all recipients using digital signatures – All recipients in a digitally signed workflow can now attach files (not just the first signer). A new attachment method using Paperclip annotations displays a visible paperclip icon in the document and remains compatible with multiple digital signatures. Each attachment is added before the signer’s digital signature is applied, preserving signature validity and providing a clear visual indicator of attached files. This enhancement improves legal integrity, transparency, and consistency across e-signature and digital-signature workflows.
Experience Changes
- Workflow agreement cancellation notifications – Cancellation notification updated to reflect the workflow behavior.
When cancelling a workflow-created agreement, the “Notify recipients” checkbox no longer appears. Notifications are always sent based on the workflow’s settings. This change adjusts the message to reflect this behavior in the cancellation challenge.
- Login Page Improvements - The Acrobat Sign login page now offers a cleaner and more consistent experience. As soon as you enter your email address, the page automatically detects your account type and sends you to the right sign-in method, removing unnecessary steps and legacy screens. This makes logging in faster, simpler, and more intuitive for everyone.
- New email format for Acrobat Sign enterprise users who log directly into the web interface - Acrobat Sign now enforces a 64-character limit to the local part of an email address (the portion before the “@” symbol) when editing an existing email, or creating a new user.
All users with a local part over 64 characters have been evaluated and determined to be inactive or test userIDs.
- New email format for Acrobat Sign enterprise users who log directly into the web interface - Acrobat Sign now enforces a 64-character limit to the local part of an email address (the portion before the “@” symbol) when editing an existing email, or creating a new user.
Note that this experience is delivered through a rolling release based on the Acrobat Sign server environment. The rollout schedule is published in the Updated Login experience Technical Notification.
- Enable Management of User Details for Inactive Users – Administrators can now edit user details for inactive users directly in the Admin UI and through CSV uploads without reactivating accounts. This includes updating group assignments (for both single and multi-group configurations), managing the “User can sign documents” attribute, and performing bulk edits for compliance and record maintenance. The change streamlines enterprise user lifecycle management, reduces administrative overhead, and supports cleaner group organization and GDPR-aligned record handling.
Resolved Issues
| Issue | Description |
|---|---|
| 4528600 | Summary: Field validation settings do not work when a form field layer is attached to a custom workflow. Validation rules, such as regex or numeric range limits, are removed when the workflow is started, causing fields to accept invalid input. |
| Fix: Validation rules now apply correctly when form field layers are included in custom workflows. Fields retain their validation behavior across both classic and new authoring experiences. No action is required from users. | |
| 4528748 | Summary: Admins intermittently see an “Unhandled error” when adding group membership to newly synced users (Azure sync). Some new users in the group have the groupID set as null |
| Fix: If a user's group is null after creation, they are placed in the account's Default group. | |
| 4529934 | Summary: In Manage > Web Forms, “Download Form Field Data” keeps loading and never finishes—especially on web forms with many submissions. Teams customers without API access can’t export data (e.g., May 1–31) for reporting |
| Fix: Added paginated, faster CSV export in the UI. Form data downloads complete reliably for selected date ranges, without hanging. | |
| 4532186 | Summary: In the new authoring experience, field color highlighting does not match the behavior of Classic Authoring. When multiple recipients are involved, all fields remain fully colored rather than dimming non-selected recipients’ fields. This makes it difficult to verify field assignments. |
| Fix: Restored visual clarity by dimming (20% opacity) fields that belong to non-selected recipients. This replicates the clarity of Classic Authoring while preserving the modern design system. Highlighting now helps users easily identify the currently selected recipient’s fields and reduces the risk of misassignment. | |
| 4534061 | Summary: The "Download a copy" link appears on the post-sign confirmation page even when the account or group setting is configured to disable it. |
| Fix: A new setting has been added to explicitly suppress the Download option for all post-send pages. The post-sign page now correctly respects the download control setting, hiding the "Download a copy" link when the setting is disabled. | |
| 4536347 | Summary: In Classic Experience, senders could not add a second file (or retry adding a file) when starting certain workflows, blocking multi-document workflow sends, due to an error in how the file picker handled templates shared across multiple groups. |
| Fix: Corrected the file picker’s handling of templates shared across multiple groups so users can add additional files or retry file selection in Classic Experience without errors. | |
| 4537504 | Summary: A conditional dropdown value was missing from the signed document even though it was correctly selected during signing, due to the visibility logic evaluating against a hidden dependent field and not persisting the rendered value into the final signed PDF. |
| Fix: Updated conditional field rendering to correctly resolve visibility dependencies at signing time and persist the selected dropdown value into the signed document when conditions are met. | |
| 4537995 | Summary: In recipient groups, changing the authentication method for external users reverted to Phone after saving, preventing Email OTP from being applied, due to a front-end state handling error that overwrote the user’s selection. |
| Fix: Corrected the recipient group UI logic to properly persist and reapply the selected authentication method across save actions, ensuring the chosen value is retained instead of being reset to the default. | |
| 4539214 | Summary: In custom workflows, a long message label causes the message text to overlap and obscure the message template hyperlink on the Send page, due to improper layout handling of excessive label content. |
| Fix: Updated the Send page layout logic to correctly constrain and wrap long message labels so the message template hyperlink remains visible and accessible. | |
| 4539854 | Summary: Some signers are redirected away from the signing experience when opening certain agreements, due to a malformed link field in the underlying document that lacks a required name attribute. |
| Fix: The signing flow now handles unnamed link fields correctly by assigning a valid name at processing time, preventing errors and allowing signers to complete agreements without redirection. | |
| 4539858 | Summary: On iOS devices, approvers using the Chinese handwriting keyboard cannot complete approval because the Approve button remains disabled after entering their name, due to the signing page not detecting handwriting input events as valid text entry. |
| Fix: Updated the input handling logic to recognize handwriting-based text input on iOS, ensuring the Approve button enables correctly once valid characters are entered. | |
| 4540392 | Summary: Admins intermittently see HTTP 400 errors and recipient groups appear missing in workflows even though the groups exist and access is correctly configured, due to request headers exceeding the platform’s header size limit when users belong to a large number of groups. |
| Fix: The server-side request header size limit was increased so recipient group lookups no longer fail when users have many group memberships. | |
| 4541258 | Summary: Admins could only see the first 100 templates in the Production or Sandbox Sync UI, with additional templates missing from the Local and Remote lists, due to the sync page loading a limited dataset and the search function filtering only templates already loaded in the browser. |
| Fix: The sync UI was updated so that entering text in the search field loads all templates for the selected environment (up to 5,000), ensuring templates beyond the initial 100 are available for search and selection | |
| 4541739 | Summary: Replaced recipients were blocked from digitally signing and saw “The agreement cannot be digitally signed since it is not in the digital sign phase,” due to the workflow failing to transition future replaced signers into the digital signing phase when digital signature fields were present. |
| Fix: The signing workflow was updated to correctly transition replaced or delegated recipients into the digital signing phase when digital signature fields exist, allowing them to sign and complete the agreement. | |
| 4541849 | Summary: Single-line auto-font-size text fields prefilled with multibyte characters were truncated in signed PDFs, causing part of the text to be cut off due to incorrect text sizing during PDF rendering. |
| Fix: Corrected text measurement and auto-font-size behavior for multibyte characters so the full value fits within the field without truncation. | |
| 4542574 | Summary: Editing a library template allowed required dropdown fields to include unpaired values, causing the Click to sign button to remain unavailable during signing when those values were selected, due to missing validation that ensured dropdown display values and export values remained correctly paired. |
| Fix: Template editing now enforces validation on dropdown fields so only properly paired values can be saved, preventing unpaired entries and ensuring required dropdown selections do not block signing. | |
| 4542942 | Summary: In webforms, required fields disabled by conditional logic continued to display the required asterisk, misleading signers into thinking input was still required, due to the UI not updating required indicators when fields were disabled. A separate mobile signature alignment issue was identified but addressed under a different scope. |
| Fix: The webform UI now hides the required asterisk when a field is disabled by conditional logic, ensuring required indicators accurately reflect whether signer input is expected. | |
| 4543157 | Summary: In the Manage page’s In Progress view, the Recipients column continued to show the delegator’s name after a signing role was delegated, even though a different signer was actively signing, due to the UI not updating the displayed recipient to reflect the current delegatee. |
| Fix: The Manage page logic was updated so the Recipients column now displays the active delegatee’s name when a signing role is delegated, ensuring the In Progress view accurately reflects who is currently signing. | |
| 4543253 | Summary: In the Classic Workflow Experience, witness-assigned fields (signature, name, date) disappeared after saving an agreement in Draft state, even though the fields existed on the backend, due to the draft rendering logic failing to restore witness fields when progress was saved. |
| Fix: The draft rendering logic was corrected to preserve and display all witness-assigned fields after saving progress, ensuring agreements opened in Draft state retain the same field visibility as during authoring and signing. | |
| 4543513 | Summary: Users were blocked from sending agreements in the Sign Web UI with the error “Locale is either invalid or missing,” due to locale validation incorrectly enforcing API-level locale rules in the web interface when the sending group’s locale differed from the user’s inherited primary group locale. |
| Fix: Locale validation was corrected so the Sign Web UI properly resolves and accepts valid group and user locale combinations, preventing API-only locale restrictions from blocking agreement sending in the web experience. | |
| 4543592 | Summary: Some Audit Reports showed “Recipient authenticated with Adobe Acrobat Sign” after “Document e-signed” and “Agreement completed,” due to events being stored with second-level timestamps, causing authentication and signing actions occurring in the same second to appear out of order. |
| Fix: Audit event logging was updated to store and display timestamps with millisecond precision, ensuring authentication, signing, and completion events are sequenced correctly in the Audit Report. | |
| 4543617 | Summary: Creating a template from an agreement launches the Classic experience instead of the New experience, despite the New experience being the default, due to the action still being routed to the legacy authoring flow. |
| Fix: The “create template from agreement” action was updated to open in the New experience, aligning the CTA behavior with the default UX and avoiding unexpected context switches for users. | |
| 4544564 | Summary: Hidden fields added or updated via the API (visible:false) rendered as visible in the Modern eSign experience. The signing UI ignored the field visibility flag, so recipients could see fields that should stay hidden. |
| Fix: Updated the Modern eSign UI to filter out fields where visible is false across rendering and navigation logic, so hidden fields never display and do not affect page behavior. | |
| 4544571 | Summary: The WhatsApp delivery option was missing from Send Settings even though WhatsApp was enabled for the account and available during agreement sending, causing inconsistent behavior and confusion for administrators. |
| Fix: The WhatsApp delivery option was restored in Send Settings wherever the feature is available, ensuring consistent visibility and configuration between admin settings and the send agreement experience. | |
| 4545381 | Summary: The Roboto font was missing from the New Request Signature Experience, even though it was available in the Classic Experience, due to the new authoring experience not including all legacy-supported fonts. |
| Fix: Roboto was added to the font list in the New Request Signature Experience, restoring font parity with the Classic Experience and allowing consistent formatting when authoring agreements. | |
| 4545484 | Summary: Some administrators were unable to access or create recipient groups from Admin > Address Book due to a backend request failure, resulting in a 400 error when loading recipient group data. The issue blocked initial setup of recipient groups for affected admins. |
| Fix: The backend request handling was corrected so recipient group search and creation no longer fails with a 400 error. Admins can now reliably access and manage recipient groups regardless of network or location. | |
| 4545547 | Summary: Agreements created from AutoCAD PDFs failed to send when a digital signature field was added, showing a generic send error, due to the system not correctly handling page rotation when validating digital signature field placement. |
| Fix: Digital signature field coordinates are now adjusted to account for rotated pages, ensuring fields are validated against the correct page boundaries so AutoCAD-generated PDFs can be sent successfully with digital signatures. | |
| 4545894 | Summary: When a recipient group is used and no signature field is manually placed, the auto-generated signature block shows the email address text at a very small size. The text becomes progressively smaller as more recipients are added to the group. |
| Fix: The auto-generated signature block now correctly renders the email address at a normal, readable size, regardless of how many recipients are included in the recipient group. | |
| 4546085 | Summary: When using Add Myself in the New Request Signature experience, email addresses containing an apostrophe are displayed incorrectly. The malformed address prevents the agreement from being sent unless the email is manually re-entered or Classic Send is used. |
| Fix: Email addresses with apostrophes are now correctly decoded and displayed when Add Myself is selected in the New Request Signature experience, allowing agreements to be sent without manual correction. | |
| 4546110 | Summary: In the New Template authoring experience, adding a Hyperlink field assigned to a specific participant causes the template save to fail. The same field works when assigned to all participants or when using the Classic experience. |
| Fix: Hyperlink fields now support placeholder participant assignments in the New Template experience, allowing templates to save correctly when the field is assigned to a specific participant. | |
| 4546257 | Summary: In the Sandbox environment, agreements sent through a custom application API incorrectly show a Back button on the authoring page due to Sandbox loading settings from an Adobe-managed application with seamless authoring enabled, unlike Swagger or Production. |
| Fix: Sandbox behavior was aligned with Production and Swagger by ensuring the authoring page respects the intended application settings, preventing the Back button from appearing for agreements sent via custom application APIs. | |
| 4546547 | Summary: Web forms failed to update the counter signer and returned a miscellaneous error due to older user records missing a required internal flag, which caused a null value to be processed during counter signer replacement. |
| Fix: The counter signer update logic was hardened with null-safe handling so web forms can successfully replace counter signers even when older user records lack the expected internal flag. | |
| 4546553 | Summary: Users assigned to multiple groups could create templates in a group where template creation is disabled when the New Create Template experience is enabled. This allowed bypassing group-level restrictions. |
| Fix: Template creation now enforces group-level permissions consistently across the new and classic experiences. Users can no longer create templates in groups where template creation is disabled, even if they belong to other groups with that permission enabled. | |
| 4547744 | Summary: Group Admins could assign Account Admin rights to users through the new User Management page. This exceeded their permission scope and created a compliance risk by allowing elevation of privileges beyond the Group Admin role. |
| Fix: The role selection control is no longer available to Group Admins. Only existing Account Admins can assign or revoke Account Admin rights, ensuring role changes align with permission boundaries. | |
| 4547796 | Summary: Some senders using the Polish UI occasionally receive a confirmation email with incorrect "cannot provide a digital signature" text, even though the agreement sends and signs normally. |
| Fix: Corrected Polish translations for sender confirmation emails so the message shows "sent for signature" instead of the incorrect "cannot provide a digital signature" text. | |
| 4548315 | Summary: When the sender is included as a CC recipient in the new Send Workflow, no validation error is shown and CC email notifications are not sent to any recipients listed after the sender in the CC list. This differs from Classic Workflow behavior and can cause CC recipients to miss notifications. |
| Fix: Updated the new Send Workflow logic so that all CC recipients, excluding the sender, receive CC email notifications regardless of their position in the CC list, aligning behavior with expected outcomes. | |
| 4548583 | Summary: PDF/A could not be enabled for a group if the user’s default group had written signatures enabled, even when written signatures were disabled for the group being edited. This blocked valid PDF/A configuration for non default groups. |
| Fix: Updated the validation to check written signature settings on the group being modified, not the user’s default group, allowing PDF/A to be enabled correctly where permitted. | |
| 4549337 | Summary: SMS notifications for cancelled agreements were suppressed when the Email Agreement Cancelled setting was disabled. This prevented customers who disable email notifications from sending required SMS cancellation alerts. |
| Fix: Decoupled SMS and WhatsApp cancellation notifications from the email setting by introducing a dedicated notification control, allowing SMS delivery for cancelled agreements even when email notifications are disabled. | |
| 4549472 | Summary: In Acrobat Sign for Government, users could not create reusable templates using the new Create Template experience. After uploading a document, the workflow stalled on a blank screen, blocking template creation. |
| Fix: Restored the missing authoring dependency required by the new Create Template experience in Gov environments, allowing the authoring screen to load correctly and templates to be created successfully. | |
| 4549862 | Summary: When the landing page is set to the New Request Signature experience, the configured login warning message does not display after sign-in. This prevents organizations from showing critical maintenance or disruption notices when users land directly on the Send page. |
| Fix: Restored support for displaying the login warning message in the New Request Signature experience. When users land on the Send page after login, the configured warning message now appears as a notification, matching prior behavior and customer expectations. | |
| 4550175 | Summary: Pressing Enter after entering a phone number for phone authentication in a workflow submits the form prematurely and triggers a system error, interrupting the workflow flow due to the form being submitted instead of waiting for explicit confirmation. |
| Fix: Updated the recipient dialog to prevent form submission on Enter for phone authentication fields, ensuring users remain on the dialog and must click Continue, eliminating the unintended workflow interruption. | |
| 4550302 | Summary: German signature requested and reminder emails used inconsistent forms of address, switching between informal “Du” and formal “Sie” within the same message, causing confusing and unprofessional wording. |
| Fix: Updated the German email translations to use a single, consistent form of address throughout the template, ensuring uniform and predictable language in all signature requested and reminder emails. | |
| 4550556 | Summary: Agreements containing large architectural plan PDFs failed to send when digital signature fields were added, returning an error during authoring due to page rotation and size handling in digital signature placement. |
| Fix: Updated digital signature field processing to correctly handle rotated, large-format pages, allowing agreements with architectural plans to send successfully with digital signatures applied. | |
| 4550579 | Summary: When an agreement was completed by removing the last remaining recipients during an in-revision state, the system did not generate the AGREEMENT_WORKFLOW_COMPLETED event, so no webhook notification was sent, breaking workflows that rely on this event to detect completion. |
| Fix: Updated event handling so agreements completed via recipient removal in revision now generate the appropriate completion events, ensuring AGREEMENT_WORKFLOW_COMPLETED webhooks are triggered as expected. | |
| 4550998 | Summary: Prefilled checkboxes appeared checked in authoring but were unchecked for signers because checkbox values were stored as non-empty text strings instead of explicit YES/NO states, causing the signing experience to treat them as unchecked. |
| Fix: Updated checkbox value handling so any non-empty prefilled value is interpreted as checked and empty or missing values as unchecked, ensuring checkbox states remain consistent for signers. |
Adobe Acrobat Sign release v17.0.1
Production deployment: March 17, 2026
GovCloud deployment: March 19, 2026
Improved Functionality
- Create a copy – Expanded access points, faster reuse of agreements.
Create a copy is now available directly from the In progress and Waiting for you filters on the Manage page, as well as from the post-send confirmation page. These additional entry points make it easier to reuse agreements at more points in the sending lifecycle, reducing the need to restart from scratch.
Note: With this release, the administrative controls to disable this feature will be removed from the admin menu, establishing Create a copy as a standard capability available to all eligible users.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: Account and Group; Enabled by default.
Experience Changes
- Integration key expiration visibility – Expiration dates now shown on the Access Tokens tab
The Access Tokens tab, in the Personal Preferences menu, displays the expiration date for each integration key. This gives users and administrators clearer visibility into key age and replacement timing, making it easier to monitor existing keys and avoid unexpected interruptions when a key reaches the end of its 10-year validity period.
Available environments: Sandbox, Commercial, Government | Available tiers of service:Acrobat Sign Solutions | Configuration scope: API
REST API/Webhook Updates
API and webhook updates for this release can be found in the Acrobat Sign API documentation.
- OEM 2.0 personalized email display – Clearer sender and recipient identity across embedded experiences, and correct email delivery.
For OEM 2.0 Partners using embedded workflows, Acrobat Sign can now display a user’s personalized email address instead of the partner-registered email across key UI surfaces and notifications. Agreements, queues such as “Waiting for you,” and “Review and Sign” emails consistently reflect the personalized identity while preserving the registered email internally for authentication and entitlements. This improves clarity for senders and signers and prevents emails from being sent to non-deliverable registered addresses.
Available environments: Sandbox, Commercial | Available tiers of service: Acrobat Sign Solutions | Configuration scope: API - OEM 2.0 Partners; by request only
- Webhook notification for SMS delivery failures – Real-time visibility into failed SMS sends, automated remediation, and parity with email bounces.
Acrobat Sign now emits a new webhook event, AGREEMENT_PHONE_BOUNCED, when an agreement sent via SMS cannot be delivered due to issues such as invalid phone numbers, carrier rejection, or blocked lines. This enables customers to detect SMS delivery failures in near real time and automatically trigger follow-up actions like correcting phone numbers, retrying delivery, or opening support cases, eliminating blind spots and reducing delays in mobile-first signing workflows.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: API
- Webhook payloads – Added conditional participant extendedStatus field for dynamic participation updates, improving participant state visibility.
Webhook notifications now include an extendedStatus field in each participant (memberInfos[]) object when the sender modifies an in-flight agreement using dynamic participation. This field provides additional participant lifecycle detail while leaving the existing status field unchanged for backward compatibility.
{
"participantSets": [
{
"id": "",
"memberInfos": [
{
"company": "TestCo",
"email": "signer2@someDomain.dom",
"id": "CBJCHBCAABAAJiZV9cH",
"name": "Signer Two",
"status": "ACTIVE",
"extendedStatus": "REMOVED"
}
],
"order": ,
"role": "",
"status": ""
}
]
}
status values (unchanged): ACTIVE, REPLACED.
extendedStatus values: ACTIVE, REPLACED, REMOVED, COMPLETED.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: API
Resolved Issues
| Issue | Description |
|---|---|
| 4543515 | Summary: A webhook email bounce event may be incorrectly generated for a valid signer after the signer successfully signs and the agreement advances to the next step. This can occur when a delegatee in the same signing group has an invalid email address and the sender replaces the original delegator. In these cases, the system may incorrectly attribute the “signed on behalf of…” bounce event to the valid signer instead of the participant whose email actually bounces. |
| Fix: The event attribution logic was corrected so email bounce events are associated only with the participant whose email actually bounces. A bounce event is no longer generated for a valid signer who has already completed signing, and webhook notifications now reflect the correct participant and email address. | |
| 4544548 | Summary: Integration Keys created through the Web UI may expire after 10 years, even though the creation page states that the key provides “permanent access.” When a key reaches its 10-year lifetime, API calls begin returning an expired token error, which may break existing integrations unexpectedly. |
| Fix: The user interface messaging was updated to remove the “permanent access” wording and clearly display the expiration date for Integration Keys. The updated text now states that the key retains access until the expiration date or until it is manually revoked, providing transparency about the 10-year default lifetime. | |
| 4546301 | Summary: Webhook event delivery may be delayed by up to multiple hours for agreements with very large documents, even when agreement creation completes and early processing steps appear to finish within minutes. During the delay window, the webhook delivery service may repeatedly receive DOCUMENT_NOT_AVAILABLE responses when attempting to retrieve agreement documents, and the webhook event may not be delivered until the service stops retrying or the documents become available. |
| Fix: Document availability handling was corrected so large agreements reliably transition to a state where documents are retrievable without extended DOCUMENT_NOT_AVAILABLE responses. As a result, webhook events are delivered without multi-hour delays caused by document retrieval retries against unavailable documents. | |
| 4547823 | Summary: A recipient's private message may not display for some signers when an agreement is created in the Authoring state through the API and then edited from the Manage experience. In this scenario, the UI may show the Private Message value as “None” or blank even though the agreement data includes the correct private message value. This behavior appears in shared-account scenarios where a user switches into another user’s account to edit the draft, and it may affect only specific recipients while others display correctly. |
| Fix: A check was added to retrieve the active share context and return the private message for authorized shared users. As a result, the Private Message value now displays correctly when viewing or sending an API-created draft from the Authoring flow. | |
| 4548274 | Summary: The Modified Date for library templates may not update after a template is edited and saved in the new template experience. Users may see newly added or updated fields on the template, but the Modified Date remains unchanged in the Manage UI and in administrative views, which makes it appear that the template was not recently modified. This occurs because the new experience updates form fields through a path that does not also update the template’s modified timestamp. |
| Fix: The modified date update behavior was aligned across the new template experience and the related API operations. The code path that saves template field changes now also updates the template’s Modified Date so it reflects the actual time of the most recent change. | |
| 4548564 | Summary: Signatures and form fields may appear invisible in the signed PDF when they are placed over pre-existing stamp annotations in the source document. In affected templates, the stamp annotations overlap or obscure the interactive fields during processing, causing completed signatures and other fields to be hidden in the final signed document. |
| Fix: Stamp annotation handling was updated to safely process and flatten pre-existing stamp annotations so they no longer obscure form fields or signatures. Fields placed over stamped areas now remain visible throughout signing and in the fully executed PDF. | |
| 4549103 | Summary: An email bounce event may be logged again for a previously incorrect recipient after the sender replaces that recipient with a valid email address. In some cases, the audit trail may show a second bounce event for the old email, and the agreement status may reflect “email bounced” even though the new recipient successfully receives, views, or signs the agreement. This behavior can make it appear that the agreement is still targeting both the old and new email addresses. |
| Fix: The replace signer workflow was updated to prevent sending additional notification emails to a replaced recipient whose email has already bounced. The system now checks for prior bounce history before sending replacement-related notifications, ensuring that no new bounce events are generated for the old email address after replacement. | |
| 4549306 | Summary: Users whose email addresses contain certain special characters (for example, an apostrophe) may be unable to log in from the generic adobesign.com or echosign.com public login pages. After entering the email address and clicking into the password field, the page may reload and clear the email field instead of redirecting the user to the correct shard or SSO login page. This prevents affected users from completing authentication and blocks integrations that rely on the public login endpoint. |
| Fix: The login shard resolution logic was corrected to properly handle and decode email addresses containing special characters before constructing the inter-shard redirect URL. Users with affected email formats are now correctly redirected to their designated shard and SSO login page without the email field being cleared. | |
| 4549331 | Summary: Signatures and other form fields may appear missing or invisible in the signed PDF when certain document processing features are enabled and the source PDF contains invalid page box coordinates (for example, incorrect CropBox or MediaBox values). In this scenario, fields that rely on page coordinates may render outside the visible page area, making completed signatures appear missing even though signing completes successfully. |
| Fix: PDF page box handling was corrected to safely normalize invalid CropBox and MediaBox values during document processing. As a result, signature and form field placement now aligns to the visible page area, and signed PDFs display signatures as expected. | |
| 4550367 | Summary: Creating a web form may fail with a generic “Server error” after selecting Preview and Add Fields when the sender’s group default signer authentication is set to Phone and the account does not have available phone authentication quota, even if the web form signer authentication is set to a non-phone method (for example, Adobe Sign). As a result, all users in the affected account may be blocked from creating web forms across all documents. |
| Fix: Web form creation now evaluates quota only for the authentication method actually configured for the web form signer, and it no longer applies phone authentication quota checks based solely on the group default authentication setting. This prevents false quota exhaustion errors and allows web forms to be created normally. | |
| 4551011 | Summary: When a sender uploads certain scanned PDFs, adds signature fields, and sends the agreement, the signed PDF may display no visible signatures after signing completes. This behavior may occur when the uploaded PDF contains invalid page boundary metadata (MediaBox and CropBox coordinates appear reversed), which can cause signature and other field appearance layers to render outside the visible page area. |
| Fix: PDF page boundary handling is updated to correctly process PDFs with invalid or reversed MediaBox and CropBox coordinate values, so signature and form field appearance content renders within the visible page area and remains visible in the final signed PDF. | |
| 4551427 | Summary: Some recipients who already have active, correctly provisioned accounts receive agreements as “pseudo user” recipients instead, so the agreement does not appear in their normal Manage view. This happens when recipient email addresses include leading or trailing spaces, which prevents the system from matching the email to the existing user and causes a pseudo-user record to be created. |
| Fix: Email parsing and user lookup were updated to normalize recipient email addresses (trim leading and trailing whitespace) before matching them to existing users. As a result, agreements addressed to existing users resolve to the registered account instead of creating a pseudo-user recipient, even if the email was entered with spaces (in API payloads and workflow recipient lists). | |
| 4553198 | Summary: When an agreement includes at least one recipient configured for SMS delivery and at least one recipient configured for email-only delivery, canceling the agreement through the API does not send an SMS cancellation notification to the SMS recipient. The agreement is successfully cancelled, and email notifications are delivered, but SMS recipients do not receive a cancellation message. |
| Fix: The cancellation workflow was corrected to ensure that SMS cancellation notifications are sent to all recipients configured for SMS delivery when an agreement is cancelled, regardless of other recipients’ delivery methods. | |
| 4554463 | Summary: When agreements include cloned radio buttons that share the same field name across combined documents, only one instance of the selected option remains selected in the final signed PDF. Although the fields appear visually as checkboxes, they are implemented as radio buttons. After signing, the selected value does not consistently propagate across all cloned instances, causing incorrect or incomplete mapping of the expected selection. |
| Fix: The form field handling logic was corrected so that cloned radio buttons store and propagate the selected export value rather than an internal index value. This ensures that all cloned instances of the same radio button field reflect the correct selection in the signed PDF. | |
| 4554593 | Summary: Some partner integrations that use the legacy OAuth endpoints to refresh access tokens started failing with HTTP 401 errors. The service rejected token refresh requests with an error indicating that the application is not allowed to use the legacy OAuth endpoints and must use the OAuth v2 endpoints instead. This blocked customers from authenticating Acrobat Sign through partner applications, even for integrations that were previously working. |
| Fix: The authentication service was corrected so partner applications that are configured to use the legacy OAuth flow can successfully refresh tokens again, instead of being incorrectly forced onto the OAuth v2 endpoints. | |
| 4554614 | Summary: When a signer uses the modern eSign experience on an agreement that requires signer authentication and is configured to require acceptance of terms of use before signing, clicking Click to Sign triggers a 5-second redirect to the classic signing experience. The redirect message warns that signatures and initials entered in modern signing will be cleared, forcing the signer to re-enter them and effectively sign twice. |
| Fix: The signing token refresh flow was corrected so that when the signer accepts the terms of use before signing, the reissued signing token retains the signer authentication details. This prevents the final signing step from failing authentication and eliminates the forced fallback from modern signing to the classic experience. | |
| 4555656 | Summary: Under specific timing conditions, an agreement state transition may appear to succeed but does not actually change the agreement state. When a webhook notification is received before backend processing completes, subsequent API calls can use stale agreement status data. In this window, certain state transition methods return HTTP 200 OK even though the agreement is not in a valid state for the requested transition. As a result, automation workflows may assume the transition succeeded while the agreement remains in the original state. |
| Fix: Agreement state transition logic was updated to enforce strict validation before applying a transition. If the agreement is not in a valid state, the API now returns a clear error response instead of silently returning success. This ensures invalid transitions are explicitly rejected, enables calling systems to retry appropriately, and prevents agreements from remaining in an unintended state without visibility. |
Improved Functionality
Experience Changes
REST API/Webhook Updates
API and webhook updates for this release can be found in the Acrobat Sign API documentation.
