Shard Group
Pēdējo reizi atjaunināts
2025. gada 20. jūn.
Define a signature deadline that automatically cancels the agreement after a defined number of days.
The Completion deadline feature in Acrobat Sign allows senders to set a time limit for recipients to complete their signatures before the agreement is automatically canceled. This helps control signing deadlines, particularly for time-sensitive agreements, such as seasonal contracts or special offers. It also streamlines agreement management by removing old or unlikely-to-complete agreements from the In Progress list, making active agreements easier to track.
Availability:
- Acrobat Standard and Acrobat Pro: Not Supported
- Acrobat Sign Solutions: Supported; Disabled by default
- Acrobat Sign for Government: Supported; Disabled by default
Configuration scope:
The configurable options for this feature can be found here >
Piezīme.
The expiration date can be manually set for up to 180 days in the future.
Agreements that don't have an expiration date set automatically expire after 365 days.
The sender experience for Document Expiration will vary depending on if you are configuring a commercial Acrobat Sign Solutions account, or an Acrobat Sign for Government account.
Please select the tier of service you are using from the below options to review the configuration options in their respective environments:
If the Document Expiration feature is disabled, the option in the Agreement settings section of the Compose page will be locked down and uneditable. The note in the Agreement settings summary displays None.
If Document Expiration is enabled with only the default value option turned on, the Completion deadline option is visible on the Compose page in the Agreement settings section. The option displays the deadline date, set to whatever the admin has stored as the default length of time an agreement should remain signable. The date picker to select a new date is greyed out and locked, preventing the sender from editing it.
When the Document Expiration feature is enabled and the option to allow the sender to set the deadline is also turned on, the Completion deadline option is available and editable. The sender is free to enter any number of days (up to 180) that the agreement should remain viable for signature.
- If the option to set the default number of days is enabled, the default date on a new agreement will reflect that default value.
- If the option to set a default date is not enabled, the default expiration value will be 180 days from the sending date.
If the Document Expiration feature is disabled, the option on the Compose page will be absent.
If Document Expiration is enabled with only the default value option turned on, the Completion Deadline option is visible on the Compose page. The option shows as checked to show the deadline is configured, but greyed out, preventing editing by the sender.
When the Document Expiration feature is enabled and the option to allow the sender to set the deadline is also turned on, the Completion Deadline option is available and editable. The sender is free to enter any number of days (up to 180) that the agreement should remain viable for signature.
Expiration timing
Document expiration always occurs during off-peak hours based on the server that sent the agreement. Off-peak hours are 7 PM to 7 AM in the server's local time zone.
By default, agreements sent through the modern Request Signatures process are assigned an expiration time of 11:59 PM, though senders may be allowed to set custom expiration dates and times. However, agreements sent through the API, integrations, or legacy interfaces don't default to 11:59 PM; instead, they adopt the timestamp of when the agreement was initially sent.
If an agreement is set to expire during peak hours, it's queued for expiration but automatically delayed by 12 hours, ensuring the expiration event is processed during off-peak hours.
Status and Editing During Expiration Queuing
- While an agreement is queued for expiration, its status remains In Process on the Manage page and API responses.
- Recipients cannot sign a queued agreement and will receive an error message stating that the agreement cannot be signed.
- During the 12-hour queuing window, the sender can edit the Expiration Date on the Manage page to extend the deadline and allow recipients additional time to sign.
Non-peak hours are from 7 PM to 7 AM based on the most central time zone for the shard group from which the agreement was sent. The time zones used for each shard group are:
|
|
Time Zone for Peak Hours (7 AM - 7 PM) |
|---|---|
|
NA1, NA2, NA3, NA4 |
America/Chicago |
|
EU1, EU2 |
Europe/Berlin |
|
AU1 |
Australia/Sydney |
|
JP1 |
Asia/Tokyo |
|
IN1 |
Asia/Kolkata |
|
SG1 |
Asia/Singapore |
Piezīme.
Some shard groups include multiple shards that span multiple time zones. All shards in the group apply the same non-peak expiration window.
For example, the NA1, NA2, NA3, or NA4 all observe the same non-peak hours based on Central Time (GMT -6).
The agreement will expire as scheduled, typically within a few minutes of the set expiration time.
It refers to the shard where the agreement was sent, based on the sender’s environment. (Find out what shard you are on >)
The signer will not be able to sign after the expiration time, even if the agreement has not yet transitioned to EXPIRED status. They will see an error message:
If an agreement has been queued for expiration but the expiration has not yet been processed, the sender may still be able to edit the expiration date. This allows the recipient additional time to sign the agreement before it is expired.
Until the system processes the expiration (within 12 hours), the agreement remains in the IN_PROCESS state. It transitions to EXPIRED once the expiration event is processed.
Yes, you can edit the expiration time at any time until the expiration is processed. There are no restrictions on modifying the expiration time before the agreement transitions to EXPIRED status.
Yes, but the delay may vary by a few minutes depending on the system load.
When setting the expiration date/time on the Request Signatures page, it defaults to 11:59 PM, ensuring the expiration occurs during non-peak hours and is processed at that time or soon after. You can adjust this in the Agreement Settings section.
The agreement will continue to appear as In Progress until the expiration is processed, typically 12 hours later.
Data governance starts only after the agreement transitions to a terminal state (e.g., EXPIRED). A delayed expiration also delays the start of the retention period.
The expiration event is logged once the expiration is processed, which may be delayed by up to 12 hours if the expiration time falls within peak hours.
This update optimizes system performance to accommodate increasing demand.
