分片组
允许发件人指定到期日期,以便在到达设定的时间后自动取消协议。
Acrobat Sign 中的到期日期功能允许发件人设置收件人完成签名的截止时间,超过此时间协议将自动取消。 这有助于控制签名截止日期,特别是对于时间敏感型协议,例如季节性合同或特价优惠。 它还可以通过从“进行中”列表中移除旧协议或不太可能完成的协议来简化协议管理,从而更轻松地跟踪活动协议。
发件人可以从发送协议之日起设置最长为 365 天的到期日期。 默认情况下,协议计划在当地服务器时间晚上 11:59 过期,但发件人可以修改此设置。 为优化系统性能,协议始终会在其指定服务器组的非高峰时段到期。 如果在高峰时段设置了到期时间,系统会自动将其延迟 12 小时,以确保在非高峰时段到期。
如果未手动设置过期日期,协议将在进行中状态下持续 365 天后自动过期,避免长期协议无限期处于开启状态。
所有到期时间均基于服务器组的时区(请参阅页面底部的常见问题)。
配置
可用性:
- Acrobat Standard 和 Acrobat Pro:不支持
- Acrobat Sign Solutions:支持
- 针对 10 万美元以下的 VIP、VIPMP 和 ETLA 帐户启用
- 针对所有其他 ETLA 帐户禁用
- Acrobat Sign for Government:支持;默认为禁用状态
配置范围:
管理员可以在帐户级别和组级别启用此功能。
通过导航管理员配置菜单到发送设置 > 文档过期,以访问此功能
文档到期相关功能系列的可配置选项如下:
启用文档过期后,还必须选择允许发件人设置或修改每个文件的到期设置或限制签名者签署文档的天数。
这样,协议设置中的完成截止日期值便可用了。
如果禁用此设置,完成截止日期选项将被锁定且无法编辑。
启用后,发件人可以选择在协议创建后 365 天内的任何一天更改到期日期。
除非定义了有限的天数,否则新协议会自动将到期日期设置为发送日期后的 365 天。
发件人可以在 365 天内选择其他到期日期。
如果协议保持进行中状态,所有协议将在创建后 365 天自动过期。
启用后,处于进行中状态的协议可以在管理页面上编辑截止日期。
协议元数据中的到期日期会显示一个铅笔图标,以打开截止日期的“添加”或“编辑”界面。
启用后,新协议将自动采用由输入字段定义的天数作为完成截止日期。
如果允许发件人设置或修改到期日期的选项未启用,则到期日期字段右侧的日期选择器将被锁定,并且仅强制执行默认到期窗口。
启用后,此选项会在发送给收件人的任何电子邮件通信中插入截止日期信息。
下面的示例显示了签名请求,以及显示截止日期信息的提醒电子邮件。
如果禁用此选项,电子邮件模板中不会包含到期信息。
拥有 Acrobat Sign 帐户的收件人可以看到根据其用户个人资料中所定义时区调整后的到期日期。
没有 Acrobat Sign 帐户的收件人将默认使用 US_PACIFIC 时区。
到期时间
文档到期时间始终在非高峰时段进行,具体时间取决于发送协议的服务器。非高峰时段为晚上 7 点到次日早上 7 点(服务器本地时区)。
默认情况下,通过现代请求签名流程发送的协议分配的到期时间为晚上 11:59,尽管发件人可以设置自定义到期日期和时间。但是,通过 API、集成或旧版界面发送的协议默认不会采用晚上 11:59 作为到期时间,而是采用协议最初发送时的时间戳。
如果协议设置为在高峰时段内到期,则会排队等待到期,但会自动延迟 12 小时,确保在非高峰时段处理过期事件。
到期排队期间状态和编辑
- 当协议在排队等待到期时,其状态在管理页面和 API 响应上保持进行中状态。
- 收件人无法签署排队等待的协议,并且将收到一条错误消息,指示无法签署协议。
- 在 12 小时的排队等待窗口期中,发件人可以编辑管理页面上的到期日期,以延长截止日期,并为收件人提供额外的时间进行签名。
最佳实践
通常,建议至少设置默认到期日期。 这有助于使协议保持有序,并与当前策略保持一致。 在“管理”页面上的“进行中”筛选条件中移除可能无法完成的过期协议,以提高效率,告别杂乱无章,从而更易于跟踪和管理活动协议。
如果您启用了到期日期,请考虑:
- 启用在发送给签名者的电子邮件中包括过期信息 - 通知收件人截止日期可激励其及时完成协议,并明确说明如果他们不执行操作,协议将到期。
- 禁用应用文档到期截止期限时包括内部签名者 - 截止日期通常会更影响外部收件人,而不是内部用户。 禁用此选项可防止协议因内部会签者未及时完成操作而过期。
- 启用允许在文档发送之后修改过期设置 - 更改是否允许更改通常取决于合规性要求。 如果您的流程不需要严格的时间限制,启用此选项可提高灵活性,并为发件人提供保存即将到期的协议的选项。
非高峰时段从晚上 7 点到次日早上 7 点,基于发送协议的分片组的最中央时区。 用于每个分区群组的时区如下:
|
|
高峰时段的时区(早上 7 点到晚上 7 点) |
|---|---|
|
NA1、NA2、NA3、NA4 |
美国/芝加哥 |
|
EU1、EU2 |
欧洲/柏林 |
|
AU1 |
澳大利亚/悉尼 |
|
JP1 |
亚洲/东京 |
|
IN1 |
亚洲/科尔卡托 |
|
SG1 |
亚洲/新加坡 |
某些分片组包括多个分片,横跨多个时区。 组中的所有分片都应用相同的非高峰时段到期窗口期。
例如,NA1、NA2、NA3 或 NA4 均以美国中部时间 (GMT -6) 为基准,采用相同的非高峰时段。
协议将按计划过期,通常在设置过期时间的几分钟内过期。
根据发件人的环境,它指的是发送协议的分片。 (查找您所在的分片 >)
即使协议尚未转换为已过期状态,签名者在到期时间过后也将无法签名。 他们将看到一条错误消息:
如果协议已排队等待到期,但系统尚未处理该到期事件,则发件人仍然可以编辑到期日期。 这可为收件人在协议到期之前提供额外的时间来签署协议。
在系统处理到期日期之前(12 小时内),协议将保持 IN_PROCESS 状态。 到期事件处理完成后,它将转换为已过期状态。
是的,您可以在处理到期之前随时编辑到期时间。 在协议过渡到已过期状态之前,修改到期时间没有任何限制。
是的,但延迟可能会因系统加载而相差几分钟时间。
在请求签名页面上设置到期日期/时间时,默认设置为晚上 11:59,从而确保在非高峰时段到期并在该时间或之后不久进行处理。 您可以在协议设置部分中调整此设置。
协议将继续显示为进行中状态,直到过期处理完成(通常是 12 小时后)。
数据治理仅在协议过渡到终止状态(例如已过期)后才开始。 延迟到期也会延迟保留期限的开始时间。
处理到期后会记录到期事件,如果到期时间在高峰时段内,则可以延迟 12 小时。
此更新优化了系统性能,以适应不断增长的需求。