BriteClaims: Permissions overview

In the BriteClaims system, permissions determine the UI elements that users can view and access. Permissions are configurable and set up during implementation. Two permission types are used within BriteClaims:

  • Permissions based on role only, which is managed by BriteAccess.
  • Permissions based on role plus claim status and/or exposure status, which is managed by BriteRules.

Permissions and UI elements

Permissions determine if users can view a UI element and access a UI element or if users are restricted from viewing a UI element and accessing a UI element. Users have different permission levels due to their roles, which are determined by their area of focus and their level of experience.

Permission levels

For BriteClaims, permissions are broken down into five levels, where permission level 1 is nonrestrictive and permission level 5 is the most restrictive.

  • Permission level 1: When designated for a specific role’s access to a UI element, a user with that role can view and access the UI element.
  • Permission level 2: When designated for a specific role’s access to a UI element, a user with that role can view the UI element, but can’t access it.
  • Permission level 3: When designated for a specific role’s access to a UI element, a user with that role can view the UI element, but can’t access it. The UI element is also grayed out. If a user with that role attempts to access the UI element, a message will appear explaining that the user can’t access the UI element.
  • Permission level 4: When designated for a specific role’s access to a UI element, the UI element is hidden for a user with that role. The user with that role can’t view or access the UI element.
  • Permission level 5: When designated for a specific role’s access to a UI element, the UI element isn’t even available to a user with that role. Permission level 5 occurs when permission level 4 restricts a role from accessing a section that has additional UI elements. While the restricted section is hidden, the UI elements contained within that section aren’t even available, and therefore have permission level 5 restrictions.

Implementing permission levels

With the permission levels defined, use the below case study to see how the permission levels would be applied to the following user roles: Agent, Claims Assistant, and Claims Adjuster.

 A client is establishing BriteClaims permissions for Agents, Claims Assistants, and Claims Adjusters in the company. The client has decided that not all users should be able to edit information contained on the claim file’s Details screen.

  • The client wants to restrict Agents from accessing BriteClaims.
  • The client wants to allow Claims Assistants to view information on the claim file’s Details screen, but wants to restrict their ability to edit information.
  • The client wants to allow Claims Adjusters to view and edit information on the claim file’s Details screen.

Based on this case study, the following restrictions would apply:

  • Agent: Permission levels 4 and 5 are applied to BriteClaims.
    • BriteClaims won’t appear in the Agent menu.
    • Permission level 5 is applied to all other UI elements contained within BriteClaims, as these UI elements aren’t available to the Agent.
  • Claims Assistant: Permission level 3 is applied to the Edit links on the Loss Information, Loss Location, Cause/Peril, Onsite Services, Additional Claim Dates sections of the Details screen.
    • The Claims Assistant can view information on the Details screen and can view the Edit buttons, but the Claims Assistant can’t access the Edit links.
  • Claims Adjuster: Permission level 1 is applied to the Edit links on the Loss Information, Loss Location, Cause/Peril, Onsite Services, Additional Claim Dates sections of the Details screen. The Claims Adjuster can view and edit information on the Details screen.

The purpose of establishing different permission levels is to mitigate errors due to oversight and to mitigate instances of fraud.

Role-based permissions

Roles and their assigned permissions are managed in BriteAccess and are configured during implementation. When you create or invite a new user and assign the user’s role(s), the role(s) assigned is/are already associated with permissions, which dictate what the user can view and access.

Note: If you need to create a new role, please contact your support team.

Role plus claim/exposure status permissions

Permissions based on role plus claim/exposure status are created and managed within BriteRules and are established during implementation. Permissions created for each role plus each claim/exposure status determine what actions a user with a specific role can complete when a claim’s status is New, Open, Closed, or Reopened or when an exposure’s status is Open, Closed, or Reopened. For example, a Claims Adjuster should be able to edit loss information when a claim is New, Open, or Reopen, but the same Claims Adjuster shouldn’t be able to edit loss information when a claim is Closed.

Troubleshooting

If you can’t access a feature or section in BriteClaims, and you believe this is an error, these questions must be answered:

  • What is your assigned role?
  • How are rules set up for this specific role?

If it’s determined that you’re prevented from accessing specific features or sections due to your role and the assigned rules, then your company must determine if a change should be made to the way rules are set up for this specific role.

Additional considerations

For more detailed information on establishing user roles and managing rules see Establish user roles for BriteClaims and Manage rules for BriteClaims.