上次更新時間
2026年3月5日
新功能
開始使用
管理
- Admin Console 概觀
- 使用者管理
- 新增、編輯和檢閱已啟用使用者
- 建立以功能為導向的使用者
- 檢閱尚未完成驗證的使用者
- 檢查有佈建錯誤的使用者
- 變更姓名/電子郵件地址
- 編輯使用者的群組成員資格
- 透過群組介面編輯使用者的群組成員資格
- 將使用者升級為管理員角色
- 使用者身分類型與 SSO
- 切換使用者身分
- 使用 MS Azure 驗證使用者
- 使用 Google Federation 驗證使用者
- 產品設定檔
- 登入體驗
- 帳戶/群組設定
- 設定概觀
- 全域設定
- 帳戶層級與 ID
- 新的收件者體驗
- 自我簽署工作流程
- 大量傳送
- 網頁表單
- 自訂傳送工作流程
- Power Automate 工作流程
- 資料庫文件
- 透過合約收集表單資料
- 限制文件可見性
- 附加已簽署合約的 PDF 副本
- 在電子郵件中加入連結
- 在電子郵件中加入影像
- 附加至電子郵件的檔案將命名為
- 將稽核報告附加至文件
- 將多個文件合併為一個
- 下載個別文件
- 上傳已簽署的文件
- 我的帳戶中的使用者委派
- 允許外部收件者委派
- 授權簽署
- 授權傳送
- 有權新增電子印章
- 設定預設時區
- 設定預設日期格式
- 使用者加入多個群組 (UMG)
- 群組管理員權限
- 更換收件者
- 稽核報告
- 交易頁尾
- 產品內傳送訊息和指示
- 無障礙 PDF
- 醫療保健客戶
- 帳戶設定/品牌化設定
- 簽名偏好設定
- 格式固定的簽名
- 允許收件者簽署
- 簽署者可變更其姓名
- 允許收件者使用已儲存的簽名
- 自訂使用條款和消費者資訊披露
- 透過表單欄位導覽收件者
- 重新啟動合約工作流程
- 拒絕簽署
- 允許戳記工作流程
- 要求簽署者提供其職稱或公司
- 允許簽署者列印並置入書面簽名
- 在電子簽名時顯示訊息
- 需要簽署者使用行動裝置來建立自己的簽名
- 要求取得簽署者的 IP 位址
- 將公司名稱和職稱排除在參與戳記之外
- 套用「最適化簽名繪製」縮放
- 數位簽名
- 電子印章
- 數位身分
- 報告設定
- 全新報告體驗
- 傳統報告設定
- 安全性設定
- 傳送設定
- 登入後顯示「傳送」頁面
- 合約建立體驗
- 傳送時需有收件者名稱
- 鎖定已知使用者的名稱值
- 允許的收件者角色
- 允許電子見證人
- 收件者群組
- 副本收件者
- 必填欄位
- 附加文件
- 欄位扁平化
- 修改合約
- 從進行中的協議移除收件人
- 合約名稱
- 語言
- 私人訊息
- 允許的簽名類型
- 提醒
- 已簽署文件的密碼保護
- 傳送合約通知途徑
- 簽署者身分識別選項
- 使用已驗證身分的資料填入表單欄位
- 內容保護
- 啟用公證交易
- 文件過期
- 預覽、定位簽名及新增欄位
- 簽署順序
- 新增我自己
- 合約下載連結
- 表單欄位邊框
- Liquid mode
- 自訂工作流程控制項
- 電子簽名頁面的上傳選項
- 「簽署後」確認重新導向 URL
- 限制存取共用的合約
- 登入後顯示「傳送」頁面
- 訊息範本
- 生技製藥設定
- 工作流程整合
- 公證設定
- 付款整合
- 簽署者傳訊
- SAML 設定
- SAML 設定
- 安裝 Microsoft Active Directory Federation Service
- 安裝 Okta
- 安裝 OneLogin
- 安裝 Oracle Identity Federation
- SAML 設定
- 資料控管
- 時間戳記設定
- 外部封存
- 帳戶語言
- 電子郵件設定
- 從 echosign.com 移轉至 adobesign.com
- 為收件者設定選項
- 法規要求指引
- 大量下載合約
- 宣告您的網域
- 「回報不當使用」連結
- 系統需求與限制
傳送、簽署與管理合約
- 收件者選項
- 傳送合約
- 在文件中撰寫欄位
- 應用程式內撰寫環境
- 自動欄位偵測
- 使用撰寫環境拖放欄位
- 將表單欄位指派給收件者
- 預填角色
- 以可重複使用的欄位範本來套用欄位
- 將欄位轉送至新的資料庫範本
- 已在傳送合約時更新撰寫環境
- 以文字標籤建立表單
- 使用 Acrobat (AcroForms) 建立表單
- 欄位
- 撰寫常見問題集
- 應用程式內撰寫環境
- 簽署合約
- 管理合約
- 稽核報告
- 報告與資料匯出
進階合約功能與工作流程
- 網頁表單
- 可重複使用的範本 (資料庫範本)
- 轉移網頁表單與資料庫範本的所有權
- Power Automate 工作流程
- Power Automate 整合與包含授權的概觀
- 啟用 Power Automate 整合
- 「管理」頁面的相關動作
- 追蹤 Power Automate 使用狀況
- 建立新的流程 (範例)
- 用於流程的觸發器
- 從 Acrobat Sign 之外匯入流程
- 管理流程
- 編輯流程
- 共用流程
- 停用或啟用流程
- 刪除流程
- 實用範本
- 僅限管理員
- 合約封存
- 將完成的文件儲存至 SharePoint
- 將完成的文件儲存至商務用 OneDrive
- 將完成的文件儲存至 Google 雲端硬碟
- 將完成的文件儲存至 DropBox
- 將完成的文件儲存至 Box
- 網頁表單合約封存
- 將完成的網頁表單文件儲存至 SharePoint 資料庫
- 將完成的網頁表單文件儲存至商務用 OneDrive
- 將完成的文件儲存至 Google 雲端硬碟
- 將完成的網頁表單文件儲存至 Box
- 合約資料擷取
- 合約通知
- 傳送包含合約內容和已簽署合約的自訂電子郵件通知
- 在 Teams 頻道中取得您的 Adobe Acrobat Sign 通知
- 在 Slack 中取得您的 Adobe Acrobat Sign 通知
- 在 Webex 中取得您的 Adobe Acrobat Sign 通知
- 合約產生
- 從 Power App 表單和 Word 範本產生文件，傳送以供簽署
- 從 OneDrive 的 Word 範本產生合約，並取得簽名
- 為所選的 Excel 列產生合約，傳送以供檢閱和簽名
- 自訂傳送工作流程
- 共用使用者與合約
與其他產品整合
- Acrobat Sign 整合概觀
- 適用於 Salesforce 的 Acrobat Sign
- 適用於 Microsoft 的 Acrobat Sign
- 其他整合功能
- 合作夥伴管理的整合功能
- 如何取得整合金鑰
Acrobat Sign 開發人員
- REST API
- Webhook
- 沙箱
支援與疑難排解
註解：
本文件針對最新版本，重點說明客戶導向應用程式中的新功能、體驗變更，以及已解決的問題。
以開發人員為中心的 API 和 Webhook 更新，均記載於 Acrobat Sign 開發人員指南中。
並不保證所有功能/變更在發行當日即可使用。 請一律參考美式英文版本的頁面，這是最新且最準確的版本。
Adobe Acrobat Sign 版本 v17.0.1
生產部署：2026 年 3 月 17 日
政府雲端部署：2026 年 3 月 19 日
改善功能
- 建立副本 – 擴展存取點，加快重複使用合約的速度。
現在可直接於「管理」頁面的「進行中」和「等候您」篩選器中使用「建立副本」，並且也可從傳送後確認頁面中使用。 這些額外進入點可供在傳送生命週期的更多時間點中，更輕鬆地重複使用合約，減少從頭重新開始的需求。
注意：在此版本中，會從管理員選單中移除停用此功能的管理控制項，並將「建立副本」建立為供所有符合資格之使用者使用的標準功能。
可用的環境：沙箱、商業、政府 |可用的服務層級：Acrobat Sign Solutions |設定範圍：帳戶和群組；預設為啟用。
REST API/Webhook 更新
您可以在 Acrobat Sign API 文件中找到此版本的 API 和 Webhook 更新。
- SMS 傳送失敗的 Webhook 通知 – 即時了解 SMS 傳送失敗的可見度、自動修復，以及與電子郵件退信的對等性。
當透過 SMS 傳送的合約因無效電話號碼、電信業者拒絕或封鎖線路等問題而無法傳送時，Acrobat Sign 現在會發出新的 Webhook 事件 AGREEMENT_PHONE_BOUNCED。 這讓客戶能夠近即時偵測到 SMS 傳送失敗，並自動觸發後續行動，例如修正電話號碼、重新嘗試傳送或開啟支援案例，進而消除盲點並減少行動優先簽署工作流程的延遲。
可用的環境：沙箱、商業、政府 | 可用的服務層級：Acrobat Sign Solutions | 設定範圍：API
- Webhook 承載 – 新增條件式參與者 extendedStatus 欄位，以進行動態參與者更新，改善參與者狀態可見度。
當傳送者使用動態參與修改傳送中合約時，Webhook 通知現在會於每個參與者 (memberInfos[]) 物件中包括 extendedStatus 欄位。 此欄位可提供額外的參與者生命週期詳細資料，同時讓現有欄位保持不變，以實現向下相容性。
{
"participantSets": [
{
"id": "",
"memberInfos": [
{
"company": "TestCo",
"email": "signer2@someDomain.dom",
"id": "CBJCHBCAABAAJiZV9cH",
"name": "Signer Two",
"status": "ACTIVE",
"extendedStatus": "REMOVED"
}
],
"order": ,
"role": "",
"status": ""
}
]
}
status 值 (不變)：ACTIVE、REPLACED。
extendedStatus值：ACTIVE、REPLACED、REMOVED、COMPLETED。
可用的環境：沙箱、商業、政府 | 可用的服務層級：Acrobat Sign Solutions | 設定範圍：API
已解決的問題
| 問題 | 描述 |
|---|---|
| 4543515 | 摘要：在簽署者成功簽署且協議進入下一步後，可能會為有效簽署者錯誤產生 webhook 電子郵件退信事件。當同一簽署群組中的受委派者具有無效的電子郵件地址，且傳送者取代原始委派者時，可能會發生此情況。在這類情況下，系統可能會錯誤地將「代表…簽署」退回事件歸因至有效的簽署者，而非其電子郵件實際退回的參與者。 |
| 修正：已修正事件歸因邏輯，因此電子郵件退信事件僅與電子郵件實際退信的參與者相關聯。不再為已完成簽署的有效簽署者產生退信事件，webhook 通知現在會反映正確的參與者和電子郵件。 | |
| 4544548 | 摘要：透過網頁 UI 建立的整合金鑰可能會在 10 年後到期，儘管建立頁面聲明金鑰提供「永久存取權」。當金鑰達到其 10 年期限時，API 呼叫會開始傳回過期權杖錯誤，這可能會意外中斷現有整合。 |
| 修正：已更新使用者介面訊息傳送，以移除「永久存取權」措辭，並清楚顯示整合金鑰的過期日。更新的文字現在說明金鑰會保留存取權直到到期日或手動撤銷為止，提供關於 10 年預設期限的透明度。 | |
| 4546301 | 摘要：對於具有極大文件的合約，Webhook 事件傳送可能會延遲多達數小時，即使合約建立已完成且早期處理步驟似乎可在幾分鐘內完成，也不例外。在延遲期間，webhook 傳送服務在嘗試擷取協議文件時可能會重複收到 DOCUMENT_NOT_AVAILABLE 回應，且 webhook 事件可能直到服務停止重試或文件變為可用時才會傳送。 |
| 修正：已修正文件可用性處理，因此大型協議能可靠地轉換到文件可擷取的狀態，而不會出現延長的 DOCUMENT_NOT_AVAILABLE 回應。因此，webhook 事件會傳送而不會因為對不可用文件的文件擷取重試而造成多小時延遲。 | |
| 4547823 | 摘要：當透過 API 在撰寫狀態中建立協議，然後從管理體驗中編輯時，收件人的私人訊息可能不會為某些簽署者顯示。在此情況下，UI 可能會將私人訊息值展開為「無」或空白，儘管協議資料包含正確的私人訊息值。此行為出現在共用帳戶情況中，其中使用者切換到另一個使用者的帳戶來編輯草稿，且可能僅影響特定收件人，而其他收件人則正確顯示。 |
| 修正：已新增檢查，以擷取作用中的共用情境，並對授權的共用使用者傳回私人訊息。因此，從「撰寫」流程檢視或傳送 API 建立的草稿時，私人訊息值現在可正確顯示。 | |
| 4548274 | 摘要：在新範本體驗中編輯和儲存範本後，資料庫範本的「修改日期」可能不會更新。使用者可能會在範本上看到新增或更新的欄位，但「修改日期」在「管理」UI 和管理檢視中保持不變，使其看來有如最近並未修改範本。發生此情況是因為新體驗更新表單欄位時所透過的路徑，不會一併更新範本的修改時間戳記。 |
| 修正：已讓新範本體驗和相關 API 操作之間的修改日期更新行為一致。儲存範本欄位變更的程式碼路徑，現在也會更新範本的「修改日期」，以反映最近變更的實際時間。 | |
| 4548564 | 摘要：將簽名和表單欄位放置在來源文件的既存印章註解上時，在簽署 PDF 中可能會顯示為不可見。在受影響的模板中，印章註解會在處理過程中重疊或遮蔽互動式欄位，導致完成的簽名和其他欄位在最終簽署的文件中被隱藏。 |
| 修正：印章註解處理已更新，可安全地處理和平面化既有的印章註解，使其不再遮蔽表單欄位或簽名。現在於整個簽署過程中以及在已完整執行的 PDF 中，放置在印章區域上方的欄位都會維持為可見。 | |
| 4549103 | 摘要：在寄件人將先前不正確的收件人替換為有效電子郵件後，可能會再次記錄該先前不正確收件人的電子郵件退回事件。在某些情況下，稽核記錄可能會顯示舊電子郵件的第二個退回事件，即使新收件人成功接收、檢視或簽署合約，合約狀態也可能反映「電子郵件退回」。此行為可能會讓合約看來仍同時以舊電子郵件地址和新電子郵件地址為目標。 |
| 修正：替換簽署者工作流程已更新，以防止向電子郵件已退回的被替換收件人傳送額外的通知電子郵件。系統現在會在傳送替換相關通知之前檢查先前的退回歷史記錄，確保在替換後不會為舊電子郵件產生新的退回事件。 | |
| 4549306 | 摘要：電子郵件包含某些特殊字元（例如撇號）的使用者可能無法從一般的 adobesign.com 或 echosign.com 公開登入頁面登入。輸入電子郵件地址並按一下以進入密碼欄位後，頁面可能會重新載入並清除電子郵件欄位，而不是將使用者重新導向到正確的分區或 SSO 登入頁面。這會阻止受影響的使用者完成驗證，並封鎖依賴公開登入端點的整合。 |
| 修正：已修正登入分區解析邏輯，可在建構分區間重新導向 URL 之前，正確處理並解碼包含特殊字元的電子郵件地址。具有受影響電子郵件格式的使用者現在可正確重新導向到其指定的分片和 SSO 登入頁面，而不會清除電子郵件欄位。 | |
| 4549331 | 摘要：當啟用特定文件處理功能，且來源 PDF 包含無效的頁框座標 (例如不正確的 CropBox 或 MediaBox 值) 時，簽名和其他表單欄位在簽署 PDF 中可能顯示為遺失或不可見。在此情況下，依賴頁面座標的欄位可能會在可見頁面區域外轉譯，使完成的簽名看起來遺失，即使簽署成功完成。 |
| 修正：已修正 PDF 頁框處理，可在文件處理期間安全地將無效 CropBox 和 MediaBox 值標準化。如此一來，現在放置簽名和表單欄位時就會對齊可見頁面區域，且簽署 PDF 會如預期顯示簽名。 | |
| 4550367 | 摘要：當寄件人的群組預設簽署者驗證設定為電話，且帳戶沒有可用的電話驗證配額時，即使網頁表單簽署者驗證設定為非電話方法（例如 Adobe Sign），在選擇預覽和新增欄位後，建立網頁表單可能會失敗並顯示一般的「伺服器錯誤」。因此，受影響帳戶中的所有使用者可能會被封鎖，無法在所有文件中建立網頁表單。 |
| 修正：網頁表單建立現在僅針對實際為網頁表單簽署者設定的驗證方法評估配額，不再僅根據群組預設驗證設定套用電話驗證配額檢查。這可防止錯誤的配額耗盡錯誤，並允許正常建立網頁表單。 | |
| 4551011 | 摘要：當傳送者上傳特定的掃描 PDF、新增簽名欄位以及傳送合約時，簽署 PDF 可能在簽署完成後顯示沒有可見的簽名。當上傳的 PDF 包含無效的頁面邊界中繼資料 (MediaBox 和 CropBox 座標顯示為相反) 時，可能會發生此行為，這可能會導致簽名和其他欄位外觀圖層在可見頁面區域外轉譯。 |
| 修正：已更新 PDF 頁面邊界處理，可正確處理具有無效或相反 MediaBox 和 CropBox 座標值的 PDF，如此一來，簽名和表單欄位外觀內容就會在可見頁面區域內轉譯，並在最終簽署 PDF 中保持為可見。 | |
| 4551427 | 摘要：部分已擁有作用中且正確佈建之帳戶的收件者，會以「虛擬使用者」收件者的身分收到合約，因此合約不會出現在其正常的「管理」檢視中。當收件人電子郵件地址包含前導或尾隨空格時，就會發生這種情況，這會阻止系統將電子郵件與現有使用者進行比對，並導致建立虛擬使用者記錄。 |
| 修正：電子郵件剖析和使用者查詢已更新，可在將收件者電子郵件地址與現有使用者進行比對之前，先將其標準化，移除前導和尾隨空白字元。如此一來，即使電子郵件輸入時含有空格 (在 API 裝載和工作流程收件者清單中)，傳送給現有使用者的合約也會解析至已註冊的帳戶，而不是建立虛擬使用者收件者。 | |
| 4553198 | 摘要：當合約包含至少一個設定為 SMS 傳送的收件人和至少一個設定為僅電子郵件傳送的收件人時，透過 API 取消合約不會向 SMS 收件人傳送 SMS 取消通知。合約已成功取消，並已傳送電子郵件通知，但 SMS 收件人不會收到取消訊息。 |
| 修正：取消工作流程已修正，可確保當合約被取消時，會向所有設定為 SMS 傳送的收件人傳送 SMS 取消通知，無論其他收件人的傳送方法為何。 | |
| 4554463 | 摘要：當合約包含複製的選項按鈕，且這些選項按鈕在合併的文件間共用相同欄位名稱時，在最終簽署 PDF 中只會維持選取一個選取選項的執行個體。雖然這些欄位在視覺上顯示為核取方塊，但它們實際上是以選項按鈕的方式實作。簽署後，選定的值不會一致地傳播到所有複製的執行個體，導致預期選擇的對應不正確或不完整。 |
| 修正：表單欄位處理邏輯已修正，因此複製的選項按鈕會儲存並傳播選定的匯出值，而不是內部索引值。這可確保相同選項按鈕欄位的所有複製執行個體都會在簽署 PDF 中反映正確的選擇。 | |
| 4554593 | 摘要：某些使用舊版 OAuth 端點來重新整理存取權杖的合作夥伴整合開始出現 HTTP 401 錯誤而失敗。服務拒絕權杖重新整理要求，並出現錯誤，指出應用程式不允許使用舊版 OAuth 端點，必須改用 OAuth v2 端點。這阻止了客戶透過合作夥伴應用程式驗證 Acrobat Sign，即使是先前正常運作的整合也是如此。 |
| 修正：已修正驗證服務，因此設定為使用舊版 OAuth 流程的合作夥伴應用程式可以再次成功重新整理權杖，而不會錯誤地迫使其使用 OAuth v2 端點。 | |
| 4554614 | 摘要：當簽署者在需要簽署者驗證且設定為在簽署前需要接受使用條款的合約上使用現代電子簽名體驗時，按一下「按一下以簽署」會觸發 5 秒重新導向至傳統簽署體驗。重新導向訊息警告將清除在新版簽署中輸入的簽名和縮寫簽名，迫使簽署者重新輸入這些項目，且實際上需簽署兩次。 |
| 修正：已修正簽署權杖的重新整理流程，因此當簽署者在簽署前接受使用條款時，重新核發的簽署權杖會保留簽署者驗證詳細資料。這可防止最終簽署步驟驗證失敗，並消除從現代簽署強制回退到傳統體驗的情況。 | |
| 4555656 | 摘要：在特定時機條件下，合約狀態轉換可能看似成功，但實際上並未變更合約狀態。當在後端處理完成之前收到 Webhook 通知時，後續的 API 呼叫可能會使用過時的合約狀態資料。在此時間窗口內，某些狀態轉換方法會傳回 HTTP 200 OK，即使合約不處於要求轉換的有效狀態。因此，自動化工作流程可能會假設轉換成功，而合約仍保持在原始狀態。 |
| 修正： 合約狀態轉換邏輯已更新，在套用轉換前強制執行嚴格驗證。如果合約並非處於有效狀態，API 現在會傳回清楚的錯誤回應，而不是靜默傳回成功。這可確保明確拒絕無效的轉換，讓呼叫系統能適當重試，並防止合約在不可見的情況下維持處於意外狀態。 |
