Models
Models are the space in which you'll create compensation programs and maintain compensation processes over time.
By selecting your model name in the admin panel, users can view and manage their model's settings. These include viewing maintenance information, model options, and user security settings for users.
Viewing upcoming model maintenance
Users can view upcoming model maintenance details for Varicent Incentives scheduled over the next seven days.
From the admin panel, click the model name.
Click Upcoming Maintenances.
Changing the model theme
Changing the model theme changes the header color in the Varicent Incentives client for all users. Changing the model theme can help you identify the model that you're working in. When viewing the list of models, there's an indicator beside each name that shows the theme color.
To change the model theme, you need Edit and View permission for the Home page. These permissions are assigned in Model settings
.
From the admin panel, click the model name.
Click Model themes.
Select the color palette menu beside the model name. You can also select a custom color with the color picker or enter a hex code into the color field.
Select a color and click Save.
The color of the header is changed for that model and appears for all users who work in that model.
Renewing the SSO certificate for Admin Client
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.
Note
This section applies to you if you use SSO and a Varicent certificate.
If you use SSO and have your own certificate, please contact Support to perform any certificate renewals.
Warning
Incentives does not support stand-alone OAuth or SSO, only OpenID Connect is supported.
We support Multi-Factor Authentication but require Single Sign-On (SSO) for its use.
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.
Video tutorial:
Tip
Try performing this certificate update on a non-production environment first.
Steps:
From the admin panel, click the model name drop-down.
Click Authentication.
Under the SSO Adminweb tab, click the Select Certificate Key Pair drop-down.
Choose the option with the latest expiry date.
Click Download Metadata.
Important
Do not click the Update button yet. Additional steps must be completed before the certificate can be updated here.
Provide the downloaded metadata file to your IT or network team. They will use this file to update your SSO configuration.
Once the IT team confirms that the configuration update is complete, return to the Authentication page in Admin Client.
Re-select the latest certificate key pair from the drop-down.
Click Update.
Renewing the SSO certificate for Sales Portal or Payee Web
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.
Note
This section applies to you if you use SSO and a Varicent certificate.
If you use SSO and have your own certificate, please contact Support to perform any certificate renewals.
Warning
Incentives does not support stand-alone OAuth or SSO, only OpenID Connect is supported.
We support Multi-Factor Authentication but require Single Sign-On (SSO) for its use.
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.
Video tutorial:
Steps:
From the admin panel, click the model name drop-down.
Click Authentication.
Under the SSO Payeeweb / Sales Portal tab, click the model you want to update.
Click the Configuration drop-down.
Select the configuration that you're using. If you’re unsure which one to choose, contact Varicent Support for guidance.
In the Select Certificate Key Pair drop-down, choose the option with the latest expiry date.
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):
Payeeweb Metadata: For users of Payee Web v1
Sales Portal Metadata: For users of Payee Web v2
Important
Do not click the Update button yet. Additional steps must be completed before the certificate can be updated here.
Provide the downloaded metadata file to your IT or network team. They will use this file to update your SSO configuration.
Once the IT team confirms that the configuration update is complete, return to the Authentication page in Admin Client.
Re-select the same tabs and drop-down options that you did before.
Click Update.
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.
Repeat these steps if you need to update the SSO certificate for other models.
Security
You can control access to Varicent Incentives models. Users can be granted access for viewing only, granted access for both editing and viewing, or denied access completely.
Users, combined with roles, provide an access management framework. Users aren't shared between models. They are primarily associated with tenants, which are containers for models. Through roles, they are then associated with models contained in tenants. Users can be associated with one model, multiple models, or no models at all.
If access to a particular feature or module is denied, and a user tries to gain access, an Access Denied message is displayed.
On the Manage Roles page, empty checkboxes and checkboxes with subtraction signs or check marks are used to indicate whether access is denied, partially granted, or granted.
Access Indicator | Description |
|---|---|
| This is used to indicate that the user is denied access to the module, object, or feature. |
| This is used to indicate that the user has partial access to the module, object, or feature. |
| This is used to indicate that the user has been granted full access to the module, object, or feature. |
For example, a role can be granted partial access to Portal Access by granting view privileges but not edit privileges. Any users who are assigned to this role can view any web tabs, Portal Access groups, or access trees, but they are not permitted to edit content.
User security and management
In Incentives, you can add, edit, or delete administrator user IDs, email addresses, and passwords.
Users are added to a tenant and associated with a model by assigning users to roles. Each role that a user is assigned grants the user appropriate access rights. Users without sufficient privileges to access a module are denied access.
Concurrent users
After you define and assign roles to different users, they can log in to Incentives simultaneously, so that multiple users can complete actions on the model at the same time.
For example, while Administrator User 1 is adding a table to the model, Administrator User 2 can be logged in concurrently to edit a calculation.
The exception to this rule occurs when multiple administrators try to simultaneously perform a global action on the model, such as a calculation or data import. One calculation must be completed before another one can start, and only one data import can occur at a time. If a second administrator tries to perform a calculation or data import while another one is in progress, the second administrator sees a warning message.
The second administrator must then wait for the first administrator's global action to complete.
In general, when two or more administrators are making unrelated changes in the model, all administrators can make changes without any type of warning. When two administrators are making changes to the same information, the second administrator receives a reminder to refresh the data before it can be saved.
The following table provides examples of multi-administrative situations. This table covers common examples of multiple administrators trying to simultaneously make changes in the same module, as well as administrators trying to make changes while a calculation or import is in progress. In all cases where administrators are making unrelated changes in different modules, all administrators can make and save changes without warnings.
Module or Action | Situation |
|---|---|
Imports | If multiple administrators try to import data into a table, the first administrator to finish a data import completes the import without warning. All other administrators are informed that the first administrator's import must complete before they can complete their imports. |
Imports | If an administrator is performing an import and a second administrator tries to add a row to the same table, the second administrator is informed that the first administrator's import must complete before the second administrator can add a row. |
Calculate | If an administrator tries to calculate the model while another calculation is in progress, the second administrator is informed that the calculation cannot proceed because another calculation is in progress. |
Data | If multiple administrators try to add or edit different rows in a table, all administrators can make and save changes without warning. |
Data | If an administrator tries to edit a table while another administrator is trying to clear the same table, the first administrator to click Save can save changes without warning. All subsequent administrators are instructed to refresh the data before they can save. |
Data | If an administrator tries to edit a table while another administrator is trying to clear a different table, all administrators can make and save changes without warning. |
Data | If multiple administrators are editing the same row simultaneously, the first administrator to click Save can save changes without warning. All subsequent administrators are instructed to refresh the data before they can save. |
Data | If two administrators try to add new payee groups, both administrators can make and save changes without warning. |
Portal Access | If multiple administrators are simultaneously creating Portal Access groups, all administrators can make and save changes without warning. |
Input Forms | If multiple administrators are creating input forms simultaneously, the first administrator to click Save can save changes without warning. All subsequent administrators are instructed to refresh the data before they can save. |
Web Forms | If multiple administrators create web forms, all administrators can make and save changes without warning. |
Web Forms | If multiple administrators try to add a web resource to the same web form, the first administrator to click Save can save changes without warning. All subsequent administrators are instructed to refresh the data before they can save. |
Scheduler | If multiple administrators try to edit the same scheduled process in Scheduler, the first administrator to click Save can save changes without warning. All subsequent administrators are instructed to refresh the data before they can save. |
Role segregation example
You might find it helpful to view an example of role segregation in Incentives.
Consider the following example:
Your company has a compensation plan builder, John, who is responsible for building all of your company's compensation plans. Because all building is done in the development environment, he must have access to the development environment. He must be able to see compensation plan results in the quality assurance (QA) and production environments. Therefore, his user role must be different in those environments.
Your company also has a Portal Access manager, Sally, who is responsible for setting up and maintaining the Portal Access hierarchy. She doesn't require access to the development and QA environments. In the production environment, she must be able to assign Portal Access trees and add Tasks rules, but she doesn't need access to any other model component.
Role | Development Environment | QA Environment | Production Environment |
|---|---|---|---|
John - Plan Builder | Build plans Add and edit tables Import Data | View plans | View plans |
Sally - Portal Access Manager | No access | No access | Assign Portal Access trees Add Task Manager rules |
Environment roles creation
To create different roles for each environment in Incentives, the primary administrator must log in to each environment separately and define appropriate user role access.
First, the primary model administrator must log in to the model to create user roles for the plan builder and the Portal Access manager.
Within the development environment, the primary model administrator creates a user role that grants the plan builder access to all compensation plans, the Composer module, selected tables within Composer, and import capabilities. The plan builder role doesn't have access to the Scheduler module, the Tasks module, or any other area that's not required for building plans.
Within the development environment, the Portal Access module manager role doesn't have access to any model components.
While the primary administrator is logged in to the QA and production environments, he or she creates slightly different access rights for the plan builder and Portal Access manager roles. In these environments, the plan builder role can view compensation plans, but cannot change them.
The Portal Access manager role can perform actions in the Portal Access and the Tasks modules, but cannot perform any other actions in the model.
User role assignment
After roles are created in Incentives, they must be assigned to specific users.
After roles are assigned and users log in to their model, they can view and perform only the actions that are allowed in their user roles. Sally is assigned to the role of Portal Access manager. If Sally logs in to the production environment of the model, she has access to the Portal Access and Tasks modules only, and she can perform any action.
When John logs in to the development environment, he can build and change compensation plans. If he logs in to the QA environment, he receives a warning message if he tries to make any plan changes.