モデル
モデルは、報酬プログラムを作成し、報酬プロセスを長期にわたって維持するスペースです。
[管理]ツールバーで[モデル]名を選択すると、ユーザーは[モデル]の設定を表示および管理できます。これには、メンテナンス情報の表示、モデル・オプション、ユーザーのセキュリティ設定も含まれます。
今後のモデルメンテナンスの表示
今後7日間においてスケジュールされた今後のVaricent Incentivesのモデルメンテナンスの詳細を表示することができます。
アプリケーションヘッダーのモデル名の横にあるドロップダウン矢印をクリックします。
[今後のメンテナンス]をクリックします。
モデルテーマの変更
モデルテーマを変更すると、すべてのユーザーのVaricent Incentivesクライアントのヘッダーの色が変更されます。モデルのテーマを変更すると、作業しているモデルを特定するのに役立ちます。モデルのリストを表示する場合、各名前の横にテーマの色を示すインジケータがあります。
モデルテーマを変更するには、[ホーム]ページの編集および表示権限が必要です。これらの権限は、[管理者オプション]で割り当てられます。
ホームページで、モデル名をクリックします。
メニューから[モデル]テーマをクリックします。
モデル名の横にあるカラーパレットメニューを選択します。また、カラーピッカーでカスタムカラーを選択するか、カラーフィールドに16進コードを入力することもできます。
色を選択し、[保存]をクリックします。
ヘッダーの色は、そのモデルに対して変更され、そのモデルで作業するすべてのユーザーに対して表示されます。
SSO証明書のセルフサービス更新
シングルサインオン（SSO）証明書の更新機能により、管理者ユーザーは証明書のメタデータをダウンロードし、Varicent SSO証明書を更新できます。
警告
[en] Incentives does not support stand-alone OAuth or SSO, only OpenID Connect is supported.
[en] We support Multi-Factor Authentication but require Single Sign-On (SSO) for its use.
[en] Complete the following steps to renew the SSO certificate for the Admin Client. Updating the Admin Client SSO certificate covers all your models in the tenant. Only users with Administrator roles can complete this renewal.
[en] Video tutorial:
ヒント
最初に、非本番環境で証明書の更新を実行してください。
[en] Steps:
管理パネルから、モデル名をクリックします。
[認証] を選択します。
[管理web] タブで、[証明書と秘密キーペア] ドロップダウンから新しい証明書を選択します。
[en] Choose the option with the latest expiry date.
[メタデータをダウンロード] をクリックします。
重要
[en] Do not click the Update button yet. Additional steps must be completed before the certificate can be updated here.
ダウンロードしたメタデータファイルをITチームに送信し、IDP（IDプロバイダー）を更新してもらいます。
メタデータが更新されたら、このページに戻り、[証明書と秘密キーペア] ドロップダウンから新しい証明書名を再度選択し、[更新] をクリックします。
[en] Re-select the latest certificate key pair from the drop-down.
[en] Click Update.
[en] Renewing the SSO certificate for Sales Portal or Payee Web
[en] The Single Sign-on (SSO) Certificate renewal feature allows admin users to download certificate metadata and update Varicent SSO certificates. The certificate in the Varicent metadata expires every year. This change needs to be made to prevent any access issues once the certificate expires.
[en] Note
[en] This section applies to you if you use SSO and a Varicent certificate.
[en] If you use SSO and have your own certificate, please contact Support to perform any certificate renewals.
警告
[en] Incentives does not support stand-alone OAuth or SSO, only OpenID Connect is supported.
[en] We support Multi-Factor Authentication but require Single Sign-On (SSO) for its use.
[en] From the Payeeweb/Salesportal tab, an admin user can see the current active SSO certificate by model and configuration, download certificate metadata files, and update the Varicent SSO certificate accordingly. Updates for Payee Web or Sales Portal SSO certificates must be done for each model individually.
[en] Video tutorial:
[en] Steps:
[en] From the admin panel, click the model name drop-down.
[en] Click Authentication.
[en] Under the SSO Payeeweb / Sales Portal tab, click the model you want to update.
[en] Click the Configuration drop-down.
[en] Select the configuration that you're using. If you’re unsure which one to choose, contact Varicent Support for guidance.
[en] In the Select Certificate Key Pair drop-down, choose the option with the latest expiry date.
[en] Click Download Metadata and select one of the following options (check your URL if you aren't sure which version you use, look for payeeweb or payeewebv2):
[en] Payeeweb Metadata: For users of Payee Web v1
[en] Sales Portal Metadata: For users of Payee Web v2
重要
[en] Do not click the Update button yet. Additional steps must be completed before the certificate can be updated here.
[en] Provide the downloaded metadata file to your IT or network team. They will use this file to update your SSO configuration.
[en] Once the IT team confirms that the configuration update is complete, return to the Authentication page in Admin Client.
[en] Re-select the same tabs and drop-down options that you did before.
[en] Click Update.
[en] Test a login on the Payee Web or Sales Portal model you updated to ensure everything works correctly. For best results, use an incognito window to avoid caching issues.
[en] Repeat these steps if you need to update the SSO certificate for other models.
セキュリティ
Varicent Incentivesモデルへのアクセスを制御できます。アクセスを完全に拒否したり、表示のみのアクセスを許可したり、編集と表示の両方に対するアクセスを許可したりできます。
ユーザーは、ロールと組み合わせ、アクセス管理フレームワークを提供します。ユーザーは、モデル間で共有されません。ユーザーは、主にモデルのコンテナであるテナントに関連付けられます。ユーザーは、ロールを通じてテナントに含まれるモデルに関連付けられます。ユーザーは、1つのモデル、および複数のモデルに関連付けられます。あるいは、まったくモデルに関連付けられない場合もあります。
特定の機能、またはモジュールへのアクセスが拒否され、ユーザーがアクセスを取得しようとすると、[アクセス拒否]のメッセージが表示されます。
[ロールの管理]ページでは、空のチェックボックスと、サブトラクション記号、またはチェックマークの付いたチェックボックスを使用して、アクセスが拒否、一部許可、または許可されているかどうかが示されます。
アクセス指標 | 説明 |
|---|---|
| これは、ユーザーがモジュール、オブジェクト、または機能へのアクセスを拒否されていることを示すために使用されます。 |
| これは、ユーザーがモジュール、オブジェクト、または機能に部分的なアクセス権を持っていることを示します。 |
| これは、ユーザーがモジュール、オブジェクト、または機能へのフルアクセスを許可されたことを示すために使用されます。 |
たとえば、ロールは、ビュー権限は付与するが編集権限は付与しないで、ポータル・アクセスへの部分アクセスを許可できます。このロールに割り当てられたユーザーは、Webタブ、ポータル・アクセスグループ、またはアクセスツリーを表示できますが、コンテンツの編集は許可されていません。
ユーザーのセキュリティと管理
Incentivesでは、管理者ユーザーID、電子メールアドレス、パスワードを追加、編集、削除できます。
ユーザーをロールに割り当てることで、ユーザーはテナントに追加され、モデルに関連付けられます。ユーザーに割り当てられた各ロールは、ユーザーに適切なアクセス権を付与します。モジュールへのアクセスに十分な権限のないユーザーは、アクセスを拒否されます。
同時ユーザー
ロールを定義し、別のユーザーに割り当てると、Incentivesに同時にログインできます。これにより、複数のユーザーが同時にモデルに対するアクションを完了できます。
たとえば、管理者ユーザー1がモデルにテーブルを追加している間、管理者ユーザー2を同時にログインして計算を編集できます。
このルールの例外は、複数の管理者が、計算やデータのインポートなど、モデルに対するグローバルアクションを同時に実行しようとしたときに発生します。別の計算を開始する前に、1つの計算を完了する必要があります。また、一度に1つのデータ・インポートしか実行できません。別の管理者が処理中に、別の管理者が計算、またはデータ・インポートを実行しようとすると、警告メッセージが表示されます。
2人目の管理者は、最初の管理者のグローバル・アクションが完了するまで待機する必要があります。
通常、2人以上の管理者がモデルで関連のない変更を行う場合、すべての管理者は警告なしに変更を行うことができます。2人の管理者が同じ情報に変更を加えると、2人目の管理者は、保存する前にデータを更新するように促すリマインダーを受け取ります。
次の表は、複数の管理状況の例を示しています。この表は、複数の管理者が同じモジュールで同時に変更を加える場合と、計算、またはインポートの進行中に変更を加える場合の一般的な例を示しています。管理者が別のモジュールで無関係な変更を行う場合、すべての管理者は警告なしに変更の実行と保存をすることができます。
モジュールまたはアクション | 状況 |
|---|---|
インポート | 複数の管理者がテーブルにデータをインポートしようとした場合、最初の管理者がデータのインポートを完了すると、警告なしにインポートが完了します。他のすべての管理者には、最初の管理者のインポートが完了しないとインポートを完了できない旨が通知されます。 |
インポート | 管理者がインポートを実行し、2人目の管理者が同じテーブルに行を追加しようとすると、2人目の管理者が行を追加する前に、最初の管理者のインポートが完了する必要がある旨が2人目の管理者に通知されます。 |
計算 | 管理者が、別の計算が進行中にモデルの計算を試みると、別の計算が進行中であるため計算が続行できない、という旨が2番目の管理者に通知されます。 |
コンポーザー | 複数の管理者がテーブル内の異なる行を追加または編集しようとすると、すべての管理者が警告なしに変更を行って保存することができます。 |
コンポーザー | 別の管理者が同じテーブルをクリアしようとしているときに、管理者がテーブルを編集しようとすると、最初に[保存]をクリックすると、警告なしに変更を保存できます。後続の管理者は、保存する前にデータを更新するように指示されます。 |
コンポーザー | 別の管理者が別のテーブルをクリアしようとしているときに、管理者がテーブルを編集しようとすると、すべての管理者が警告なしに変更を行って保存することができます。 |
コンポーザー | 複数の管理者が同じ行を同時に編集する場合、最初に[保存]をクリックした管理者は、警告なしに変更を保存できます。後続の管理者は、保存する前にデータを更新するように指示されます。 |
コンポーザー | 2人の管理者が新しい受け取り人グループを追加しようとすると、両方の管理者は警告なしに変更を行って保存することができます。 |
ポータル・アクセス | 複数の管理者がポータル・アクセスグループを同時に作成している場合、すべての管理者は警告なしに変更を行って保存することができます。 |
入力フォーム | 複数の管理者が入力フォームを同時に作成する場合、最初に[保存]をクリックした管理者は、警告なしに変更を保存できます。後続の管理者は、保存する前にデータを更新するように指示されます。 |
Webフォーム | 複数の管理者がWebフォームを作成した場合、すべての管理者は警告なしに変更を行って保存することができます。 |
Webフォーム | 複数の管理者が同じWebフォームにWebリソースを追加しようとすると、最初に[保存]をクリックした管理者は、警告なしに変更を保存できます。後続の管理者は、保存する前にデータを更新するように指示されます。 |
スケジューラー | 複数の管理者がスケジューラーで同じスケジュールされたプロセスを編集しようとする場合、最初に[保存]をクリックすると、警告なしに変更を保存できます。後続の管理者は、保存する前にデータを更新するように指示されます。 |
ロール分離の例
Incentivesでロール分離の例を見ると役に立つかもしれません。
次の例を考えてみましょう。
あなたの会社には、すべての会社の報酬プランを構築する責任を担う、報酬プラン・ビルダーのジョンがいます。すべての構築は開発環境で行われるため、開発環境にアクセスできる必要があります。ジョンは、品質保証(QA)、および生産環境で、報酬計画の結果を確認できる必要があります。そのため、これらの環境では、ユーザーのロールが異なる必要があります。
あなたの会社には、ポータル・アクセス階層の設定と維持を担当するポータル・アクセスマネージャーのサリーもいます。彼女は、開発およびQA環境へのアクセスを必要としません。実稼働環境では、ポータル・アクセス ツリーを割り当ててタスク・マネージャールールを追加で切る必要がありますが、他のモデル・コンポーネントにアクセスする必要はありません。
ロール | 開発環境 | QA環境 | 生産環境 |
|---|---|---|---|
ジョン - プランビルダー | 計画の作成 テーブルの追加と編集 データのインポート | 計画を表示 | 計画を表示 |
サリー - ポータル・アクセスマネージャー | アクセスできません | アクセスできません | すべてのポータル・アクセスツリー タスク・マネージャールールの追加 |
環境ロールの作成
Incentivesで環境ごとに異なるロールを作成するには、プライマリー管理者は、各環境に別々にログインし、適切なユーザーロールアクセスを定義する必要があります。
まず、プライマリー・モデル管理者がモデルにログインし、プラン・ビルダーとポータル・アクセスマネージャーのユーザー・ロールを作成する必要があります。
開発環境内で、プライマリー・モデル管理者は、すべての報酬プラン、コンポーザーモジュール、コンポーザー内の選択したテーブル、およびインポート機能に対するプラン・ビルダーのアクセス権を付与するユーザー・ロールを作成します。プラン・ビルダーのロールには、スケジューラー、タスク・マネージャー、またはプランの作成に不要なその他の領域へのアクセス権がありません。
開発環境内では、ポータル・アクセスのマネージャー・ロールはモデル・コンポーネントにアクセスできません。
プライマリー管理者は、QA環境と本番環境にログインしている間、プランビルダーとポータル・アクセスマネージャのロールに対して、わずかに異なるアクセス権を作成します。これらの環境では、プランビルダーのロールは報酬プランを表示できますが、変更することはできません。
ポータル・アクセスマネージャーのロールは、ポータル・アクセスおよびタスク・マネージャーモジュールでアクションを実行できますが、モデルで他のアクションを実行することはできません。
ユーザーのロールの割り当て
Incentivesでロールを作成した後、特定のユーザーに割り当てる必要があります。
ロールが割り当てられ、ユーザーがモデルにログインすると、ユーザーのロールで許可されているアクションのみを表示および実行できます。サリーは、ポータル・アクセスマネージャーのロールに割り当てられています。サリーがモデルの本番環境にログインすると、ポータル・アクセスと[タスク・マネージャー]モジュールにのみアクセスでき、任意のアクションを実行できます。
ジョンが開発環境にログインすると、報酬プランを構築して変更することができます。もし、彼がQA環境にログインした場合は、計画の変更を試みると警告メッセージが表示されます。