Permission setup is restricted to internal BriteCore staff.
BriteCore offers two forms of permissions:
- Version 1 (V1) is nonrestrictive permissions, where by default you have access to all of BriteCore unless restrictions are added.
- Version 2 (V2) is restrictive permissions, where by default you don’t have access to any of BriteCore unless granted access.
You can learn more about permissions and restrictions as they relate to Permissions V1 in this overview.
Permission levels
With V1 permissions, by default users have access to all of BriteCore. After you add permission levels, you can add rules. When you add rules to a permission level, you can restrict access to specific areas, functions, and UI elements by selecting the None radio button in the Access column of the newly added rule. If necessary, you can grant access to areas by adding a rule and selecting the Read or Read/Write radio buttons in the Access column. To learn more about adding permission levels, see Add permission levels. To learn more about permission rules, see Add permission rules.
Rules and restrictions
As you begin to type in the rule box, a list of available URLs and functions appear in a dropdown list. You can place restrictions on both the Agent and Administrator portals. To apply restrictions for the Agent portal, select a rule that begins with agent/. To apply restrictions for the Provider Administrator portal, select a rule that begins with britecore/. When selecting a rule and applying restrictions, the restrictions will appear to the far right of the rule expression. For example, adding the rule britecore/claims/accounting and selecting the None radio button restricts the user from the Accounting tab of the Claims module. The user can still access BriteCore and the Claims module.
You can restrict users from specific areas, functions, and UI elements by doing one of the following:
- Using URLs. When coupled with selecting the None radio button, URLs will restrict users from web pages, as each BriteCore page has a unique URL. For example, when you add the rule britecore/claims and select the None radio button, a user is restricted from the Claims module.
- Using camelCased verbs. When coupled with selecting the None radio button, camelCased verbs can restrict users from a front-end function and from UI elements. For example, when you add agent/policies/submitQuote and select the None radio button, a user is restricted from submitting an application. When you add agent/policies/accountsReceivable/makePayment and select the None radio button, a user is restricted from the Make Payment button.
- Using server-side restrictions, which can restrict users from backend functions.
Assign permission level
Role permissions
BriteCore is automatically added with the roles of agent, agency, agency group, claims adjuster, employee, and underwriter. After completing the Permission Levels section, you can assign permissions to each role in the Role Permissions section. When you assign permissions to a role, all contacts with that role have the permissions identified in the Role Permissions section. See how assigned permissions impact a specific role in Table 1.
Table 1: The impact assigned role permissions have on contacts with the agent role.
|
Agent role |
Assigned role permissions: Agent |
The contact has agent permissions. |
Assigned role permissions: Employee |
The contact has employee permissions. |
Assigned role permissions: None |
The contact has full access to BriteCore. |
Permission level in Contacts module
While you can assign permission levels to a role within Role Permission, permission levels are also managed on a per-contact basis within the Contacts module for all contacts that have login credentials.
Relationship between role permissions and permission level
When you assign permission levels to a contact that already has an assigned role permission, one of the following occurs:
- The contact’s permission level is both the permission level assigned in Role Permissions and the permission level assigned in the Contacts module. This occurs when permission levels are assigned in both areas and the permissions don’t conflict.
- The contact’s permission level is the permission level assigned in the Contacts module. This occurs when permission levels are assigned in both areas; however, the permissions conflict.
If you don’t assign a permission level in the Contacts module, the contact will default to the permissions assigned in Role Permissions. In Table 2, see the interaction between permission levels assigned in Role Permissions and the Contacts module, and the impact it has on a contact.
Table 2: Interaction between permission levels assigned in Role Permissions and the Contacts module, and impact on a contact with the agent role.
|
Contacts module Permission Level: Agent |
Contacts module Permission Level: Employee |
Contacts module Permission Level: None |
Role Permissions: Agent
|
The contact has Agent permissions. |
The contact has Employee Permissions. |
The contact has Agent Permissions. |
Role Permissions: Employee
|
The contact has Agent Permissions. |
The contact has Employee Permissions. |
The contact has Employee Permissions. |
Role Permissions: None
|
The contact has Agent Permissions. |
The contact has Employee Permissions. |
The contact has full access to BriteCore. |
Usage considerations
When you update a user’s permissions, the user must log out of BriteCore and then log back in for the new permissions to take effect. When a permission rule is locked, the rule can’t be deleted by anyone other than BriteCore staff.