Adobe Acrobat Sign rolls out at least three updates per year, categorized as major or minor releases. Additional minor updates may be introduced as needed to address system or customer issues.

Major Releases bring significant updates, new features, and multiple enhancements.
Minor Releases focus on smaller improvements and user experience tweaks. These occur between major updates, typically one to two times per cycle.

To prevent disruptions, new features are disabled by default and must be manually enabled by an account or group admin.

For Health and Life Sciences customers requiring compliance validation, Acrobat Sign partners with a third-party vendor to provide a validation package for every major release containing features to minimize your risk factor.

Note

This Prerelease Notes page is regularly updated as new information becomes available, so its content is relatively dynamic.

While this page is localized, the process takes time, which may result in localized versions differing slightly from the authoritative US English version.

For the most accurate and up-to-date information, we recommend referring only to the US English page.

The prerelease schedule and notes are listed below.

Adobe Acrobat Sign follows a structured schedule for publishing release notes and documentation updates:

8 Weeks Before Production Release

The prerelease page publishes a summary of expected features and updates, typically four weeks before the Sandbox launch.
Any feature changes after this point are noted in the Errata section.
Resolved issues are not included at this stage.

4 Weeks Before Production Release (Sandbox Launch)

The prerelease page is updated with detailed documentation on new and updated features.
Links to prerelease support documentation (available in US English only) are added as needed.
The initial Resolved issues section is published, with ongoing updates over the next four weeks.

Launch Day

The official release notes are updated with final feature details and links to production support documentation.
The prerelease page is refreshed to highlight the next release cycle.
Documentation is published after release verification in the live system, typically after 7 pm PT, though complex updates may take longer.
The final Resolved issues list is added to the US English release notes, with localized versions updated later.

Government Cloud Release

The Government Cloud environment typically updates between two days and several weeks after the production release, as some features may require additional evaluation before deployment.

Note

Sandbox documentation is designed for the production environment. Links found in the prerelease content target production URLs, meaning those links may lead to older existing documentation or 404 results if the target page is new and hasn't been published yet (e.g., when the link is pointing to a new feature in the same release).

The new pages will be published when the release is published, and links will properly resolve to their production URLs.

Sandbox availability

Customers accessing the Acrobat Sign Sandbox environment can typically access the new release functionality four weeks before launch.

The Sandbox environment must pass all production quality assurance procedures at the same quality level as the regular production environment.
Adobe strives to have 99.9% availability in the Sandbox environment, but customers should note that the Adobe Unified SLA does not formally cover the Sandbox.
The Sandbox environment uses the same status page and outage procedures as the regular Production environment.

Releases

Alert

This article contains prerelease information. Release dates, features, and other information are subject to change without notice.

June 16, 2026 (Minor release) v17.1.1

Adobe Acrobat Sign release v17.1.1

Sandbox deployment: May 12, 2026

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 >

Inline Document Editing During Authoring – Edit document text directly in the authoring experience
Senders can edit document text directly in the authoring environment without downloading and re-uploading the file. The Edit Document option preserves existing fields and agreement configuration, reducing disruption during pre-send updates. Editing is available only while the agreement is in a draft state and is not available after the agreement is sent.

This feature is enabled by default for all users in supported accounts, allowing senders to edit documents that are sent through Request Signature. Account and group admins can disable document editing through the Send Settings.

This feature is not available in Acrobat Sign for Government or for accounts using the legacy user management system.

Available environments: Sandbox, Commercial | Available tiers of service: Acrobat Sign Solutions | Configuration scope: Account and Group; Enabled by default
Enable or disable in-line document editing >
How to edit text during field authoring >

Bio-Pharma (CFR) Support in Modern eSign – Adds signing reason capture and enforced sign-time reauthentication
Adobe Acrobat Sign completes Bio-Pharma support in the Modern eSign experience by adding signing reason capture and enforced reauthentication during signing. Organizations operating in regulated environments can require a signing reason, enforce reauthentication for each signature or at final click-to-sign, and maintain compliant audit reporting — all within the Modern interface.

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 >

Experience Changes

REST API/Webhook Updates

The below updates are presented in the prerelease notes for disclosure purposes. Full documentation for API and Webhook updates can be found in the Acrobat Sign developer documentation when the version update is delivered to the production servers.

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

Release errata

There are no items that have slipped from this release as of this time.

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.
4545881	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.
4547132	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.
4553171	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
4554947	Summary: In the modern Compose experience, users could not remove incorrect or outdated email addresses from personal autocomplete suggestions when adding recipients, CCs, per-recipient CCs, or group members. The delete option was still available in the classic experience, but not all users could switch back to classic.
4554947	Fix: The modern Compose experience now lets users delete personal autocomplete suggestions from supported email fields, including recipient, CC, per-recipient CC, and group member fields. Organizational contacts cannot be deleted from autocomplete suggestions.
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.
4556731	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.
4557576	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.
4558445	Summary: Templates created in the classic experience could include radio button groups with only one option. When those templates were opened or reused in the new Create Template experience, validation blocked the workflow with the error A radio button group must contain more than one item, preventing users from saving or applying existing templates.
4558445	Fix: The new Create Template and authoring experiences now align with the classic experience for existing templates that contain single-option radio button groups. Validation was relaxed to preserve backward compatibility and allow affected templates to be opened, saved, and reused without blocking the workflow.
4559171	Summary: In the new Create Template experience, templates created from tagged PDFs could be saved before text tag processing completed. If users selected Create immediately after the preview loaded, the saved template could contain no converted form fields, even though the same workflow succeeded in the classic experience.
4559171	Fix: The new Create Template experience now prevents users from creating the template until text tag processing is complete. The Create button becomes available only after all fields and related details are fully loaded, ensuring text tags are converted and applied before the template is saved.
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.
4561898	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
4562041	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.
4562458	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.
4566894	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.
4568666	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.
4571682	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.
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.
4572455	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.