Enhancements
Restricting access to Manual Commission Override (BC-15876)
The ability to hide or show the manual commission override within the Administrator’s view of the policy information is now available. Administrators can configure permissions to control access to the manual commission function by navigating to Settings > System Wide > Permissions. This is done by setting the permission registry for BriteCore/policies/manualCommission to "None”. Once this permission is set for a user group, when a specific user of that group signs in and navigates to BriteCore > Policies > Information, the option to override the commission manually will no longer be visible.
New permission registry entry to control access to void Print State for attachments (BC-14645)
With BriteCore’s focus on the separation of duties, a new permission registry entry has been added to control whether users can assign the void print state to attachments across different modules, such as contacts, claims, policies, and reports. With the advanced setting Permissions-V2-Restriction enabled or disabled, the void option is removed once permissions are set in the registry. Specifically, setting britecore/policies/printStateUpdatetoVoid to "None" results in the Void option no longer being available in the "Edit Print State" dropdown for attachments located via the Policy > Attachment > Document > Print State section.
Improving render speed of dashboard options dropdown menu (BC-15566)
BriteCore has enhanced the speed of processing to improve the user experience when viewing Dashboards. Now, the dropdown menu that allows choice of the dashboard will render more quickly.
Ability to search policies and contacts by DOT number (BC-14910)
BriteCore has enhanced the policy and contacts search functionality by allowing users to now search for policies and contacts using the DOT number of the named insured(s). This new feature is available within both the policy search and contacts pages. Additionally, the help documentation for these pages has been updated to guide users through the DOT number search process.
Expanded Control for Claim Payment Transactions (BC-16109)
Several new settings have been introduced to enhance flexibility and control in the Claims Module for non-auto. You can find these settings under Settings > Modules > Claims > Options:
- Allow Claim Payment Transaction Date Override (checked by default): If unchecked, the system automatically assigns the payment transaction date based on the entry date, preventing users from manually entering the date.
- Show Payment Method Dropdown with Primary Carrier Payment Methods on Claim Payments (checked by default): This setting controls whether users can manually select a payment method for claim payments. This field enables users to select the appropriate payment method for each transaction if multiple payment methods are used. If unchecked, this field is removed from the claim payment transaction screen.
- Limit Claim Payments to One Category per Transaction (Loss, Adjusting, or Legal) (unchecked by default): A single payment can be split across multiple categories by default. This setting limits payments to one category per transaction. Once a category is selected, others are grayed out unless the amount is reset to zero. This option is useful when payments need to be separated for the different categories, thus if payments for multiple categories are required, each payment must be recorded separately.
Settings > Modules > Claims > Claim Payment Classifications:
- Users can now control which payment types (e.g., check, ACH) are assigned check numbers. For example, checks can be assigned numbers, while ACH transactions are excluded, preserving check number sequencing during export.
Additional changes include:
- External Claim Adjuster Role: Administrators can now enter a vendor number for external claim adjusters under the contact module.
- Claims Processing Table: The table now breaks down the dollar amounts into the three categories—Loss, Adjusting, or Legal—and displays whether the payment is a check or ACH.
Defects
Updated rating behavior for Insured Disclosures in Quote Wizard (BC-15750).
In the Quote Wizard, previously, when a user added, removed, or changed an insured disclosure on the "3. Risks" tab, they were not prompted with the “Calculate Rate” button on the "4. Rating" tab. Additionally, previously, the "Calculate Rate" button in the Quote Wizard provided different results compared to the "Rate and Save" button in the Admin Builder. The rating process for agents did not include all relevant claims. BriteCore has now updated the frontend behavior to always trigger the "update risk" call whenever there is a change on the "3. Risks" tab. This ensures that all claims are accounted for in the rating process.
Corrected amounts on Renewal Billing statements by adding Reinstatement as a Debit Type (BC-15412)
Clients experienced issues where Renewal Billing Statements displayed incorrect amounts due to the system needing to transfer all debits successfully across terms. Previously, only non-payments, NSF (non-sufficient funds), and invoice types were considered during the debit transfer process. Reinstatement rows on account history were not included, leading to incomplete balances. To resolve this issue, reinstatement was added as a valid debit type for transfer, ensuring that all relevant charges are accurately reflected in renewal statements moving forward.
Fix for incorrect payment methods being assigned to mortgagee contacts in Quote Wizard (BC-13521)
BriteCore introduced a Cancel button at the bottom of the payment form in the Quote Wizard, allowing agents to close the form and prevent accidental entry of payment methods. This fix ensures that while payment methods can still be added to Mortgagees, agents now have the option to cancel the process easily, preventing unintentional assignments.
The agent experience was updated because they mistakenly added the insured's payment methods to Mortgagee contacts when selecting Mortgagee billing, which doesn't require a payment method. As a result, Mortgagee contacts were being assigned payment methods that did not belong to them. Users were also unable to cancel a payment method once initiated, leading to confusion and requiring a page reload or navigation between steps to correct the error. BriteCore recommends that carriers review the payer and payment methods to ensure they align during policy renewal.
BriteCore Policyholder Mobile App: push notifications restored (BC-15617)
In this release, BriteCore addressed an issue where push notifications were failing to reach policyholders on their mobile devices. As part of BriteCore's notification system, insureds are informed of key events through both email and push notifications. Due to this issue, policyholders were not receiving timely updates on their devices. With this fix, push notifications are now fully restored, ensuring that policyholders are promptly informed of important events.
Carrier Experience Report notified as "already running" when not running (BC-15789)
In this release, BriteCore removed an incorrect notification that stated the “Carrier experience report” was running when this report was not running.
Improved Consistency in Permissions V1 (BC-15977)
BriteCore has made an update to the V1 permission engine, addressing confusion caused by inconsistent permission evaluations between parent and child modules. Previously, if a parent module had read-only permissions but a child module had read-write permissions, it could result in unintended access when evaluating permissions for other child modules.
With the new update, parent-level permissions now strictly control access, without being overridden by child permissions. This means that if a parent module is set to read-only, access to its children will follow the parent’s permission unless explicitly defined otherwise.
For example, a user with read-only access to a parent module - Policy- will be able to view the policy but may be granted read-write access to a specific child module, such as payment logs, if configured. Conversely, if a child module has no access permissions, the user will be restricted from accessing that module, even if the parent allows read access.
Note: To check if your site is on V1, go to Advanced Settings and confirm that the engine-version is set to V1.