BriteAccess overview

As BriteCore’s access control system, BriteAccess allows administrators to determine who can do what in BriteCore. BriteAccess works with BriteAuth, BriteCore’s integrated login, authentication, and user management product, and the Contacts module, BriteCore’s contact repository.


BriteAccess allows administrators to filter access and set permissions for business users by role.

The Access-Control Permission (ACP) is the main construct of the BriteAccess framework. The ACP defines whether to allow or deny a certain action based on specific circumstances. Associating a role with an ACP potentially affects users assigned that role.

At a high level, BriteAccess ACPs allow for access control through three different mechanisms:

  • Target resource: Allows or denies access to a platform resource. For example, an ACP may state that associated users can only create or read Policy records from Policy Admin but deny them the ability to create or read Claim records from BriteClaims.
  • Intended action: Allows or denies a specific action or intention to be fulfilled. For example, an ACP may state that associated users can create and read a BriteNotes Note but deny any attempt to delete one.
  • Target record: Allows or denies access to a specific resource record or instance. For example, adjusters can access only the specific records their manager has authorized them to access.

Key features

BriteAccess has several key features:

  • Agent data filtering
  • Module restriction
  • Policy Document permissions
  • Note type restrictions

Agent data filtering

Agents and agencies can only create or view records associated with their agency or agency group, and users can only create Claims FNOL for policies under their user or user group.

Module restriction

Administrators can grant or deny users access to specific BriteCore modules. For example, BriteLines can be restricted to only administrators or content analysts.

Policy Document permissions

Administrators can control which users can access documents based on the document source. For example, agents can be denied access to credit reports from third-party vendors.

Note type restrictions

Administrators can restrict which user roles can create and view specific note types. For example, agents can’t create or view Legal Notes.


BriteAccess differentiators:

  • Platform permission management
  • Custom roles and permissions

Platform permission management

BriteAccess allows administrators to manage permissions from a single location and deploy them across key business areas like quoting, policies, billing, claims, and documents.

Custom roles and permissions

BriteAccess provides administrators the ability to create as many roles as they want and customize permissions for every role, which allows them to create different levels of permissions for each role. For example, if an administrator wants to give senior agents different permissions than other agents, they can create a Senior Agent role and customize the permissions for senior agents. Senior agents would still be agents in the system but would have different permissions than other agents.

User roles

Administrators can use BriteAccess to control and manage authorization and access for user roles and specific users.