コンテキストと Domain Separation
ユーザーのセッションのコンテキストによって、ユーザーがリストビュー、ホームページ、レポート、およびナレッジ記事を参照する際のプロセス、データ、およびユーザーインターフェイス (UI) が決まります。コンテキストは、作成するプロセス、設定するビジネスルール、ワークフロー、およびその他の要因によって決まります。
ユーザーセッションコンテキスト
ユーザープロファイル、グループ、会社基準など、多くの要因がユーザーセッションのコンテキストを決定します。次の図では、会社が作成したインシデントがコンテキストの一部であることがわかります。
この例のユーザーのホームドメインは Cloud Dimensions です。
- ブランディングには、Cloud Dimensions ドメインと会社レコードの設定が反映されます。
- アプリケーションナビゲーターには、上位レベルのドメインから継承されたアイテムと、Cloud Dimensions ドメインで定義されているモジュールが表示されます。
- ホームページとリストデータには、ユーザーに表示されるデータが反映されます。このデータは、ユーザーのセッションコンテキストに基づいています。この場合、Cloud Dimensions ドメインのユーザーは、Cloud Dimensions、子ドメイン、およびグローバルドメインのデータを表示できます。
ホームドメインでのユーザーセッションコンテキストの開始
次の図は、コンテキストの要素を示しています。
システム管理者は、ユーザーのホームドメインをユーザーレコードに設定します。通常、ユーザーのホームドメインは会社のドメインと同じドメインに設定されます。ユーザーがログインすると、ドメインピッカーがユーザーのホームドメインに自動的に設定されます。ユーザーは、ドメインピッカーの矢印アイコンをクリックして、いつでもホームドメインに戻ることができます。
ドメインピッカーのリストには、ユーザーのセッションコンテキスト内のドメインが含まれています。ユーザーは、ピッカーで子ドメインを選択して、セッションコンテキストをさらに制限できます。
ユーザーセッションのコンテキストには、ユーザーのホームドメインと子ドメインが含まれます。ユーザーのセッションコンテキスト内のこの一連のドメインは、データベースに送信されるすべてのクエリに自動的に追加されます。これにより、結果はこれらのドメイン内のデータとグローバルデータのみに制限されます。このプロセスは、アクセスできないコンパイル済みコードに埋め込まれています。
統合に使用されるサービスアカウントにもユーザーセッションコンテキストがあります。ユーザーコンテキストとレコードコンテキストがあり、それぞれ独自のドメインに独自のデータがあります。これらのコンテキストは統合に影響します。データベースクエリー (レコード) は、インタラクティブユーザー (ユーザー) と同じ方法で制限されます。つまり、通常どおりに機能しますが、開発者が設定した制約によって制限されます。
ユーザーのセッションコンテキストにドメインを追加するその他の方法については、「サービスプロバイダー参照アーキテクチャ」を参照してください。
レコードコンテキスト
ユーザーが個々のレコードにドリルダウンすると、レコードコンテキストが有効になります。レコードコンテキストによって、レコードに適用する UI 要素とプロセスが決まります。
- レコードコンテキストは、ユーザーのドメインが変更されても保持されます。
- ユーザーは、独自のレコードコンテキストを維持しながら、複数のブラウザータブで同時にレコードを表示できます。