新機能
開始する
管理者
- Admin Console の概要
- ユーザー管理
- アクティブなユーザーの追加、編集、確認
- 機能重視のユーザーの作成
- 検証を完了していないユーザーを確認
- プロビジョニングエラーが発生しているユーザーの確認
- 名前/メールアドレスの変更
- ユーザーのグループメンバーシップの編集
- グループインターフェイスを使用したユーザーのグループメンバーシップの編集
- ユーザーの管理者役割への昇格
- ユーザー ID タイプと SSO
- ユーザー ID の切り替え
- MS Azure を使用したユーザー認証
- Google フェデレーションを使用したユーザー認証
- 製品プロファイル
- ログインエクスペリエンス
- アカウント/グループ設定
- 設定の概要
- グローバル設定
- アカウントレベルと ID
- 新しい受信者エクスペリエンス
- 自己署名ワークフロー
- 一括送信
- Web フォーム
- カスタム送信ワークフロー
- Power Automate ワークフロー
- ライブラリ文書
- 契約書からフォームデータを収集する
- 文書の表示制限
- 署名済み契約書の PDF コピーの添付
- 電子メールへのリンクの追加
- 電子メールへの画像の添付
- メールに添付されるファイルの名前
- 文書への監査レポートの添付
- 複数の文書を 1 つに結合
- 個別文書をダウンロード
- 署名済み文書をアップロード
- アカウント内のユーザーの委任
- 外部受信者による委任の許可
- 署名の権限
- 送信の権限
- e シールを追加する権限
- デフォルトのタイムゾーンの設定
- デフォルトの日付形式の設定
- ユーザーの複数グループ所属(UMG)
- グループ管理者の権限
- 受信者を置き換え
- 監査レポート
- トランザクションフッター
- 製品内メッセージとガイダンス
- PDF のアクセシビリティ
- PDF/A ワークフロー
- 医療機関のお客様
- 新しい署名依頼機能
- 新しいカスタムワークフロー機能
- 新しい「テンプレートを作成」機能
- アカウント設定 / ブランド設定
- 署名の環境設定
- 形式の整った署名
- 受信者による署名の許可
- 署名者による名前の変更
- 受信者が保存した署名を使用するのを許可
- カスタムの利用条件と消費者への情報開示
- フォームフィールド間の受信者の移動
- 契約書ワークフローをやり直し
- 署名を辞退
- 印鑑ワークフローを許可
- 署名者による役職または会社名の入力を必須とする
- 署名者が手書き署名を印刷および配置するのを許可
- 電子サイン時のメッセージの表示
- 署名の作成時にモバイルデバイスの使用を必須
- 署名者から IP アドレスを要求
- 参加スタンプから会社名と役職を除外
- Adaptive Signature Draw の拡大・縮小を適用
- デジタル署名
- e シール
- デジタル ID
- レポート設定
- 従来のレポーティングを有効にする
- 新しいレポートエクスペリエンス
- 従来のレポート設定
- セキュリティ設定
- シングルサインオン設定
- アカウント記憶設定
- ログインパスワードポリシー
- ログインパスワードの強さ
- Web セッション期間
- PDF 暗号化のタイプ
- API
- ユーザーおよびグループ情報へのアクセス
- 許可する IP 範囲
- アカウント共有
- アカウント共有権限
- 契約書の共有制御
- 署名者の ID 確認
- 契約書の署名パスワード
- 文書のパスワード強度
- 地理的な場所で署名者をブロック
- 電話認証
- ナレッジベース認証(KBA)
- ページの抽出を許可
- 文書リンクの有効期限
- Webhook/コールバック用のクライアント証明書のアップロード
- タイムスタンプ
- 送信設定
- ログイン後に送信ページを表示
- 契約書作成エクスペリエンス
- 送信時に受信名を必須とする
- 既知のユーザーの名前値をロック
- 受信者の役割を許可
- 証人署名者を許可
- 受信者グループ
- CC 関係者
- 必須フィールド
- 文書の添付
- フィールドのフラット化
- 契約書を変更
- 進行中の契約書から受信者を削除
- 契約書名
- 言語
- プライベートメッセージ
- 許可されている署名タイプ
- リマインダー
- 署名済み文書のパスワード保護
- 契約書通知の送信方法
- 署名者 ID オプション
- ID 確認済みデータをフォームフィールドに入力
- コンテンツ保護
- Notarize トランザクションを有効にする
- 文書の有効期限
- プレビュー、署名の位置指定、フィールドの追加
- 署名順序
- 自分を追加
- 契約書のダウンロードリンク
- フォームフィールドの境界線
- Liquid Mode
- カスタムのワークフロー制御
- 電子サインページのアップロードオプション
- 署名後の確認 URL リダイレクト
- 共有された契約書へのアクセス制限
- ログイン後に送信ページを表示
- メッセージテンプレート
- バイオ医薬業界標準対応
- ワークフロー統合
- 公証設定
- 支払いの統合
- 署名者へのメッセージ
- SAML 設定
- SAML 設定
- Microsoft Active Directory フェデレーションサービスのインストール
- Okta のインストール
- OneLogin のインストール
- Oracle ID フェデレーションのインストール
- SAML 設定
- データガバナンス
- タイムスタンプ設定
- 外部アーカイブ
- アカウントの言語
- 電子メール設定
- echosign.com から adobesign.com への移行
- 受信者のオプションの設定
- 規制要件に関するガイダンス
- アクセシビリティ
- HIPAA
- GDPR
- 21 CFR part 11 および EudraLex Annex 11
- 医療機関のお客様
- IVES サポート
- 契約書の「Vault」への追加
- EU/英国に関する考慮事項
- 契約書の一括ダウンロード
- ドメインの要求
- 「不正を報告」リンク
- システム要件と制限
契約書の送信、署名、および管理
- 受信者オプション
- 契約書の送信
- 送信(作成)ページ
- ランドマークと機能の概要
- グループセレクター
- ファイルやテンプレートの追加
- 契約書名
- グローバルメッセージ
- 契約書の完成期限
- リマインダー
- PDF を保護するパスワード
- 署名タイプ
- 受信者のロケール
- 受信者の署名順序/フロー
- 受信者の役割
- 受信者の認証
- 受信者のためのプライベートメッセージ
- 受信者の契約書のアクセス
- CC する関係者
- ID チェック
- 自分のみに契約書を送付
- 契約書を他のユーザーに送信
- 手書き署名
- 受信者の署名順序
- 一括送信
- 送信(作成)ページ
- 文書へのフィールドの作成
- アプリ内オーサリング環境
- テキストタグを含むフォームの作成
- Acrobat(AcroForm)を使用したフォームの作成
- フィールド
- フィールドタイプ
- 一般的なフィールドタイプ
- 電子サインのフィールド
- イニシャルフィールド:
- 受信者名フィールド
- 受信者の電子メールフィールド
- 署名日フィールド
- テキストフィールド
- 日付フィールド
- 番号フィールド
- チェックボックス
- チェックボックスグループ
- ラジオボタン
- ドロップダウンメニュー
- リンクオーバーレイ
- 支払いフィールド
- 添付ファイル
- 参加スタンプ
- トランザクション番号
- 画像
- 会社名
- 役職名
- 印鑑
- フィールドコンテンツの外観
- フィールドの検証
- マスクされたフィールド値
- 表示条件/非表示条件の設定
- 計算フィールド
- 検証済みフォーム
- フィールドタイプ
- オーサリングに関するよくある質問
- 契約書に署名
- 契約書を管理
- 「管理」ページの概要
- 契約書をコピー
- 契約書を委任
- 受信者の置換
- 文書の表示制限
- 契約書のキャンセル
- リマインダーの新規作成
- リマインダーの確認
- リマインダーをキャンセルする場合
- Power Automate のフローにアクセス
- その他のアクション...
- 監査レポート
- レポートとデータの書き出し
高度な契約書機能とワークフロー
- Web フォーム
- 再利用可能なテンプレート(ライブラリテンプレート)
- Web フォームおよびライブラリテンプレートの所有権の譲渡
- Power Automate ワークフロー
- Power Automate 統合の概要と含まれる使用権限
- Power Automate 統合を有効にする
- 「管理」ページのインコンテキストアクション
- Power Automate の使用状況を追跡
- 新しいフローの作成(例)
- フローに使用するトリガー
- Acrobat Sign 外部からのフローの読み込み
- フローの管理
- フローの編集
- フローの共有
- フローを無効または有効にする
- フローの削除
- 便利なテンプレート
- 管理者のみ
- 契約書のアーカイブ
- Web フォーム契約書のアーカイブ
- 完了した web フォーム文書の SharePoint ライブラリへの保存
- 完了した web フォーム文書の OneDrive for Business への保存
- 完了した文書の Google ドライブへの保存
- 完了した web フォーム文書の 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
- Webhooks
- サンドボックス
サポートとトラブルシューティング
Adobe Acrobat Sign のリリーススケジュールとプレリリースドキュメント
Adobe Acrobat Sign は、「メジャー」リリースと「マイナー」リリースを合わせて、アップデートを毎年 3 回以上リリースしています。 システムまたはお客様の問題に対処するために、必要に応じてマイナーアップデートを追加で導入する場合があります。
- メジャーリリースでは、重要なアップデート、新機能、複数の拡張機能が提供されます。
- マイナーリリースは、より軽微な改善とユーザーエクスペリエンスの調整に重点を置いています。 マイナーリリースはメジャーアップデートの間に行われます。通常はサイクルごとに 1~2 回です。
中断を防ぐために、新機能はデフォルトでは無効になっており、アカウントまたはグループの管理者が手動で有効にする必要があります。
コンプライアンスの検証が必要な医療およびライフサイエンス業界のお客様には、Acrobat Sign パートナーはサードパーティのベンダーと連携して、各メジャーリリースの機能が含まれた検証パッケージを提供します。そのため、リスク要因を最小限に抑えることができます。
このプレリリースノートページは、新しい情報が入手できるようになると定期的に更新されるため、内容は常に変わります。
このページはローカライズされますが、そのプロセスには時間がかかるため、正式な米国英語版とは若干異なるローカライズ版が作成される場合があります。
最も正確な最新情報については、米国英語ページを参照することをお勧めします。
Adobe Acrobat Sign は、決められたスケジュールに従って、リリースノートとドキュメントのアップデートを公開します。
本番リリースの 8 週間前
- プレリリースページには予定された機能やアップデートの概要が公開されます。通常はサンドボックスが公開される 4 週間前です。
- この時点以降に変更された機能は、「正誤表」セクションに記載されます。
- この時点では、解決された問題は公開されません。
本番リリースの 4 週間前(サンドボックスの公開)
- プレリリースページが、新機能と更新された機能の詳細ドキュメントで更新されます。
- 必要に応じて、プレリリースサポートドキュメントへのリンクが追加されます。米国英語のみです。
- 最初の「解決された問題」セクションが公開され、4 週間にわたって継続的に更新が行われます。
公開日
- 公式リリースノートが、最終的な機能の詳細情報と本番サポートドキュメントへのリンクで更新されます。
- プレリリースページが更新され、次のリリースサイクルがハイライト表示されます。
- ドキュメントはライブシステムでのリリースの確認後に公開されます。通常は午後 7 時(太平洋時間)に公開されますが、複雑なアップデートは遅れる場合があります。
- 「解決された問題」の最終リストが米国英語のリリースノートに追加され、その後ローカライズされたバージョンが更新されます。
Government Cloud リリース
- Government Cloud 環境は、デプロイメント前に一部の機能の追加評価が必要になる場合があるため、通常は本番リリースの 2 日から数週間後に更新されます。
サンドボックスドキュメントは本番環境用に設計されています。 プレリリースコンテンツに表示されるリンクのターゲットは本番 URL です。つまり、ターゲットページが新規でまだ公開されていない場合(例えば、リンクが同じリリースの新機能を指す場合)、これらのリンクは、既存の古いドキュメントを表示したり、404 エラーを返したりする可能性があります。
新しいページは、リリースの公開と同時に公開され、リンクは本番環境の URL へ正しく接続されます。
サンドボックスの可用性
Acrobat Sign サンドボックス環境にアクセスするお客様は通常、公開日の 4 週間前から、新しいリリース機能をご使用いただけます。
- このサンドボックス環境は、通常の本番環境と同じ品質レベルのすべての本番品質保証手順の要件を満たす必要があります。
- アドビは、サンドボックス環境で 99.9% の可用性を目指していますが、お客様は、アドビ統合 SLA がサンドボックス環境を正式にカバーしていないことに注意してください。
- サンドボックス環境では、通常の本番環境と同じステータスページと障害対応手順が使用されます。
この記事には、プレリリース情報が含まれています。リリース日、機能、および他の情報は予告なく変更される可能性があります。
Adobe Acrobat Sign リリース v17.1
サンドボックスへのデプロイメント:2026 年 4 月 7 日
本番環境へのデプロイメント:2026 年 5 月 5 日
GovCloud へのデプロイメント:2026 年 5 月 12 日
改善された機能
- 対面署名 – web アプリケーションでのホスト署名セッションを有効にする
対面署名では、送信者が内部ホストを指定し、web ブラウザーを使用して対面署名セッションを効率化することができます。 ホストは管理ページまたはメール通知から制御された署名セッションを開始し、一時的にデバイスを署名者に渡して必要なアクションを完了させ、完了後は、再びホストが制御を引き継ぎます。セッションの作成と完了は監査証跡に記録され、署名者は必要に応じてメールアドレスを指定して契約書のコピーを受け取れます。
利用可能な環境:サンドボックス、商用 | 利用可能なサービスレベル: Acrobat Sign Solutions | 設定範囲:アカウントおよびグループ
対面署名の役割を有効にする方法を確認したい場合はこちら >
契約書の設定で対面署名を許可する方法を確認したい場合はこちら >
対面署名をホストする方法を確認したい場合はこちら >
- 管理ページからの一括デジタル署名 – 単一の認証で複数の契約書にデジタル署名を適用
署名者は「あなたの処理待ち」表示で複数の契約書を選択し、単一の署名認証を使用して一括アクションとしてデジタル署名を適用できます。これにより、大量ワークフローでの反復的な署名手順を削減しながら、既存のクラウド署名セキュリティ、認証、監査制御を維持できます。 一括署名では、署名者は一括アクションを完了する前に、すべての契約書をレビューまたはスキップする必要があります。
利用可能な環境:サンドボックス、商用、政府 |利用可能なサービス階層: Acrobat Sign Solutions |設定範囲:アカウントとグループ
一括デジタル署名を有効にする方法のドキュメントを確認 >
一括デジタル署名で署名する方法のドキュメントを確認 >
- 内部受信者のみに送信 – 同じ Acrobat Sign アカウント内の受信者にのみ契約書を送信するよう制限します。
内部受信者のみに送信設定により、ユーザーが Acrobat Sign アカウント外の受信者に契約書を送信することを防ぐことができます。 有効にすると、契約書は送信者のアカウント ID と一致するアカウント ID を持つ受信者にのみ送信できます。 この制御は内部セキュリティ要件をサポートし、契約書が外部に共有されることを防ぎます。
使用可能な環境:サンドボックス、商用、官公庁 | 使用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:アカウントおよびグループ
グループを内部受信者のみに制限するための設定ドキュメントを確認したい場合はこちら >
- Phone Transaction Usage Reporting – Expanded reporting with group-level visibility and scheduled report access
Phone transaction reporting now provides visibility into purchased quantities, quota start dates, and detailed consumption across SMS and WhatsApp transactions. Customers can track usage at the group level and access scheduled CSV reports through a unified reporting experience, enabling more accurate budgeting, internal allocation, and proactive monitoring to prevent service disruption when transaction limits are reached.
Reporting is now generated through scheduled reports in the reporting interface, with API access available to retrieve the latest report output.
New endpoint: POST /api/rest/v6/reportDownload
This endpoint accepts a scheduleId and returns the download URL for the most recently generated CSV report associated with that schedule.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: v6 REST API
Review the documentation for the SMS consumption report >
エクスペリエンスの変更
- 監査レポートでの署名の表示方法 – 各署名者が使用した署名入力方法をログに記録し、コンプライアンスの可視性を向上させ、手動検証を削減
監査レポートには、署名者が署名を行う際に使用した署名の表示方法が記録されるようになりました。 監査証跡では電子サインされたイベントごとに、署名者が入力署名、手書き署名、アップロード画像、モバイルベースの手書きや画像キャプチャのどれを使用したかが識別されます。 この機能強化により、コンプライアンスチームと運用チームが監査レポートから直接署名方法を確認できるようになり、曖昧さを減らし、不要な契約書の却下を防ぐことができます。
署名の外観の種類:- タイプ:署名者が名前を入力し、フォントベースの署名スタイルを選択します。
- 描画:署名者がデスクトップでマウスまたはトラックパッドを使用して署名を描画します。
- 画像:署名者がデスクトップから署名画像ファイルをアップロードします。
- モバイル描画:署名者がモバイルデバイスでタッチを使用して署名を手書きします。
- モバイル画像:署名者がモバイルデバイスで署名画像をアップロードまたは撮影します。
使用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービス階層:Acrobat Standard、Acrobat Pro、Acrobat Sign Solutions | 設定範囲:常に有効、設定不要
- API 署名 URL での保存済み署名 – API ベースの署名時に保存済みプロファイル署名の使用を許可
登録ユーザーが、API 生成の署名 URL(GET /agreements/{agreementId}/signingUrls)を使用して契約書に署名する際に、保存済みプロファイル署名を適用することを許可します。 保存された署名は、内部署名者と、メール OTP または Adobe ID を使用して認証する外部署名者に表示されます。 この機能は、アカウントレベルのセキュリティ制御を維持しながら、バックエンド統合の署名ワークフローを合理化します。
セキュリティレビュー後、アドビがアカウント単位で有効にします。
利用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:無効、サポートにお問い合わせください
- 新しいエクスペリエンスでの個人アドレス帳管理 – 新しい「署名を依頼」エクスペリエンスでは保存済みメールアドレスを個人アドレス帳で直接削除できるようになり、個人の受信者リストを正確かつ最新の状態に維持しやすくなっています。
利用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:デフォルトで有効、設定不可。
アドレス帳からのメール削除について更新されたドキュメントを確認したい場合はこちら >
- Agreement Expiration Window – Extended default expiration period to 365 days
The maximum completion deadline for agreements has been extended from 180 days to 365 days. When document expiration is enabled, agreements are now automatically assigned a 365-day expiration date that cannot be removed. This change ensures all agreements have a defined lifecycle, improves long-term tracking and compliance, and reduces the risk of agreements remaining open indefinitely while still allowing users to set earlier deadlines when needed.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: Account and Group
- 刷新されたホームページ – ワークフローアクセスを改善し、重大なアクションを明示
ホームページを再設計し、契約書の開始、アクティビティの監視、最近送信した契約書のコピー機能、より直感的な順序でのアクションタイルの表示を含む重要な機能へのアクセスが簡単にできるようになりました。「処理中」および「あなたの処理待ち」項目の迅速な識別、そしてより見やすくなり合理化された新機能バナーのエクスペリエンスにより、より迅速な移動、契約書の見落としの削減を可能にし、必要なものがすぐ見つかるホームエクスペリエンスが実現しました。
新しいホームページは、リリース後 10 日間にわたって展開されます。スケジュールについては、テクニカル通知を参照してください >
利用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:デフォルトで有効
新しいホームページレイアウトを確認する場合はこちら >
- 体験版の機能強化と期間の延長 – エンタープライズ版の体験に新しいオンボーディングエクスペリエンスが追加されました。既存の Adobe ID ユーザーは新たに体験を開始できます
法人向けの体験版に、最近のリリースで導入された強化されたオンボーディングエクスペリエンスが導入されました。また、既存の Adobe ID をお持ちのユーザーの体験期間が延長されています。Acrobat Sign の使用権限がないユーザーには、フル機能の体験アクセス権が付与されます。限定的な Acrobat Sign 使用権限を持つユーザーは、30 日の体験期間中、権限が一時的に昇格されます。
利用可能な環境: 商用 | 利用可能なサービスレベル:Acrobat Sign Solutions for business 体験版 | 設定範囲:体験版利用権
- 新しいカスタムワークフローデザイナーがデフォルトに – 新しいデザイナーを促進し、ユーザー切り替えコントロールを削除しつつ、管理の柔軟性を保持
新しい「カスタムワークフローデザイナー」エクスペリエンスがすべてのアカウントでデフォルトになりました。従来のデザイナーに戻すための切り替えリンクは表示されなくなりますが、管理者には必要に応じて以前のエクスペリエンスへのアクセスを再び有効にする機能が引き続き用意されています。この更新により、移行期間中に管理者コントロールを保持しながら、モダンワークフロー設計インターフェイスへの移行が進められます。
利用可能な環境:サンドボックス、商用、政府 |利用可能なサービス階層: Acrobat Sign Solutions |設定範囲:アカウントとグループ
REST API/Webhook のアップデート
以下のアップデートは、情報開示の目的でプレリリースノートに記載されています。API および Webhook のアップデートに関する完全なドキュメントは、バージョンのアップデートが本番サーバーに送信されるときに Acrobat Sign 開発者向けドキュメントで確認できます。
- Webhook 用 mTLS キーの管理 – Acrobat Sign で生成されたキーオプションを追加し、証明書署名ワークフローを有効にすることで、セキュリティコンプライアンスが向上
開発者が、Acrobat Sign で webhook mTLS 認証用の秘密鍵の管理方法を選択できるようになりました。お客様が独自の秘密鍵と証明書を生成してアップロードする既存のモデルに加えて、Acrobat Sign が秘密鍵と証明書署名要求(CSR)を生成できるようになりました。お客様は CSR を使用して認証局から証明書を取得し、それをアップロードして設定を完了できます。このオプションでは、既存の webhook mTLS 動作との互換性を維持しつつ、秘密鍵を Acrobat Sign 内に保持することから、セキュリティが向上します。
利用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:v6 REST API POST/webhook エンドポイント、すべての範囲
更新された mTLS ドキュメントを確認したい場合はこちら >
- Login_hint パラメータによるデジタル ID の初期化 – API 送信者が受信者固有のログイン識別子を使用して、デジタル ID 認証を初期化することを許可します。
複数の v6 REST API/agreements エンドポイントで、loginHint パラメーターがサポートされるようになりました。これにより、API 送信者はメールアドレスやユーザー ID 番号などの既知のログイン識別子を使用してデジタル ID ゲートウェイ認証を初期化できます。アイデンティティプロバイダーがユーザーエクスペリエンスを制御しますが、識別子は通常ログイン画面に事前入力され、高信頼認証ワークフローを強化し、なりすましリスクを軽減します。 識別子は、機密データを保護しながらトレーサビリティを維持するため、デジタルアイデンティティゲートウェイのランディングページと監査レポートにマスク形式で表示されます。
以下のエンドポイントが、loginHint パラメーターを含むように更新されました。- POST /agreements
- PUT /agreements/{agreementId}
- PUT /agreements/{agreementId}/participantSets/{participantSetId}/participants/{participantId}/securityOptions
- GET /agreements/{agreementId}
- GET /agreements/{agreementId}/members/participantSets/{participantSetId}
- GET /agreements/{agreementId}/participantSets/{participantSetId}/participants/{participantId}/securityOptions
- GET /agreements/{agreementId}/members
利用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:v6 REST API
- OEM 2.0 Identity and Trust Boundary Enhancements – User resolution now prioritizes users provisioned by the same partner and automatically creates a recipient when no match is found
Agreement participant resolution now prioritizes users provisioned by the same partner and automatically creates a recipient record when no matching user exists, ensuring consistent identity handling across accounts. Audit reports now indicate whether a sender is partner-provisioned or a personal account, and signer flows guide users to switch accounts when identical email addresses exist across different account types, reducing confusion and preventing unintended access.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: v6 REST API; OEM 2.0 Partner
リリースの正誤表
以下は、プレリリースノートの最初の公開以降にこのリリースに追加された項目です。
- Phone Transaction Usage Reporting – Expanded reporting with group-level visibility and scheduled report access
Phone transaction reporting now provides visibility into purchased quantities, quota start dates, and detailed consumption across SMS and WhatsApp transactions. Customers can track usage at the group level and access scheduled CSV reports through a unified reporting experience, enabling more accurate budgeting, internal allocation, and proactive monitoring to prevent service disruption when transaction limits are reached.
Reporting is now generated through scheduled reports in the reporting interface, with API access available to retrieve the latest report output.
New endpoint: POST /api/rest/v6/reportDownload
This endpoint accepts a scheduleId and returns the download URL for the most recently generated CSV report associated with that schedule.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: v6 REST API
- Agreement Expiration Window – Extended default expiration period to 365 days
The maximum completion deadline for agreements has been extended from 180 days to 365 days. When document expiration is enabled, agreements are now automatically assigned a 365-day expiration date that cannot be removed. This change ensures all agreements have a defined lifecycle, improves long-term tracking and compliance, and reduces the risk of agreements remaining open indefinitely while still allowing users to set earlier deadlines when needed.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: Account and Group
- OEM 2.0 Identity and Trust Boundary Enhancements – User resolution now prioritizes users provisioned by the same partner and automatically creates a recipient when no match is found
Agreement participant resolution now prioritizes users provisioned by the same partner and automatically creates a recipient record when no matching user exists, ensuring consistent identity handling across accounts. Audit reports now indicate whether a sender is partner-provisioned or a personal account, and signer flows guide users to switch accounts when identical email addresses exist across different account types, reducing confusion and preventing unintended access.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: v6 REST API; OEM 2.0 Partner
- 新しいエクスペリエンスでの個人アドレス帳管理 – 新しい「署名を依頼」エクスペリエンスでは保存済みメールアドレスを個人アドレス帳で直接削除できるようになり、個人の受信者リストを正確かつ最新の状態に維持しやすくなっています。
利用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:デフォルトで有効、設定不可。
リリースの正誤表
以下は、以前に今回のリリースの一部として発表されていましたが、それ以降のリリース日にずれ込んだ項目です。
- Enhanced Resource hub – Reorganizes learning and support links within Acrobat Sign
The updated Resource hub improves how users access learning and support materials directly within Acrobat Sign. Content is organized into structured sections with embedded video tutorials and direct access to webinars, release notes, customer stories, and support resources. These updates make educational content easier to locate within the product experience.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: This updated experience is enabled by default
- Agreements API による通知制御 – POST /agreements エンドポイントと POST /agreements/{agreementId}/reminders エンドポイントにメール通知を無効にするマルチレベル制御が追加されました。
開発者は、v6 REST API を介して契約書を作成する際に、INITIAL、INTERMEDIATE、FINAL、CANCELLATION、REMINDER メール通知を無効にできます。このソリューションではリクエストの複数レベルで disabledNotificationTypes 配列が導入されており、役割ごとに対象を絞ってコントロールできます。- participantSetsInfo[].disabledNotificationTypes — 参加者セットのすべてのメンバーのメール通知を無効にする
- ccs[].disabledNotificationTypes — 個々の CC 受信者のメール通知を無効にする
- senderDisabledNotificationTypes — 契約書送信者のメール通知を無効にする
API レベルの senderDisabledNotificationTypes フィールドは、「
個人設定」で設定された送信者通知設定よりも必ず優先されます。
利用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:v6 REST API
- レポーティングでの受信者フィルター – レポートとデータエクスポートに受信者ベースのフィルタリングを追加します。
契約書およびトランザクションレポートとデータの書き出しのために、新しいレポートに受信者フィルターを追加します。 管理者は受信者メールでフィルタリングして、役割や署名順序に関係なく、指定された受信者を含むすべての契約書を返すことができます。 フィルターは、既存の送信者フィルターと一致するオートコンプリートおよび複数選択動作をサポートし、ビジュアルレポートと CSV 書き出しの両方に適用されます。
利用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:新しいレポートで有効化
- 新しい電子サインにおけるバイオ医薬業界標準対応(CFR)のサポート – 署名理由の取得と強制的な署名時再認証を追加
Acrobat Sign に署名理由の取得と署名時の強制的な再認証が追加され、新しい電子サインにおけるバイオ医薬業界標準対応のサポートが完成されました。規制環境で運営する組織は、署名理由を要求し、各署名または最終クリック署名時の再認証を強制し、準拠した監査レポートを維持できます。新しいインターフェイス内ですべての作業を実行できます。
使用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:バイオ医薬業界標準対応設定のサポートは、新しい電子サインでデフォルトで有効になっています。
- オーサリング中のインライン文書編集 – 送信者がオーサリングエクスペリエンス内で文書のテキストを直接編集できるようにする
送信者が署名用の契約書を送信する前に、オーサリングエクスペリエンス内で文書のテキストを直接編集できるようにします。 「文書を編集」オプションを使用すると、ユーザーは既存のフィールドと契約書設定を保持しながら、ファイルのダウンロードと再アップロードをすることなくテキストを変更できます。 これにより、送信前の修正作業を合理化し、契約書の準備中の中断を削減します。
使用可能な環境:サンドボックス、商用、官公庁 | 利用可能なサービスレベル:Acrobat Sign Solutions | 設定範囲:アカウントおよびグループ
- 顧客管理キー – AWS KMS または Azure Key Vault キーを使用した保存データの暗号化の有効化
顧客管理キーは、AWS Key Management Service(KMS)または Azure Key Vault で顧客管理キーを使用して、アカウントレベルの保存データの暗号化を実行します。 アカウント管理者は、顧客管理キーをオンボードしてサポートされているコンテンツを再暗号化し、キーバージョンを回転または復元し、キーを一時停止(暗号化および復号化操作を失敗させる)、またはキーを破棄して暗号化されたコンテンツへのアクセスを永続的に防ぐことができます。
使用可能な環境:サンドボックス、商用 | 利用可能なサービスレベル:AWS 環境での Acrobat Sign Solution | 設定範囲:アカウントのみ
- SMS Usage Reporting API – Retrieve purchased quantities and track SMS consumption
The SMS Usage Reporting API provides visibility into SMS entitlements and consumption to support budgeting and service continuity planning. Organizations can retrieve total purchased SMS quantities, track overall usage to date, and query consumption by group and date range. This enables proactive monitoring and internal allocation to prevent disruption when credits approach exhaustion.
New endpoints:- GET /api/rest/v6/smsUsage
- GET /api/rest/v6/smsUsage?groupId={groupId}
- GET /api/rest/v6/smsUsage?startDate=YYYY-MM-DD&endDate=YYYY-MM-DD
- GET /api/rest/v6/smsUsage?groupId={groupId}&startDate=YYYY-MM-DD&endDate=YYYY-MM-DD
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: v6 REST API
- Modern Request Signature becomes default – Retire Classic Compose, remove switch controls, standardize signing experience
All accounts are now transitioned to the modern Request Signature experience, replacing the classic Compose interface. Switch links and admin controls to revert to the classic experience are removed for commercial accounts, while GovCloud accounts are also transitioned with temporary retention of admin controls. This change standardizes the sending experience across environments and simplifies user onboarding ahead of full Classic retirement.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Sign Solutions | Configuration scope: Not configurable
- Modern Create Template becomes default – Promote new authoring experience, expand rollout, maintain admin controls
The modern Create Template experience is now the default for all accounts, including those that share assets across multiple groups. This update expands the rollout of the new authoring interface, ensuring all users benefit from ongoing enhancements, while retaining admin controls to revert to the classic experience if needed.
Available environments: Sandbox, Commercial, Government | Available tiers of service: Acrobat Standard, Acrobat Pro, Acrobat Sign Solutions | Configuration scope: Account and Group
解決された問題
| Issue | Description |
|---|---|
| 4520028 | Summary: The Group column on the Manage page displayed incorrect or inconsistent values when users belonged to multiple groups. Changing the user’s primary group caused agreements to show the wrong group, including the last selected primary group or multiple groups, instead of the group the agreement was originally sent from. |
| Fix: Updated the Manage page logic to use the agreement’s sending group (agreement_group_id) instead of the user’s current primary group when rendering the Group column. | |
| 4532690 | Summary: Users could not edit draft agreements created from custom workflows when both “Enable agreements to only be sent by using a workflow” and “Enable new Custom Workflow send experience” were enabled. The system incorrectly blocked access to the compose page when editing an existing draft, treating it as a new send action instead of a draft edit. |
| Fix: Updated the Compose page logic to detect draft editing scenarios and bypass the workflow restriction check, allowing users to edit existing draft agreements created from custom workflows. | |
| 4536764 | Summary: Sending agreements through a custom workflow resulted in a server error due to a failure processing specific template PDFs. The error was caused by invalid or missing annotation appearance data in one or more source documents, which triggered a rendering exception during prefill. The issue was not consistently reproducible and could not be replicated outside the affected workflows. |
| Fix: Improved handling of rendering exceptions in the PDF processing layer. | |
| 4537197 | Summary: When using the new Send in Bulk experience with manually entered recipient names, the second name field was removed during signing due to incorrect handling of required recipient name data across documents. |
| Fix: Updated document processing logic to correctly retain all recipient name fields when sending agreements in bulk. | |
| 4538172 | Summary: Copying workflows that include recipient groups failed during Sandbox Sync with an “Error executing request” message due to invalid recipient group references. The workflow used environment-specific recipient group IDs, which are not portable across environments, causing validation to fail during sync. |
| Fix: Updated Sandbox Sync handling to correctly validate and process recipient group references during workflow copy operations, preventing failures when recipient groups exist in both environments. | |
| 4538251 | Summary: In the new Send in Bulk experience, fullname and email signer info fields did not appear during signing or in the final document when the source file contained existing AcroForm fields. The issue was caused by incorrect handling of merge field data when combining signer info fields with pre-existing form fields, resulting in the fields not being rendered in child agreements |
| Fix: Updated merge and form field processing logic to correctly apply signer info fields in documents that include existing AcroForm fields. | |
| 4545485 | Summary: Agreement creation intermittently failed when thumbnail generation encountered malformed PDF form fields. The failure was caused by source documents containing form fields without valid names and invalid nested field structures, which triggered processing errors during PDF generation. |
| Fix: Added validation and null checks during PDF processing to handle malformed form fields and prevent failures during thumbnail generation and agreement creation. | |
| 4545814 | Summary: Fields are misaligned and text tags remain visible when processing landscape-oriented documents generated from XDP-based workflows. Incorrect coordinate calculations in landscape layouts cause improper field placement and prevent text tags from being properly parsed and removed. |
| Fix: Updated the field rendering logic to correctly calculate and place form fields in landscape-oriented documents, ensuring proper alignment and removal of text tags during processing. | |
| 4545978 | Summary: Accented characters in signer names render incorrectly in the visible signature block when using local digital signing. The issue occurs because the default font embedded in the document lacks proper encoding for Western European characters, causing incorrect character substitution during signature appearance rendering. |
| Fix: Updated the embedded font configuration to include proper encoding for accented characters, ensuring correct rendering of signer names in the signature appearance | |
| 4547100 | Summary: Cloned multiline text fields render inconsistently in the signed PDF. Multiline clone fields are missing the default appearance dictionary, which causes cloned fields to display fewer lines than the source field even when both fields use the same size and settings. |
| Fix: Added the default appearance dictionary to multiline cloned fields so cloned and source fields render consistently in signed documents. | |
| 4548305 | Summary: The onboarding checklist shows “Request BAA for HIPAA readiness” as Pending even when HIPAA is enabled. The checklist evaluation logic incorrectly treats inherited HIPAA-related settings as incomplete, causing the task status to remain Pending despite the feature being enabled. |
| Fix: Updated checklist evaluation logic to correctly interpret HIPAA-related settings, including inherited values, so the onboarding task reflects the completed state when HIPAA is enabled. | |
| 4550731 | Summary: A large gap appears between the signature underline and timestamp when signing documents using Fill & Sign. The issue occurs when the signature field is not wide enough to accommodate the rendered signature content, causing incorrect spacing in the signature appearance |
| Fix: Updated signature rendering to respect the defined field dimensions and adjust spacing appropriately, reducing the gap between the underline and timestamp. | |
| 4550906 | Summary: The Change Password link points to an invalid URL for certain users, causing a browser error. The issue occurs when the application reads an outdated endpoint from configuration instead of the correct URL, leading to inconsistent behavior across environments. |
| Fix: Updated the configured password change endpoint to use the correct URL across affected environments. | |
| 4550992 | Summary: Editing certain templates in the new experience redirects to the Create Template page instead of opening the template in edit mode. The issue occurs because the system determines the experience based on the template owner’s settings rather than the current user’s settings, causing incorrect routing when editing shared templates. |
| Fix: Updated template editing logic to use the current user’s experience settings instead of the template owner’s settings, ensuring templates open in the correct edit mode. | |
| 4551756 | Summary: Approval request emails display unresolved template variables in the recipient field, causing incorrect email formatting. The issue occurs due to a failure in the email template rendering logic when generating entitlement conflict notifications. |
| Fix: Updated email template rendering to correctly resolve and populate recipient fields, ensuring valid email addresses are displayed in approval request emails. | |
| 4551768 | Summary: Signers encounter an unhandled error when accessing or completing agreements due to a failure in form field appearance processing. A malformed appearance object causes a ClassCastException during document generation, leading to agreement rendering failure. |
| Fix: Updated form field processing logic to validate appearance object types before casting, preventing exceptions and ensuring agreements render correctly for signing. | |
| 4552272 | Summary: Cancelled or abandoned agreements appear under Waiting for you on the Manage page. The issue occurs when a workflow restart event does not properly clean up participant status data, leaving stale visibility and indexing data that surfaces the agreement in incorrect views |
| Fix: Updated workflow restart handling and indexing logic to correctly clear prior participant status data and ensure agreements appear only in their correct state. | |
| 4553158 | Summary: In RTL language environments on iOS, the signature panel does not respond correctly when drawing a signature. The panel scrolls instead of capturing input, requiring users to manually scroll to draw and apply the signature, which prevents normal signing behavior when the new recipient signature experience is enabled. |
| Fix: Updated signature panel interaction handling for RTL layouts on iOS to correctly capture drawing input without unintended scrolling, enabling normal signature creation and application. | |
| 4553583 | Summary: Workflows allow email addresses with leading or trailing spaces, which causes agreements to fail silently when sending in the new experience. The system does not validate or normalize the input, and no error message is shown to indicate the issue. |
| Fix: Updated input handling to automatically trim whitespace from email addresses and prevent saving invalid values, and added handling for existing workflows so agreements can be sent successfully. | |
| 4553676 | Summary: Hyperlinks display incorrectly in the Manage view, where the agreement title is appended to the URL, resulting in broken links. The issue occurs due to incorrect URL parsing when rendering hyperlinks in the Manage interface. |
| Fix: Updated hyperlink rendering to use proper URL parsing, ensuring links remain unchanged and function correctly across all views. | |
| 4555021 | Summary: OTP validation fails with an “expired” error even when the code is entered immediately. The issue occurs due to a race condition in the authentication flow, where multiple submission events cause the OTP to be invalidated prematurely. |
| Fix: Updated OTP validation flow to handle duplicate or rapid submission events correctly, preventing premature expiration and allowing valid OTP entries to succeed. | |
| 4555028 | Summary: Removing the next recipient to sign can fail with a system error and leave the agreement stuck in a pending revision state. The issue occurs when the recipient has an active reminder, which prevents the agreement update from completing successfully. |
| Fix: Updated recipient removal logic to handle cases where the next signer has active reminders, allowing the agreement update to complete without errors. | |
| 4555319 | Summary: Web form creators see only Type and Draw signature options when previewing the form, while signers see all available options (Type, Draw, Image, Mobile). The issue occurs because the preview mode does not correctly apply enabled signature input settings when the creator is not acting as a signer. |
| Fix: Updated web form preview behavior to apply the full set of enabled signature input types, ensuring creators see the same signature options as signers. | |
| 4555345 | Summary: Agreements with multiple Signer with Witness recipients fail to open in Preview from Draft with the error “ParticipantSetsInfo cannot be modified.” The issue occurs due to incorrect participant and witness ordering logic in custom workflows, which prevents the agreement from transitioning back to the authoring state |
| Fix: Updated participant and witness ordering logic in custom workflows to correctly calculate execution order, allowing agreements to return to the authoring state and proceed normally. | |
| 4555615 | Summary: Webhook event payloads for delegated and replaced recipients do not include the privateMessage field. The issue occurs because the private message is not propagated to the recipient state used to generate webhook payloads, resulting in missing data for affected events. |
| Fix: Updated participant data handling to ensure private messages are included in webhook payloads for delegated and replaced recipients. | |
| 4555687 | Summary: Agreements can be auto-cancelled and moved to a hidden state after signing due to a document visibility validation failure. When a participant is delegated or replaced, the document visibility mapping is not correctly transferred, causing a mismatch between assigned fields and visible documents, which can trigger an automatic cancellation. |
| Fix: Delegation and replacement logic now correctly clone document visibility mappings for new participants, preventing validation failures and unintended agreement cancellation. | |
| 4556516 | Summary: Form fields can ignore configured font sizes and render inconsistently in generated agreements. The issue occurs in multiline fields when the document processing engine adjusts font size to prevent text clipping, overriding fixed font size settings. |
| Fix: Updated font rendering behavior so multiline fields respect fixed font size settings, aligning behavior with expected output and preventing unintended size adjustments. | |
| 4556967 | Summary: Selected checkboxes can appear unselected in the finalized signed PDF for web forms. The issue occurs when certain hidden values (for example, “no”, “false”, “0”, “off”, “unchecked”) are used, which can cause checkbox states to be misinterpreted during document processing when Gibson is enabled. |
| Fix: Updated checkbox processing to correctly interpret hidden values and preserve selected states in the finalized document, ensuring consistency between signing and the signed PDF. | |
| 4557222 | Summary: Link fields from field templates can disappear on the authoring page when used within a workflow. The issue occurs because link fields are not included in the agreement form field data returned during workflow-based authoring, resulting in missing fields. |
| Fix: Updated form field handling to include link fields from field templates during workflow processing, ensuring they are correctly merged and displayed on the authoring page. | |
| 4557272 | Summary: The Date of Signing field can fail to appear in the finalized signed PDF. The issue occurs when text field rendering fails during document processing, preventing the date field from displaying in the output document. |
| Fix: Updated text field rendering to handle null or empty values correctly, ensuring the Date of Signing field is consistently displayed in signed documents. | |
| 4557282 | Summary: Radio button fields in web forms can display an unexpected tooltip value (“object Object”) when created using the new template experience. The issue occurs due to incorrect handling of empty tooltip values, causing placeholder data to be rendered instead of being suppressed. |
| Fix: Updated tooltip handling logic to properly ignore empty values, preventing unintended placeholder text from appearing in web forms. | |
| 4557589 | Summary: Prefilled checkbox fields can appear unchecked when the agreement is sent for signature. The issue occurs when duplicate or conflicting hidden values are defined for checkbox or radio inputs, which can cause incorrect interpretation of the selected state during document processing. |
| Fix: Updated field value handling to correctly process hidden values and preserve prefilled selections, ensuring checkbox states remain consistent when agreements are generated and sent. | |
| 4557672 | Summary: The new request signature experience can display a generic error (“The request provided is invalid”) when sending an agreement, without identifying the specific field causing the failure. This can occur when recipient details (such as phone number format) fail validation, but the error is not surfaced clearly to the user. |
| Fix: Updated validation handling to provide specific, field-level error messages, helping users identify and correct invalid inputs before sending the agreement. | |
| 4557680 | Summary: Checkbox or radio button mappings can fail in some agreements when combining multiple documents, resulting in expected values not being applied. The issue occurs when default values do not exactly match defined export values, which can cause fields to be treated as separate groups and break mapping behavior. |
| Fix: Updated field mapping logic to ignore mismatched default values and correctly associate fields across documents, improving consistency of checkbox and radio button behavior. | |
| 4557902 | Summary: An extra gap can appear between the signature and the date and time stamp in Fill and Sign agreements. The issue occurs due to incorrect spacing calculation in well-formatted signatures, leading to inconsistent layout compared to other signing flows. |
| Fix: Updated signature layout calculation to correctly position the signature and timestamp, removing unintended spacing and ensuring consistent formatting. | |
| 4557947 | Summary: Checkbox fields can appear unchecked in the finalized signed PDF when using library templates, even though the signer selected them. The issue can occur when checkbox fields are misconfigured or use certain hidden values, which leads to incorrect interpretation of the selected state during document processing. |
| Fix: Updated checkbox processing to correctly interpret hidden values and preserve selected states, ensuring checkbox selections are retained in the signed document. | |
| 4558295 | Summary: Required radio button values can be missing in the finalized signed PDF. The issue can occur when field values contain special characters (for example, quotes or symbols) that are not properly processed, leading to the selected value not rendering in the document output. |
| Fix: Updated field value processing to correctly handle special characters, ensuring selected values are preserved and displayed in the signed PDF. | |
| 4558307 | Summary: Form fields can ignore configured font sizes and render inconsistently in generated agreements. The issue can occur in multiline fields when the document processing engine adjusts font size to prevent text clipping, overriding fixed font size settings. |
| Fix: Updated font rendering behavior so multiline fields respect fixed font size settings, preventing unintended resizing and ensuring consistent output. | |
| 4558554 | Summary: Signers can complete agreements without interacting with the Signature Block. The issue can occur in Gibson-enabled accounts when the Signature Block is not properly rendered or enforced during signing, allowing completion with only the Signature Field. |
| Fix: Updated signature rendering and validation logic to ensure Signature Blocks are correctly displayed and required before agreement completion. | |
| 4558725 | Summary: Text tags can fail to render or convert into form fields during preview. The issue can occur when the uploaded PDF contains unsupported or invalid elements (for example, null annotations or existing fillable fields), which prevent text tag processing from completing successfully. |
| Fix: Updated text tag processing to handle PDFs with invalid or unsupported annotations more reliably, allowing fields to be generated as expected during preview. | |
| 4559285 | Summary: Phone authentication can fail for certain regions when selecting a country code in the new request signature experience. The issue occurs when the UI displays an incomplete or incorrect country code (for example, “+1” instead of “+1246” for Barbados), which can cause validation errors when sending the agreement. |
| Fix: Updated country code handling to use the correct full dialing codes, ensuring phone numbers are validated and processed correctly in the new experience. | |
| 4560119 | Summary: Text in form fields can appear misaligned or overlap in generated agreements. The issue can occur in multiline text fields when rendering differences are introduced by the document processing engine, leading to layout shifts compared to the authoring view. |
| Fix: Updated text rendering and layout handling for multiline fields to improve alignment and prevent overlapping, ensuring more consistent display between authoring and final documents | |
| 4562058 | Summary: The recipient name can remain unchanged when selecting a different email from the address book on the Send page. The issue occurs because the name field does not refresh when a new contact is selected, causing a mismatch between the displayed name and selected email. |
| Fix: Updated recipient selection behavior so the name field always refreshes when a new contact is selected, ensuring the name and email remain synchronized. | |
| 4566339 | Summary: Incorrect checkbox states can appear when processing static XFA PDFs with malformed field values. The issue can occur when unsupported or invalid XFA data (for example, string values in numeric fields) is handled inconsistently, particularly in Gibson-enabled environments where checkbox defaults can be misinterpreted. |
| Fix: Updated XFA handling in the document processing pipeline to normalize or ignore malformed values more consistently, preventing incorrect checkbox states and aligning behavior across environments. | |
| 4567278 | Summary: Read-only text fields can fail to appear on the signing page when dynamic participants are enabled. The issue occurs due to field rendering inconsistencies during participant resolution, which can cause non-editable fields to be omitted from the signer view. |
| Fix: Updated field rendering logic for dynamic participants to ensure read-only fields are consistently included and displayed during signing. | |
| 4568023 | Summary: Image and Mobile signature options can fail to appear in web forms during signing. The issue can occur due to inconsistent loading of signature options in the web form entry flow, where certain signing methods are not surfaced until the session is reloaded or accessed through an alternate path. |
| Fix: Updated web form signing initialization to consistently load all enabled signature options, ensuring Image and Mobile methods are available across all entry points. |