メインコンテンツへスキップ
ユーザーがドキュメントをアップロードし、誰にでもそのドキュメントへの署名を依頼できるドキュメント管理アプリを想像してみてください。この場合、アプリは、署名対象のドキュメントと署名する必要がある人を認識しますが、署名やそのプロパティ (名前、日付、イニシャルなど) を配置する場所は認識しません。 これは、テンプレート構造化されたドキュメントを使用する場合とは対照的です。これらを使用する場合、アプリは、署名プロパティの内容や場所を認識します。 このような場合、各ドキュメントに異なる構造を使用できるため、常にis_document_preparation_neededフラグをtrueに設定することをお勧めします。これにより、署名者がリクエストを受け取る前に、送信者は署名プロパティを選択してドキュメントに配置できるようになります。 このフローには、署名リクエストの作成、ドキュメントの準備、署名という3つのステップがあります。フローは次のようになります。 非構造化ドキュメントへの署名フロー 次の例を考えてみます。
これの結果、ドキュメント準備のURL (簡略化されています) を含む署名リクエストが作成されます。
上記のスクリプトでは、ドキュメント準備のURLが署名リクエストによって生成された場合、アプリによってそのURLのためにブラウザが開くことに注意してください。その後、リクエスト送信者は、次のようにさまざまな署名プロパティを適用できます。
テンプレートエディタでドラッグアンドドロップを使用してドキュメントを準備する
ドキュメントが準備できたら、リクエスト送信者は署名リクエストを署名者に送信できます。 Boxアプリに戻ると、ステータスがIn Progressになっていることがわかります。
保留中の署名リクエスト
その後、署名リクエストへのリンクが記載されたメールがBoxから署名者に送信されます。
ドキュメントに署名する
処理が完了すると、メタデータを含む署名ログと署名済みドキュメントの両方が保存先フォルダに格納されます。
ログと署名済みドキュメント
最終更新日 2026年3月20日