はじめに
パブリケーショングループが実際にどのように機能するかをより深く理解したいと思ったことはありますか？このドキュメントは、この興味深いトピックに関する詳細な情報を提供することを目的としています。パブリケーショングループの最新かつ優れた機能を適切に説明するために、使用事例別に製品の機能とオプションを分類しています。内部パブリケーショングループ
使用事例
内部状況では、パブリケーショングループは特定の内部ユーザーが属するセグメントにもとづいて、データのフィルターとして機能します。例えば、営業マネージャーは、販売地域またはアカウントのデータのみを各営業担当者または営業グループに表示させたいが、一人ひとりに個別のページを複製、変更、または保持したくないと考えている場合があります。この場合、各営業担当者はパワーユーザーレベルまたは閲覧ユーザーレベルのいずれかのアクセス権を持つセールスパブリケーショングループのメンバーになります。設定
設定を行うには、 ［管理者］>［パブリケーショングループ］ の順に移動して、フィルターするページを選択します。そこから、使用事例にもとづいて関連するデータソースを追加および編集できます。選択したデータキー（スクリーンショットに表示されている地区、担当者の名前、または地域）にもとづいて、データがダッシュボード内で行レベルでフィルターされることに注意してください。
結果
例で選択されたページは、適切なデータのみを使用してデータソース/DataFlowレベルでフィルターされます。例では、売上データの担当者列またはチーム列をもとに、売上データがフィルターされ、チームまたは個人ごとに該当するデータがカードに表示されます。内部パブリケーショングループにより、通常機能へのアクセスが奪われることがないよう注意することが大切です。ページ機能とカード機能はすべてのユーザー間で共通です。ユーザーは、ページにフィルターを適用したり、カードにドリルダウンしたりするなど、同一の操作を期待通り行うことができます。ユーザーのインスタンスでは、Buzzやアラート、その他の機能は有効になったままです。 セールスグループAのビュー：
- 管理者は変わらずすべてのデータソースにアクセスできます。例では、ユーザーのデータソースへのアクセスを制限する場合、すべての営業担当者がパワーユーザーレベルまたは閲覧ユーザーレベルのアクセス権のみを持つようにする必要があります。
- パブリケーショングループのアクセス制御はカードへのアクセスと異なります。パブリケーショングループは独立したアクセス制御を使用しているため、ユーザーはパブリケーショングループに含まれるカードおよびデータソースにアクセスすることができません。インスタンスの管理者であっても、カードやページを共有したりコピーしたりすることはできません。
- このドキュメントの作成時点で、アラートはパブリケーショングループにとって課題です。パワーユーザーと閲覧ユーザーは引き続きアラートとお気に入りを使用できますが、これらのユーザーはフィルター処理したカードにアラートを追加することはできません。管理者が作成したアラートのみを使用できます。これらのユーザーがアラートを作成したユーザーをフォローしている場合、サブスクライブするには［アラート］タブに移動する必要があります。このとき、アラートエンジンはフィルターシステムを考慮しないことに注意してください。アラートをサブスクライブするユーザーは、フィルター処理されたビューだけでなく、カードのDataSet全体に対してアラートを受け取ります。
- ページがパブリケーショングループでフィルター処理されていることを示すUIは表示されません。管理者は、特定のページがパブリケーショングループでフィルター処理されていることをユーザーに示すことを検討しても良いでしょう（例えば「このページは、販売地域のみを表示するようにフィルターされています」と表示するなど）。
- ユーザーはパブリケーショングループページのカードサイズを変更または再編成することはできません。
SSO（別名SaaS/SaaS）による外部パブリケーショングループ
使用事例
この使用事例では、厳しく管理された情報をDomoの顧客のクライアントに周知するためにパブリケーショングループを使用します。一般的な例では、エージェンシーや専門サービスのグループがあります。通常、管理者は、個々のエンドユーザー、グループ、または外部のクライアントが互いに認識し、コラボレーションしたり交流したりすることを望んでいません。例えば、エージェンシーは、200人のすべてのエンドユーザーのクライアントに向けて、事前にフォーマットされた有料検索結果ページを同様のカードと共有することを希望する場合があります。エージェンシーの目標は、エンドユーザーのクライアントがほかのクライアントの存在を意識せずに、安全かつ確実にログインしてリアルタイムデータを使用できるようにすることです。設定
外部パブリケーショングループを完全に保護する唯一の方法は、SSOを有効にしてエンドクライアントにSSOを介してDomoにログインさせることです。具体的には、2つのタイプのSSOがあります。- SSOによるDomoへの認証
- SSO（SaaS/SaaS SSO）によるパブリケーショングループへの認証
結果
パブリケーショングループSSOが適切に有効化および設定されている場合、エンドユーザー/クライアントは技術的にはDomoインスタンス内のユーザーではありません。エンドクライアントは、インスタンスのcustomername-ss.domo.com 部分にのみログインしています。そのため、そのエンドユーザーにのみ適用可能なデータが完全に安全でカスタマイズされた方法で提供されます。エンドユーザーはほかのエンドクライアントのデータにアクセスできなくなります。ただし、外部のパブリケーショングループの閲覧ユーザーに対しては、Domoのほかの強制的な機能の多くは完全に無効になります。エンドユーザーは、アラート、お気に入り、トップページなど、多くの通常のインスタンス機能にアクセスすることができません。Buzzと検索は無効になっています。エンドクライアントには指定されたページのみが表示され、White Label化が自動的に実行されます。
この使用事例に関するその他の詳細：
- SSOは、外部グループやHotmailやGmailなどの外部メールに対応することができます。
-
パブリケーショングループ内のユーザーのマッチングに使用される要素：
- 名前
- Domoユーザーグループ
- メールアドレス
SSOを使用しない外部パブリケーショングループ（中間オプション）
使用事例
よくあることですが、SSOアクセス制御プログラムを構築して有効にするための実行可能なリソースや手段、または関心が顧客（エージェンシー）に不足していることがあります。Domoには3つ目のオプション、つまり内部と安全な外部の使用事例の中間に当たるオプションがあります。3つ目のオプションは、インスタンス内のほかのクライアントのUIとエビデンスを非表示にします。エンドクライアントが、該当するパブリケーショングループの閲覧ユーザーである場合、使用事例2で説明した同じ機能がほぼ引き続き適用されますが、以下で説明するいくつかの注意点もあります。設定
エンドユーザー/クライアントは、上記のように閲覧ユーザーおよびパブリケーショングループの一部として設定する必要があります。管理者（Domoの顧客）は、上記のようにデータソースでフィルターも設定します。エンドクライアントは引き続きcustomer-ss.domo.com インスタンスにログインしますが、SSO認証はありません。ほかのカード、ページ、およびデータソースに招待されていない場合、UIはクリーンな状態です。プロジェクトとタスク、Buzz、検索などの機能は無効になります。
結果
エンドユーザーは、一般的なcustomer-ss.domo.com ドメインにログインし、そのエンドユーザーにのみ関係するカード/ページに存在するカスタマイズされたデータにアクセスできます。ただしこの場合、エンドユーザーはインスタンスの実際のユーザーアカウントを持っています。そのため、エンドユーザーは引き続き customer.domo.com に移動し、SSOオプションが制御する特定のDomo機能にアクセスできます。エンドユーザーが – ss.domo.com UIの範囲内にとどまり、閲覧ユーザーレベルのアクセス権しか持たない場合、そのエンドユーザーはほかのエンドユーザーを見つけることができません。プロジェクトとタスク、Buzz、検索は無効になります。お気に入りとトップページは存在しますが、エンドユーザーは編集や設定を行えません。技術的に精通したITグループを持つエンドユーザー/クライアントは、既存の防止手段の回避方法を見つけることができることに留意してください。そのため、直接の顧客（この例ではエージェンシー）は、このオプションの欠点を認識する必要があります。顧客は、ユーザーを管理するために導入可能なOktaのようなシステムを検討する必要があります。