Subjectivities

What are Subjectivities?

Subjectivities are specific conditions, requirements, or stipulations that must be satisfied before an insurance policy can be bound, issued, or remain in force. Think of them as “to-do items” or checkpoints for a policy, such as providing a signed inspection report, proof of repairs, or additional documentation.

Note: In BriteCore, subjectivities differ from underwriting rules in purpose and timing, but both can be automated. Underwriting rules are enforced automatically during quote submission to evaluate eligibility or trigger referrals. Subjectivities, on the other hand, represent conditions that must be satisfied before a policy can be bound or issued. While they are often associated with manual follow-up, such as submitting documents or completing inspections, BriteCore also supports automating the assignment of subjectivities based on predefined criteria.

Why are Subjectivities Important?

• Risk Management: Subjectivities help ensure all necessary steps are taken to mitigate risk before a policy becomes effective.
• Compliance: Subjectivities ensure regulatory and company-specific requirements are met.
• Transparency: Subjectivities provide a clear record of outstanding requirements for both underwriters and agents.

Where do Subjectivities Appear in BriteCore?

Subjectivities are managed in the policy workflow:

• During Underwriting: Subjectivities may be added either by an automated process or a human underwriter.
• On Policy Records: Users can view, add, update, or mark subjectivities as satisfied.
• In the Policy interface: There is a dedicated “Subjectivities” section for each policy or revision.

How do I Work with Subjectivities in BriteCore?

1. View Subjectivities

1. Open the desired policy and navigate to the Subjectivities section.

Note: When subjectivities are present, a table will appear with the list of required actions. 

2. Review the list of subjectivities, including their status (e.g., Not Satisfied, Satisfied, Waived, Expired, Canceled.), due dates, assignees, and any additional notes/description.

2. Add Subjectivities Manually 

1. Select the Add Subjectivity option to add a new subjectivity.
2. Complete the required fields:
   1. Definition: Choose the type of subjectivity (e.g., “Inspection Report”).
   2. Due Date: Set when it must be completed.
   3. Status: Set the initial status (usually “Not Satisfied”).
   4. Statement/Description: Add any additional details or clarification.
   5. Expiration Action: Cancel flat, pending cancellation, or none
      • Note: Pending Cancellation places the policy into a temporary state where it is not yet cancelled, but will be after a configured notice period. The process and timing are controlled via policy lifecycle settings, and additional actions (notices, document generation, extensions) depend on those settings.
3. Save the subjectivity. It will now appear in the policy subjectivities list.

3. Edit Subjectivities

In the Action column:

1. Select the pencil icon to edit the fields:
   • Definition: Choose the subjectivity type (e.g., Inspection Report).
   • Due Date: Set when it must be completed.
   • Status: Update the status (e.g., Waive, Expire, or Cancel).
   • Statement/Description: Add any additional details or clarification.
2. Select the checkbox to mark when requirements are met (e.g., Mark as Satisfied once documentation is received).
3. Select the trash can icon to delete the subjectivity. 

Note: All changes to subjectivities result in a system-generated note. 

4. Understand Subjectivity Statuses 

• Not Satisfied: Requirement is outstanding and must be completed.
• Satisfied: Requirement has been met and verified.
• Waived: Requirement has been dismissed by an authorized user.
• Expired: Requirement was not met by the due date.
• Canceled: Requirement is no longer applicable due to policy changes.

How do I Configure Subjectivities?

Step 1: Define Subjectivities

1. In BriteCore, navigate to Lines > Subjectivity Definition.

2. Create a New Subjectivity Definition:

1. Select Add Definition.
2. Enter a Name (e.g., Inspection).
3. Provide a Description to clarify the purpose of the subjectivity.
4. Set the Status to either Active or Inactive to control availability.
5. Choose the Due Date Type which determines when the subjectivity must be resolved in relation to the policy lifecycle and what system actions are triggered.
   • Pre-Bind
     • Must be resolved before the policy can be bound.
     • If any Pre-Bind subjectivities are still open, the system will block binding.
     • Used for critical requirements that must be satisfied prior to finalizing coverage.
   • Post-Bind
     • Allows the policy to be bound even if these subjectivities are unresolved.
     • The system tracks and displays outstanding items for follow-up.
     • May restrict downstream actions (e.g., endorsements, renewals) until resolved.
     • Triggers reminders or tasks to responsible users.
     • Does not block binding but may block certain future workflow steps.
   • Post-Issue
     • Allows the policy to be issued even if the subjectivity remains open.
     • Outstanding items are tracked and may initiate follow-up workflows (e.g., reminders or escalations).
     • May limit post-issuance activities (e.g., renewals, claims) if unresolved.
       • Typically used for lower-risk or administrative conditions that don’t impact binding or issuance but still need completion.
6. Specify whether the subjectivity is Mandatory (Yes or No).
   • If marked Yes, the subjectivity must be satisfied before the related process, form, or workflow can proceed.
7. Set the Due Within Days value.
   • This determines how many days after a trigger (e.g., creation or assignment) the subjectivity is due.
8. Enter the Display Statement, which appears on the subjectivity.
   • This is a free-text or rich-text field where you can provide instructions, context, or guidance for the user within the policy view.
9. Select Save to create the new subjectivity definition.

Step 2: Configure Rule Logic

Decide when each subjectivity should apply (e.g., for certain products, risk types, or premium thresholds).

Common triggers include:

• Policy type/class
• Coverage amount
• Location/state

Customer segment

• In BriteCore, navigate to Lines > Effective Date > Underwriting > Rules.
• For each rule, define the following:
  • IF: Specify the trigger conditions
  • THEN: Add an Effect with the Action set to Add Subjectivity, and select the appropriate subjectivity definition.
  • Select Save.

Example:

• IF Roof Type = Shingle AND Coverage Limit > $1M
• THEN require subjectivities: Building Inspection AND Loss Runs

Note: Additional event-based triggers have been added to initiate subjectivities at the following stages: Quote Submitted, Policy Issued, and Policy Active.

Step 3: Set Permissions

• Only certain user roles (typically Underwriters or Administrators) can add, modify, or remove subjectivities.
• Permissions are enforced by the system and may depend on the policy’s current status (e.g., subjectivities can’t be changed on active or cancelled policies).
• The following permissions are located in the Permissions section, and they control access to subjectivities within the policy module and can be assigned to specific users or roles. 

Note: These permissions can be combined to tailor access depending on user roles (e.g., underwriters, CSRs, or agents)

What are Best Practices?

• Be Specific: When adding subjectivities, provide clear and detailed instructions.
• Set Realistic Due Dates: Align due dates with policy timelines and client expectations.
• Communicate: Notify assignees of new subjectivities and follow up as needed.
• Review Regularly: Check outstanding subjectivities during policy review or renewal.