ユーザーが複数のグループから契約書を送信できるようにすることで、管理者はライブラリテンプレート、受信者認証、署名要件を 1 つのグループに厳密に関連付けることができ、ワークフローでグループ内のユーザーではなくグループの性質を定義できます。
概要
契約書を作成すると、使用可能なアセット（テンプレート／ワークフロー）とシステムによって提供される契約書のプロパティ（ブランディング、受信者の役割、認証方法、PDF のセキュリティ／保持など）を主に指定するグループレベルの設定になります。
1 つのグループにロックされていると、個々のユーザー ID は、1 つのデフォルトセット、1 つのテンプレートとワークフローの配列、および 1 つの署名コンプライアンスの概念にロックされることになります。
ユーザーが複数のグループにアクセスできるようにすると、管理者はグループをユーザーの複数のコレクションと考えることができます。グループは、ユーザーにアクセス権を付与する特定の文書署名要件の環境として表示できます。
例えば、1 つのグループを非常に厳格なコンプライアンス関連の署名と配布ルールのセットを中心に設計し、もう 1 つのグループを内部の厳密でない認証ワークフローとテンプレート用に設定することもできます。両方のグループに割り当てられたユーザーは、各グループのすべてのリソースにアクセスできます。
グループレベルの管理者は、複数のグループを管理することもできます。これにより、グループレベルの管理者の役割の実用性が向上します。
この文書では、UMG がもたらすユーザーのインターフェイス／機能への変更に重点を置いて説明し、管理者が UMG に移行する際に必要な考慮事項を特定します。
前提条件
- 複数のグループユーザーを有効にできるのは、エンタープライズおよび法人レベルのアカウントのみです
- ネットワークセキュリティが Acrobat Sign エンドポイントへのアクセスを明示的に許可していることを確認します
- カスタムワークフロー、ホーム、および管理インターフェイスの最新バージョンがアカウントで有効になっている必要があります
- アカウントを切り替えて複数のグループユーザーを許可すると、新しいバージョンのページが自動的に有効になり（まだ有効になっていない場合）、従来のインターフェイスに戻すオプションが無効になります。 これには「切り替え」リンクが含まれます
- 従来のワークフロー／ホーム／管理ページは、複数のグループユーザーと互換性がありません
- UMG を元に戻しても、ホーム／管理はリセットされません
- アカウントを切り替えて複数のグループユーザーを許可すると、新しいバージョンのページが自動的に有効になり（まだ有効になっていない場合）、従来のインターフェイスに戻すオプションが無効になります。 これには「切り替え」リンクが含まれます
- Acrobat Sign でサポートされている統合、カスタム API 開発、開発者アカウントでのサードパーティ統合をレビューして、機能を確認します
プライマリグループ
UMG ルールの下にあるすべてのユーザーは、「プライマリグループ」に割り当てられます。 プライマリグループは次のとおりです。
- ユーザーが送信ページに移動したときに読み込まれるデフォルトのグループ
- 契約書が電子メールアドレスに送信される場合、ユーザー ID 署名の権限／パラメーターを定義するグループ
- グループレベルの設定が必要で、要求しているソースが UMG に未対応の場合に参照されるグループ
- 例：Acrobat Sign の統合は複数のバージョンにまたがることができます。UMG に対応していない古いバージョンでは、参照するためのデフォルトが必要であり、それがプライマリグループになります
- 例：Acrobat Sign の統合は複数のバージョンにまたがることができます。UMG に対応していない古いバージョンでは、参照するためのデフォルトが必要であり、それがプライマリグループになります
オブジェクトと継承（親子オブジェクト）
「オブジェクト」とは、1 つのアイデアを表すプロパティのコレクションを表す用語です。アカウント は、ユーザーと同様に、オブジェクトのタイプです。
Acrobat Sign などのアプリケーション内では、オブジェクトをテンプレートとして使用して他のオブジェクトを作成できます。また、1 つのオブジェクトを「テンプレート」オブジェクトから作成する場合、これらの 2 つのオブジェクトには親子関係があると言います。
子オブジェクトは親の直接のコピーであるため、設定は同じです。 子オブジェクトは、親のプロパティ値を継承します。親の値が変更されると、その変更は子にも継承されます。
Acrobat Sign の 1 つのオブジェクトツリーは、アカウント／グループ／ユーザーのプロパティのグループです。
- グループはアカウントの子オブジェクトであるため、すべてのグループはそのアカウントのプロパティを必然的に継承します
- すべてのユーザーは、グループの子オブジェクトと見なされるため、所属するグループのプロパティを継承します
アカウント／グループ／ユーザーのオブジェクトのチェーンを観察すると、1 人のユーザーを新しいグループに移動した場合に、グループから継承された新しいパラメーターにより、ユーザーの「デフォルト」機能がどのように変更されるかを簡単に確認できます。
子オブジェクトのプロパティ値を変更することは許可されています。この明示的な変更により、通常、親オブジェクトからのプロパティ値の継承が解除されます。親オブジェクトがこのようなプロパティの値を変更しても、明示的に設定された値が優先されるため、子は新しい値を継承しません。
これは、グループレベルの管理者がグループのアカウントレベルの設定を上書きする場合に最もよく見られます。また、グループ内のユーザーは、所属するグループの子オブジェクトであるため、ユーザーエクスペリエンスはそれに応じて変更されます。
複数のグループにアクセスできるユーザーでは、作業しているグループを変更すると、継承されたプロパティが変更されます。ユーザーが送信ページでグループを変更すると、ページが更新され、新しいグループレベルのプロパティが読み込まれます。これは、グループごとに独自のロゴブランディングを使用している場合に非常によくわかります。
オブジェクト ID
表に見えない部分で、各オブジェクトには、固有の識別番号があります。 この一意の ID は、アプリケーションが類似したタイプのオブジェクトを区別し、オブジェクトを相互に関連付ける方法です。
UMG ルールでは、特にレポートに関して、ユーザー ID とグループ ID の影響がより明確になります。ユーザーがシステムでアセット（契約書、テンプレート、Web フォーム）を作成すると、作成者のユーザー ID とアセットが作成されたグループ ID がアセットにエンコードされます。
ユーザーが契約書のレポートを作成すると、そのユーザー ID に関連するデータが返されます。グループ ID は検索には関係ありません（フィルターが適用されていない場合）。
ただし、グループ管理者がグループのレポートを作成すると、アプリケーションはグループ ID に関連するデータを返します（作成したユーザー ID に関係なく）。
ユーザーが 1 つのグループにしか存在できなかった場合、一般的に観察すべき違いはありませんでした。ユーザーが複数のグループにアセットを作成する場合、1 つのユーザーのコンテンツが複数のグループレベル管理者のグループにまたがることができます。
グループレベルの管理者は、権限を持つグループ ID 内で生成されたコンテンツにのみアクセスできます（個人的に作成したコンテンツを除く）。グループ管理者が 1 つのユーザー ID のコンテンツのレポートを作成した場合、返されるデータセットには、管理者であるグループ内のコンテンツ（そのユーザー ID によって作成されたもの）のみが含まれます。
アセットのグループ提携
UMG を有効にする前に作成された契約書、Web フォーム、および一括送信イベントは、ユーザー ID の作成にのみに関連付けられます。
UMG を有効にした後に作成された契約書、Web フォーム、および一括送信イベントは、作成されたグループ ID およびそれらを作成したユーザー ID にのみに関連付けられます。
つまり、UMG を有効にする前に作成されたアセットは、ユーザーのプライマリグループを変更した場合に、そのユーザーと共に移動されます。ユーザーが共有グループから移動されると、（アカウントの共有を通して）グループを表示しているユーザーは、これらのアセットを表示できなくなります。
UMG を有効にした後に作成されたアセットは、グループに関連付けられたままになります。グループを表示しているユーザーは、作成したユーザーが新しいプライマリグループに移動した後も、グループで作成されたアセットを引き続き表示することができます。
複数のグループユーザーを使用するオプションを有効にする方法
UMG の有効化または無効化は、アカウントレベルの管理者のみがおこなうことができます。アカウントをアップグレードする手順については、この記事を参照してください。
UMG から元に戻した場合、次のような主な効果があります。
- すべてのグループレベルの管理者フラグがクリアされます
- アカウントレベルの管理者フラグは影響を受けません
- グループレベルの管理者は、専用グループに権限を再度付与することができます
- すべてのユーザーは、自分のプライマリグループ内にのみ存在します
ユーザーは最大 100 グループまでメンバーシップを持つことができます。
ユーザーレベルの違い
ユーザーレベルの変更はあらゆる場所で発生します。Acrobat Sign にログインできるすべてのユーザーは、以下の変更を確認できます。
違い：
ユーザーのプロファイルは、ユーザーが含まれるすべてのグループを完全に公開し、特にプライマリグループにフラグを付けます。
UMG が有効な場合：
- ユーザーがメンバーになっているすべてのグループが一覧表示されます
- 最初に表示されるグループは、常にプライマリグループです
違い：
ユーザーは複数のグループにアクセスできるため、ユーザーが使用できるテンプレートとワークフローは、テンプレート／ワークフローが関連付けられているグループでグループ化されます。
- テンプレートとワークフローは、1 つのグループまたはアカウント全体にのみ関連付けることができます
- アカウントレベルのテンプレート／ワークフローは、グループのリストの下部にある独自のセクションにも表示されます
- このメニューからテンプレート／ワークフローを起動すると、関連するグループ値が自動的に適用された状態で送信（作成）ページが読み込まれます
- 送信元セレクターは、テンプレート／ワークフローが関連付けられているグループの値にロックされます
グループレベルのテンプレートが使用されている場合は、グループが送信ページに挿入され、グループを編集するオプションが無効になります。
アカウントレベルのテンプレートが使用されている場合、グループは（ユーザーがメンバーになっているグループから）選択可能です。
違い：
送信ページの上部に送信元
ドロップダウンセレクターが表示されます。送信者は、このセレクターから、トランザクションのプロパティとオプションを管理するグループ（および関連するすべてのグループレベルのプロパティ）を選択できます。
- 送信元ドロップダウンフィールドでは、ユーザーは、明示的に追加され、送信権限が付与されているグループを選択するためのアクセス権のみが付与されます
- ユーザーが送信ページにアクセスしたとき、プライマリグループは常にグループのデフォルト（読み込み済み）値になります
考慮事項:
最初に送信元セレクターを設定します。
- セレクターを変更すると、次のようなグループレベルの設定が適用されます。
- ブランディング
- 許可される認証タイプ
- 署名の制限
- 共有ライブラリテンプレートおよびワークフローオプション
- メッセージテンプレート
- 送信元セレクターを変更すると、Web ページが新しいグループ設定で強制的に再読み込みされるため、追加されたフィールドレベルのコンテンツは更新時に失われます。
- 一度契約書が送信されると、送信元のグループは変更できません。
違い：
送信ページと同様に、自己署名ページには、ページの上部にグループを選択ドロップダウンセレクターが表示されます。
このセレクターを使用すると、送信者は、トランザクションのプロパティとオプションを管理するグループ（および関連するすべてのグループレベルのプロパティ）を選択できます。
- ユーザーは、自分が明示的に追加されたグループにのみアクセスできます
- ユーザーが送信ページにアクセスしたとき、プライマリグループは常にグループのデフォルト（読み込み済み）値になります
考慮事項:
最初に使用して送信セレクターを設定します。
- セレクターを変更すると、次のようなグループレベルの設定が適用されます。
- ブランディング
- 許可される認証タイプ
- 署名の制限
- 共有ライブラリテンプレートおよびワークフローオプション
- 使用して送信セレクターを変更すると、Web ページが新しいグループ設定で強制的に再読み込みされるため、追加されたフィールドレベルのコンテンツは更新時に失われます。
違い：
契約書の送信元グループを示す識別ラベルが契約書のコンテキストメニューに追加されました。
考慮事項:
一部の関数は、グループに強く関連しています（レポートパラメータや保持ルールなど）。
違い：
管理ページで作成される契約書のテーブルに列が追加されました。
- テーブルのグループヘッダーはクリックできません。データセットを並べ替えるには、フィルターを使用します。
違い：
新しいフィルターを使用して、管理ページのデータセットをグループでフィルタリングできます
- 一度に有効にできるグループフィルターは 1 つだけです
- 他のフィルターと同様に、グループフィルターが有効になっている場合は、フィルターボタンの左側に小さなタグが表示されます
- グループフィルターには、グループに共有されているテンプレートが含まれます
- 明示的なグループフィルターには、アカウントレベルの共有テンプレートが含まれます
- ユーザーは、現在メンバーになっているグループに対してのみフィルターを使用できます
- 「すべてのグループ」オプションは、ユーザーが現在メンバーではないグループで作成された契約書を含む唯一の「フィルター」です
違い：
ライブラリテンプレートを作成するときに、作成者はテンプレートアクセスプロパティを設定し、メンバーになっているグループと契約書を共有することができます。
- テンプレートは 1 つのグループにのみ共有できます。
- テンプレートをこの方法でグループに共有すると、テンプレートとグループの間に強固な関係が確立されます。詳細の説明：
- グループへのアクセス権を持つ管理者は、「共有ライブラリタブ」を使用してテンプレートを編集できます
- ユーザーがグループから削除されても、テンプレートはグループのアセットとして残ります（新しいグループに明示的に再リンクされない限り）
- グループに共有されているテンプレートは、グループのメンバー（およびテンプレートの作成者）のみが使用できます
- テンプレートの作成者が、そのテンプレートが共有されているグループから退出した場合、次のようになります
- テンプレートの作成者は、グループとの提携がなくなっても、契約書を送信するアクセス権を持ち続けます（テンプレートの所有者として）
- テンプレートの作成者は、管理ページで契約書のプロパティを編集する権限／アクセス権を保持します
- グループは引き続きテンプレートにアクセスできます
- テンプレートの作成者は、グループとの提携がなくなっても、契約書を送信するアクセス権を持ち続けます（テンプレートの所有者として）
- テンプレートの作成者が、そのテンプレートが共有されているグループから退出した場合、次のようになります
- 作成したユーザーが（GDPR の削除により）アプリケーションから削除された場合、その契約書はグループのアセットとして保持できます
考慮事項:
すべてのグループへのアクセス権を持つ 1 人のユーザーを、中心的な文書管理者として使用できます。
Web フォームを作成する権限を持つユーザーは、自分のフォームを、メンバーになっている任意のグループに関連付けることができます。
- Web フォームは 1 つのグループにのみ関連付けることができます
- 関連するグループは、Web フォームの作成後には変更できません
- 「共有ライブラリ」タブでは Web フォームは表示されません
- 作成者がグループへのメンバーシップを失った場合、Web フォームはグループ関係を保持します
違い：
レポートページにフィルターが追加され、1 つ以上のグループに関連する契約書に限定されたレポートを作成できるようになりました。
- ユーザーがフィルターを適用するには、グループへのアクセス権を持っている必要があります
.csv レポートには、同じ送信者グループ列が引き続き表示され、1 人の送信者のグループが切り替えられたことを適切に追跡できます。
以前に契約書を送信したグループからユーザーを削除すると、ユーザーはそのトランザクションのレポートを作成できなくなります。
グループレベルの管理者の違い
これらのインターフェイスの変更は、アカウントの管理者のみが確認できます（アカウントレベルの管理者コントロールで許可されているため）。
グループレベルの管理者の役割は大幅に改善されています。1 人のユーザーが複数のグループの管理者になることができ、メンバーになっているすべてのグループの管理者になる必要はありません。
複数のグループに属するグループレベルの管理者は、より広範なチームの文書やワークフローをより適切に管理し、アカウントの完全なデータセットへのアクセス権を付与されなくても、複数のグループのコンテンツでレポートを作成できます。
違い：
ユーザーが複数のグループの管理者である場合、ワークフローと共有ライブラリは、グループ管理者のメニューオプションの最上位レベルから、各個別グループのサブメニューに移動されます。
UMG が有効になっている場合は、まずグループを選択し、グループ設定を開いて、グループ固有のメニュー項目と設定にアクセスする必要があります。
違い：
グループ管理者が複数のグループに対する管理権限を持っている場合、管理者はまず、設定するグループを選択する必要があります。
- 左側のパネルメニューリストから「グループ」を選択します
- 編集するグループをシングルクリックします（「グループ設定」リンクが表示されます）
- 「グループ設定」リンクをクリックします
違い：
グループレベルの管理者には、新しく作成したユーザーの契約書を強制的に表示するオプションがなくなりました。
- アカウントレベルの管理者は、引き続きこの権限を持っています
違い：
アカウントにユーザーを追加するには、まずグループを選択して、「グループ内のユーザー」メニューオプションにアクセスする必要があります。
個別のユーザーを作成する場合、選択したグループはそのユーザーのプライマリグループを定義します。
グループレベルの管理者には、ユーザーの作成後にプライマリグループを編集する権限はありません。
1 人 のユーザーを作成するプロセスは同じで、強制的にユーザーの契約書への共有を表示するオプションを除きます（上記を参照）。
考慮事項:
ユーザーを個別に作成する場合、作成プロセスの一部としてユーザーを複数のグループに含めるオプションを使用することはできません。
ユーザーが作成された後、グループ管理者はユーザープロファイルを編集して、ユーザーを複数のグループに含めて、送信権限を編集できます。
違い：
ユーザー ID が契約書に署名できるかどうかを判断する権限とユーザー ID の自動委任ルールをインストールする機能が、グループレベルの管理インターフェイスから削除されました。
- この権限は、UMG ルール下にあるアカウントレベルの管理者のみに存在します
グループレベルの管理者は、ユーザーのプロファイルから管理する各グループに対するユーザーのメンバーシップを許可または禁止する権限を持っています。
- ユーザーは、ユーザーのリストに表示されるには、グループ管理者に公開されている必要があります（作成または管理者権限により）
グループメンバーシップを追加するには：
- グループ／グループ内のユーザーページに移動します
- ユーザーをダブルクリックして、ユーザープロファイルを開きます
- グループメンバーシップヘッダーの右側にあるプラスアイコンをクリックします
- グループメンバーシップを追加ダイアログボックスが開きます
- ユーザーを追加する契約書を選択します
- 自分が管理者であるグループのみが選択可能です
- 「追加」をクリックします
- 追加するすべてのグループに対してこの手順を繰り返します
- 完了したら、「保存」をクリックします。
グループに新たに配置されたユーザーには、次の 2 つの権限値が採用されます。
- グループ管理者 - ユーザー ID にグループレベルの管理権限があるか。
- デフォルトは False です
- 送信可能 - ユーザー ID には、テンプレート／ワークフローにアクセスして、グループのプロパティプロファイルで契約書を送信する権限があるか。
- デフォルトは True です
必要に応じて、グループごとの値をオンまたはオフにします。
- 完了したら、「保存」をクリックします
グループレベルの管理者は、元のプライマリグループと新しいグループの両方に管理権限がない限り、ユーザー ID のプライマリグループを編集する権限を持ちません。
グループメンバーシップを削除する方法
グループメンバーシップからユーザーを削除するには：
- グループ／グループ内のユーザーページに移動します
- ユーザーをダブルクリックして、ユーザープロファイルを開きます
- 削除するグループをシングルクリックして、グループメンバーシップの削除アクションを表示します
- 「削除」リンクをクリックします
- 削除する追加のメンバーシップについて、この手順を繰り返します
- 「保存」をクリックします
ユーザーのグループメンバーシップがすべてのグループに対して無効になった場合：
- ユーザー ID はデフォルトグループに格納されます
- ユーザーのプライマリグループは、デフォルトグループに設定されます
Webhook を作成するグループレベルの管理者は、グループフィールド値を設定するときに自分が管理者である任意のグループを選択できます。
違い：
複数のユーザーを作成／アップデートするために使用される、アップロードされる .csv の形式が変更され、複数のグループおよびグループ固有の権限を持つユーザーに対応できるようになりました。 この最後に、UMG エクスペリエンスで次の 3 つの列が削除されました。
- グループ名 - 削除されました。グループ列に置き換えられました
- グループ管理者 - 削除されました。グループ列のステータス値に置き換えられました
- 送信可能 - 削除されました。グループ列のステータス値に置き換えられました
1 つの列グループ
が追加されました
グループレベルの管理者には、グループ列を使用してユーザーを操作する権限がありません。
- アカウントレベルの管理者のみが、ユーザーを一括で作成／アップロード機能を使用して、グループ間のプロパティ／アクセスを活用する権限を持っています
グループレベルの管理者が一括アップロードを使用して新しいユーザーを作成する場合：
- 各ユーザーは、管理者がプロセスを開始したグループに作成されます
- ユーザーのプライマリグループは、デフォルトでユーザーが作成されたグループに設定されます
- デフォルト値のグループレベルの設定に関係なく、各ユーザーは署名を許可されます
アップロードテンプレートにはグループ列が含まれているため、以下のコンテンツは通知目的で提供されます。
グループ列には、1 つ以上のグループ定義が含まれています。各グループ定義では、1 つのグループの名前の後に、1 つ以上のステータス値が角括弧で囲まれます。例：グループ名[ステータス]
- グループ名は、スペースを含む実際のグループ名と正確に一致します。例：デフォルトグループ
- グループ名[ステータス 1 ステータス 2] など、1 つのグループ定義に複数のステータス値を含めることができます
- ステータス値は角括弧で囲まれます
- グループ名には、角括弧を使用することもできます。この場合、ステータス値は最後の括弧文字列に含まれている必要があります。例：Sales [East Coast][ステータス1 ステータス2]
- グループ名とステータス値が入った左角括弧の間にスペースはありません
- グループ名には、角括弧を使用することもできます。この場合、ステータス値は最後の括弧文字列に含まれている必要があります。例：Sales [East Coast][ステータス1 ステータス2]
- ステータス値は、値の間を 1 つのスペースで区切られます
- ステータス値は角括弧で囲まれます
- セミコロンを区切り文字として使用して、複数のグループ定義を含めることができます（スペースなし）
- 例：グループ名[ステータス];その他のグループ[ステータス 1 ステータス 2 ステータス 3];最後のグループ[ステータス A ステータス B]
- グループ定義で使用できるステータス値は次のとおりです。
- プライマリ -ユーザーのプライマリグループとしてグループを定義します
- 送信 - ユーザーがグループから契約書を送信できるようにします
- 送信不可 - ユーザーがグループから契約書を送信できないようにします
- 管理者 - グループのグループレベル管理者としてユーザーを定義します
- 削除 - グループからユーザーを削除します
- ユーザーがすべてのグループから削除された場合、そのユーザーはデフォルトグループに属します
上記の例では、次のようになります。
- John@here.com は、次の 2 つのグループ定義で設定されます。
- デフォルトグループは、彼のプライマリグループであり、彼はグループレベルの管理者であり、契約書の送信が許可されています
- Engineering グループは、彼をグループレベルの管理者として定義し、契約書を送信できます
- デフォルトグループは、彼のプライマリグループであり、彼はグループレベルの管理者であり、契約書の送信が許可されています
- また、Fred@here.com は、次の 2 つのグループ定義で設定されます。
- Procurement グループは、彼をグループレベルの管理者として定義しますが、契約書の送信は無効にします
- さらに、Fred は、Sales グループから削除されています
違い：
ユーザー ID を無効にするアクションは、権限のないグループ内のユーザーを無効にしないようにグループレベルの管理者に制限されています。
グループ管理者は、管理者のグループまたはデフォルトグループ内にのみメンバーシップを持つユーザーのみを非アクティブにできます。
- ユーザーが、非アクティブにしようとしているグループ管理者の権限の外部にメンバーシップを持っている場合、「ユーザーを非アクティブにする」オプションは使用できません
アカウントレベルの管理者の違い
アカウントレベルの管理者のみが、次の項目にアクセスできます。
違い：
個々のユーザーを作成するときに、ユーザーグループフィールドの名前がプライマリグループに変更されました
違い：
グループレベルの管理者のセクションに記載されているように、複数のユーザーを作成／更新するために使用される、アップロードされる .csv の形式が変更され、複数のグループおよびグループ固有の権限を持つユーザーに対応できるようになりました。 この最後に、UMG エクスペリエンスで次の 3 つの列が削除されました。
- グループ名 - 削除されました。グループ列に置き換えられました
- グループ管理者 - 削除されました。グループ列のステータス値に置き換えられました
- 送信可能 - 削除されました。グループ列のステータス値に置き換えられました
1 つの列グループ
が追加されました
グループ列には、1 つ以上のグループ定義が含まれています。各グループ定義では、1 つのグループの名前の後に、1 つ以上のステータス値が角括弧で囲まれます。例：グループ名[ステータス]
- グループ名は、スペースを含む実際のグループ名と正確に一致します。例：デフォルトグループ
- グループ名[ステータス 1 ステータス 2] など、1 つのグループ定義に複数のステータス値を含めることができます
- ステータス値は角括弧で囲まれます
- グループ名と左角括弧の間にスペースはありません
- ステータス値は、値の間を 1 つのスペースで区切られます
- ステータス値は角括弧で囲まれます
- セミコロンを区切り文字として使用して、複数のグループ定義を含めることができます（スペースなし）
- 例：グループ名[ステータス];その他のグループ[ステータス 1 ステータス 2 ステータス 3];最後のグループ[ステータス A ステータス B]
- グループ定義で使用できるステータス値は次のとおりです。
- プライマリ - ユーザーのプライマリグループとしてグループを定義します
- 送信 - ユーザーがグループから契約書を送信できるようにします
- 送信不可 - ユーザーがグループから契約書を送信できないようにします
- 管理者 - グループのグループレベル管理者としてユーザーを定義します
- 削除 - グループからユーザーを削除します
上記の例では、次のようになります。
- John@here.com は、次の 2 つのグループ定義で設定されます。
- デフォルトグループは、彼のプライマリグループであり、彼はグループレベルの管理者であり、契約書の送信が許可されています
- Engineering グループは、彼をグループレベルの管理者として定義し、契約書を送信できます
- デフォルトグループは、彼のプライマリグループであり、彼はグループレベルの管理者であり、契約書の送信が許可されています
- また、Fred@here.com は、次の 2 つのグループ定義で設定されます。
- Procurement グループは、彼をグループレベルの管理者として定義しますが、契約書の送信は無効にします
- さらに、Fred は、Sales グループから削除されています
違い：
ユーザーが別のグループに追加された場合に、ユーザーをデフォルトグループから削除することを許可するための、UMG ルールに基づいた次の 2 つの設定が使用できます。
- プライマリグループがデフォルトグループの場合、グループ割り当てによりデフォルトグループからユーザーを削除する - 有効な場合は、プライマリグループがデフォルトグループに設定されているユーザーは、ユーザーをこのグループに割り当てる管理ページを使用して、他のグループに追加された場合に、デフォルトグループから削除されます。新しいグループが、自動的にユーザーのプライマリグループになります。
- この設定は、CSV 読み込みまたは API メソッドを使用してユーザーを追加／変更する場合には適用されません。
- グループ管理者はアカウントのデフォルトグループからユーザーを削除できる - この設定では、グループレベルの管理者がユーザープロファイルを使用してデフォルトグループからユーザーを削除するオプションを有効にします。
プライバシーレベルの管理者の違い
現在、UMG 設定では、プライバシーレベルの管理者ツールは変更されていません。
API の違い
UMG に対応するようにアップデートされるのは、REST API の v6 のみです。
従来の SOAP API は UMG に対応するようにアップデートされません。
SOAP API または v5 REST（およびそれ以前のバージョン）を使用すると、UMG に対応せずに機能し、ユーザーのプライマリグループが有効になります。
特定のグループのコンテキストで実行される v6 REST API エンドポイントは、オプションのグループ ID 識別子を含むように拡張されています。この識別子は、クエリーパラメータ、ヘッダー、またはリクエスト本文の一部としてリクエストに渡すことができます。
このパラメーターはオプションであり、省略すると、コードでは、デフォルトのユーザーのプライマリグループに設定されます。
グループ固有のアクションは、次の 2 つのカテゴリに分類されます。
- ユーザー管理
- リソースでの CRUD 操作
ユーザー管理の変更は、1 つの API 呼び出しで複数のグループメンバーシップを管理する機能と、グループ管理者の機能に影響を与えるセキュリティモデルの拡張に含まれます。つまり、グループ管理者が、自分の範囲外のグループに変更を加えないようにします。
リソース操作の変更は、契約書、Web フォーム、一括送信イベントにグループコンテキストを提供する、リクエスト／レスポンスモデルに対する追加のグループ ID パラメーターです。
グループ ID パラメーターは、v6 REST API にのみ追加されます。v6 REST より下のバージョンでは、下位互換性のためにプライマリグループを使用します。
INVALID_GROUP_ID
一般的なエラー応答コード「INVALID_GROUP_ID」は、次の場合にトリガーされます。
- 識別されたグループが見つからない
- 識別されたユーザーは、識別されたグループのメンバーではない
- この機能が無効になっており、グループ ID がユーザーのプライマリグループと一致しない
UMG が有効になっていない場合、すべての既存のエンドポイントは以前のように動作します。ユーザーのプライマリグループは、唯一の有効なグループメンバーシップとして使用され、別のグループ ID がエンドポイントに渡されると、INVALID_GROUP_ID が返されます。
複数のグループにユーザーを追加
複数のグループにユーザーを追加するには、次の 2 つの方法のいずれかを実行します。
個々のユーザーを編集 - 次の方法で行います。
- ユーザーメニュー - アカウントレベルの管理者のみ
- グループ内のユーザーメニュー - アカウントまたはグループレベルの管理者
ユーザーをシングルクリックして「ユーザーを編集」オプションを表示し、「ユーザーを編集」をクリックします。
グループ管理用のオーバーレイが開き、管理者は、プラスアイコンをクリックして、管理者権限を持つ任意のグループにユーザーを自由に追加できます。
グループメンバーシップがユーザーに追加されると、管理者はグループ管理者および送信可能列ヘッダーの下にあるチェックボックスをオン／オフにすることで、グループ内のユーザーの権限を有効／無効にできます。
アカウントレベルの管理者は、ユーザーの一括作成／アップデート機能を使用して、アカウント内のすべてのユーザー ID をすばやく更新できます。
ユーザーの一括作成および編集は、名前、会社、タイトル、類似した情報の編集などの機能のためにグループレベルの管理者が利用できるオプションです。 グループメンバーシップは、グループレベルの管理者がアップロードされる CSV 機能を使用して操作できる値ではありません。
「サンプル CSV ファイルのダウンロード」リンクをクリックすると、さまざまなプロパティが含まれているサンプルの CSV をダウンロードできます。
複数のユーザーを作成／アップデートするために使用される、アップロードされる .csv の形式が変更され、複数のグループおよびグループ固有の権限を持つユーザーに対応できるようになりました。 この最後に、UMG エクスペリエンスで次の 3 つの列が削除されました。
- グループ名 - 削除されました。グループ列に置き換えられました
- グループ管理者 - 削除されました。グループ列のステータス値に置き換えられました
- 送信可能 - 削除されました。グループ列のステータス値に置き換えられました
新しいグループ列
グループ列には、1 つ以上のグループ定義が含まれています。各グループ定義では、1 つのグループの名前の後に、1 つ以上のステータス値が角括弧で囲まれます。例：グループ名[ステータス]
- グループ名は、スペースを含む実際のグループ名と正確に一致します。例：デフォルトグループ
- グループ名[ステータス 1 ステータス 2]など、1 つのグループ定義に複数のステータス値を含めることができます
- ステータス値は角括弧で囲まれます
- グループ名と左角括弧の間にスペースはありません
- ステータス値は、値の間を 1 つのスペースで区切られます
- ステータス値は角括弧で囲まれます
- セミコロンを区切り文字として使用して、複数のグループ定義を含めることができます（スペースは使用できません）
- 例：グループ名[ステータス];その他のグループ[ステータス 1 ステータス 2 ステータス 3];最後のグループ[ステータス A ステータス B]
- グループ定義で使用できるステータス値は次のとおりです。
- プライマリ -ユーザーのプライマリグループとしてグループを定義します
- 送信 - ユーザーがグループから契約書を送信できるようにします
- 送信不可 - ユーザーがグループから契約書を送信できないようにします
- 管理者 - グループのグループレベル管理者としてユーザーを定義します
- 削除 - グループからユーザーを削除します
上記の例では、次のようになります。
- John@here.com は、次の 2 つのグループ定義で設定されます。
- デフォルトグループは、彼のプライマリグループであり、彼はグループレベルの管理者であり、契約書の送信が許可されています
- Engineering グループは、彼をグループレベルの管理者として定義し、契約書を送信できます
- デフォルトグループは、彼のプライマリグループであり、彼はグループレベルの管理者であり、契約書の送信が許可されています
- また、Fred@here.com は、次の 2 つのグループ定義で設定されます。
- Procurement グループは、彼をグループレベルの管理者として定義しますが、契約書の送信は無効にします
- さらに、Fred は、Sales グループから削除されています
契約書の作成
UMG ルールは、新しい契約書を作成するプロセスの最初に表示されます。
ホームページ／ライブラリから開始からテンプレートまたはワークフローを選択してプロセスを開始する場合、ユーザーは最初に送信元のグループを展開してから、グループ内で使用可能なオプションからテンプレート／ワークフローを選択する必要があります。
テンプレート／ワークフローを選択して開始をクリックすると、送信ページが開き、ユーザーが設定を完了できるようになります。
グループレベルのテンプレートまたはワークフローから契約書を開始すると、グループの値が送信ページに挿入され、グループを編集するオプションが無効になります。
アカウントレベルのワークフロー／テンプレートが選択されている場合、送信者はグループの値を選択するオプションを使用できます。
ユーザーが送信ページからプロセスを開始した場合、送信元ドロップダウンフィールドは、契約書が関連付けられるグループを定義します。
グループを選択すると、契約書は、選択したグループで使用可能なライブラリテンプレートに制限されます。
グループを変更すると、契約書に適用されるプロパティが変更されます。 これにより、ページが強制的に更新され、入力されたフィールドレベルのコンテンツは失われます。
カスタムワークフローデザイナー
カスタムワークフローの作成と管理は、現時点では UMG ルールの影響を受けません。
- グループに割り当てられているワークフローは、プライマリグループが、ワークフローが専用で割り当てられているグループと同じグループに設定されている管理者（グループまたはアカウントレベル）のみが編集できます
- アカウントレベルに割り当てられているワークフローは、アカウントレベルの管理者のみが編集できます（プライマリグループに関係なく）
今後のアップデートでは、プライマリグループに関係なく、作成したワークフローを管理権限を持つ個々のグループに関連付けるためのインターフェイスオプションが管理者に提供されます。
ライブラリテンプレートの作成と管理
UMG ルールで再利用可能なライブラリテンプレートを作成する場合、テンプレートにアクセスするためのグループレベルの権限を付与するには、次のような手順が 1 つ追加されます。
ライブラリテンプレートが関連付けられているグループを定義します。
- これは、このテンプレートを使用できるユーザー権限を選択した場合に、サブメニューで実行されます。
テンプレートを作成した元のユーザー ID は、そのテンプレートの「所有者」として認識されます。
テンプレート所有者は、送信または編集するテンプレートに常にアクセスできます。所有するユーザー ID の権限レベル、またはテンプレートが公開されているグループに所有者が関連付けられているかどうかは関係ありません。
既存のライブラリテンプレートの管理
既存のライブラリテンプレートのプロパティは、管理ページで編集できます。
テンプレートを開いて編集します。テンプレートが自分のグループ内の任意のユーザーと共有されている場合は、編集者はグループの関連付けを変更できます。
グループの関連付けを変更しても、既に作成されている契約書のグループの提携には影響しません。
Web フォームの作成と管理
UMG ルールで Web フォームを作成するには、次のような手順が 1 つ追加されます。
Web フォームが関連付けられているグループを定義します。 これはページの最上部でおこないます。
- グループを変更するとページがリセットされ、フィールドレベルのコンテンツがクリアされるので、最初にグループ値を設定します
関連付けられたグループは、Web フォームの作成後は編集できません。
既存の Web フォームの管理
UMG ルールは、既存の Web フォームの管理方法には影響しません（関連付けられたグループは編集できないため）。
Web フォームに対してレポートを実行するには、レポートを実行する作成者か、グループ内のレポートデータに対する権限を持つ管理者が必要です。
コンテンツの共有
個別の契約書またはテンプレートの共有は、UMG ルールの影響を受けません。
標準アカウント共有を使用しているアカウント（ユーザー対ユーザー共有のみ）は、UMG ルールの影響を受けません。
高度なアカウント共有では、ユーザー間、グループ間、ユーザーとグループ間での共有が許可されます。
ユーザー対ユーザーの共有は UMG ルールで変更されません。
- ユーザー A が自分のアカウントをユーザー B と共有する場合：
- ユーザー B は、ユーザー A が作成したまたは当事者であるすべての契約書／テンプレートコンテンツにアクセスできます
- ユーザー A が所有するすべてのテンプレート（自分自身／グループ/アカウントに割り当てられている）が表示されます
- 複数のグループにメンバーシップを持っている場合、またはユーザー A を別のプライマリグループに移動しても、関係には影響しません
- ユーザー B は、ユーザー A が作成したまたは当事者であるすべての契約書／テンプレートコンテンツにアクセスできます
ユーザー A がグループ X に共有されている場合：
- グループ X のすべてのメンバーは、ユーザー A が作成したまたは当事者であるすべての契約書／テンプレートコンテンツにアクセスできます
- ユーザー A が所有するすべてのテンプレート（自分自身／グループ/アカウントに割り当てられている）が表示されます
- 複数のグループにメンバーシップを持っている場合、またはユーザー A を別のプライマリグループに移動しても、関係には影響しません
- グループ X に追加されたユーザーは、ユーザー A の契約書／テンプレートコンテンツにアクセスできます
- グループ X から削除されたユーザーは、ユーザー A によって共有されている契約書／テンプレートコンテンツにアクセスできなくなります
グループ A がユーザー X に共有されている場合：
- ユーザー X は、グループ A から作成／送信されたすべての契約書にアクセスできます
- 送信側のユーザー ID は、グループ A の現在のメンバーである必要はありません。グループ A から契約書が作成されたことで、関係が定義されます
- 送信側のユーザー ID は、グループ A の現在のメンバーである必要はありません。グループ A から契約書が作成されたことで、関係が定義されます
- ユーザー X は、グループ A がプライマリグループとして定義されているすべてのユーザー ID のすべての契約書／テンプレートにアクセスできます
- 例：ユーザー M のプライマリグループをグループ A からグループ B に変更すると、ユーザー X にはユーザー M のコンテンツが表示されなくなります（上記のルールに従ってグループ A から送信された契約書を除く）。
グループ A がグループ B に共有されている場合：
- グループ B のすべてのメンバーは、グループ A から送信されたすべての契約書にアクセスできます
- 送信側のユーザー ID は、グループ A の現在のメンバーである必要はありません。グループ A から契約書が作成されたことで、関係が定義されます
- グループ B のすべてのメンバーは、グループ A がプライマリグループとして定義されているユーザーのすべての契約書／テンプレートコンテンツにアクセスできます
- グループ B に新しいユーザー ID を追加すると、そのユーザー ID は、グループ A のコンテンツのへアクセスを付与されます
- グループ B からユーザー ID を削除すると、グループ A のコンテンツへのアクセスが削除されます
- グループ A がプライマリグループになるようにユーザー ID を作成またはアップデートすると、すべてのユーザーの契約書／テンプレートコンテンツがグループ B に公開されます
- グループ A からユーザー ID を削除すると、グループ B のコンテンツに対するユーザーのアクセス権が削除されます（グループ A から作成された契約書を除く）
- グループ A からユーザー ID を削除すると、グループ B のコンテンツに対するユーザーのアクセス権が削除されます（グループ A から作成された契約書を除く）
文書の保持／GDPR
UMG の変更に関して GDPR ツールセットについて想定される変更はありませんか？
統合
1 つ（または複数）の統合が設定されている場合でも、すべてのエンタープライズレベルのアカウントで UMG を有効にできます。
現在の Acrobat Sign 統合パッケージは、UMG を一切考慮していません。 その結果、統合を介して契約書を送信するすべてのユーザーはプライマリグループのみに属していると認識され、それに応じてパラメーターの送信はプライマリグループの設定に合わせて調整されます。
API - REST v6
REST v6 API エンドポイントの多くで、グループ ID のオプションパラメータがメソッドに追加されています。
現在の想定では、UMG が有効になっているかどうかに関係なく、既存の REST v6 API 呼び出しは引き続き機能します。
以前の API バージョン（SOAP と REST の両方）は、引き続き想定どおり動作し、ユーザーはプライマリグループのメンバーとしてのみ認識されます。
アカウントにログイン