Shard Group
Ultima actualizare la
22 apr. 2025
Allow senders to specify an expiration date to automatically cancel an agreement after a set time.
The Expiration Date 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.
Senders can set expiration dates up to 180 days from when an agreement is sent. By default, agreements are scheduled to expire at 11:59 PM local server time, but senders can modify this setting. To optimize system performance, agreements always expire during off-peak hours for their assigned server group. If an expiration is set during peak hours, the system automatically adds 12 hours, ensuring expiration occurs during non-peak times.
Notă:
If no expiration date is manually set, agreements automatically expire after 365 days in an In Progress status, ensuring long-standing agreements don't remain indefinitely open.
All expiration times are based on the server group's time zone (see the FAQ at the bottom of the page).
Configuration
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:
Administrators can enable this feature at the account and group levels.
Access this feature by navigating the administrator's configuration menu to Send Settings > Document Expiration
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:
When Document Expiration is enabled, either Allow senders to set or modify expiration settings per document or Limit number of days signers will have to sign documents to must also be selected.
This makes the Completion Deadline value in the Agreement settings available.
If the setting is disabled, the Completion Deadline option is locked and can't be edited.
When enabled, senders have the option to change the expiration date to any day within 180 days of the agreement creation.
New agreements automatically set the expiration date to 180 days from the day of sending (unless a limited number of days is defined).
The sender is free to select a different expiration date within the 180 days.
When enabled, agreements that are In Progress have the option to edit the deadline date on the Manage page.
The Expiration Date in the agreement meta data displays a pencil icon to open the Add or Edit interface for the deadline.
When enabled, new agreements automatically adopt a completion deadline measured in the number of days defined by the input field.
If the option to allow sender to set or modify the expiration date is not enabled, then the date picker to the right side of the expiration date field will be locked, and only the default expiration window is enforced.
When enabled, the document expiration date does not apply to internal recipients—users within the same Acrobat Sign account as the sender.
This ensures that external recipients must complete their actions within the defined expiration window, as stated in the agreement details and email notifications. Meanwhile, internal counter-signers are not restricted by the expiration date, preventing situations where they run out of time to complete their actions before the agreement expires.
When enabled, this option inserts the deadline information on any email communications to the recipient.
Examples below show the request to sign, and a reminder email with the deadline information visible.
If the option is disabled, the expiration information is not included in the email template.
When Document Expiration is enabled, either Allow senders to set or modify expiration settings per document or Limit number of days signers will have to sign documents to must also be selected.
New agreements display the Completion Deadline option. The experience will depend on whether the default deadline is being used or if the sender can set the deadline.
If the Document Expiration is not enabled, the Completion Deadline option is omitted from the page entirely.
When enabled, senders have the option to change the expiration date to any day within 180 days of the agreement creation.
New agreements display the Completion Deadline option with no value inserted. The sender can provide a number of days before the agreement will expire, or no expiration will be defined.
When enabled, agreements that are In Progress have the option to edit the deadline date on the Manage page.
The Expiration Date in the agreement meta data displays a pencil icon to open the Add or Edit interface for the deadline.
When enabled, new agreements automatically adopt a completion deadline measured in the number of days defined by the input field.
If the option to allow sender to set or modify the expiration date is not enabled, then the Completion Deadline option will be checked, but locked. Only the default expiration window is enforced in this case.
When enabled, the document expiration date does not apply to internal recipients—users within the same Acrobat Sign account as the sender.
This ensures that external recipients must complete their actions within the defined expiration window, as stated in the agreement details and email notifications. Meanwhile, internal counter-signers are not restricted by the expiration date, preventing situations where they run out of time to complete their actions before the agreement expires.
When enabled, this option inserts the deadline information on any email communications to the recipient.
Examples below show the request to sign, and a reminder email with the deadline information visible.
If the option is disabled, the expiration information is not included in the email template.
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.
Best practices
Typically, setting at least a default expiration date is encouraged. This helps keep agreements organized and aligned with current policies. Expiring agreements that are unlikely to be completed improves efficiency by reducing clutter in the In Progress filter on the Manage page, making it easier to track and manage active agreements.
If you enable expiration dates, consider:
- Enabling Include expiration information in emails sent to signers – Informing recipients of a deadline encourages timely completion and clarifies that the agreement will expire if they don't act.
- Disabling Include internal signers when applying document expiration deadlines – Deadlines typically impact external recipients more than internal users. Disabling this option prevents agreements from expiring simply because internal counter-signers haven't completed their actions in time.
- Enable Allow modification of expiration settings after document is sent - Whether to allow changes usually depends on compliance requirements. If your process doesn't require strict time constraints, enabling this option provides flexibility, giving the senders an option to save an agreement that is about to expire.
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 |
Notă:
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.
