Automate a post-bind document review
This example creates an underwriting review when a Wind Mitigation document is attached to a policy.
Goal: When a Wind Mitigation document is attached, assign a review to the policy underwriter. Give the underwriter 10 days to complete it and send an alert if the review is not completed in time.
Workflow scope: Policy
Flow:
Trigger — File Attached
The workflow begins whenever a file is attached.
↓
Gateway — File Category = Wind Mitigation
Only Wind Mitigation documents continue down the review path.
↓
Task — Wind Mit Review
Assign the task to the Underwriter on policy with a 10-day due date.
↓
Wait — Task state or timeout
Wait for the Wind Mit Review task to be completed or for the 10-day maximum to expire.
↓
Completed → End
Timeout → Alert Underwriter → End
Once the workflow is configured, resolve any outstanding issues and publish it.
The result is an automated, time-boxed review process: qualifying documents automatically create the appropriate task, route it to the underwriter, and generate a notification if the work is not completed in time.
Capabilities and Manual Steps
Workflows support:
- Document-based routing
- STP review workflows
- Task chaining and outcome-based branching
- Deadline and subjectivity follow-up
- Multiple tasks from a single event
- Role-based and task-owner assignment
- Alerts and notifications
- Escalation based on task due dates
These actions need a person:
System actions are limited. The System Action node supports Create Claim Folder. Workflows cannot cancel, non-renew or void a policy. A workflow can instead create a task or alert for someone to perform the action.
Workflows cannot generate documents from a workflow node. Workflows can respond to attached documents but cannot automatically generate a new document.
Capacity is task-count based. Assignment considers the number of open tasks, not estimated effort or available work hours.
Priority does not automatically age. There is no continuous priority-aging mechanism or separate escalation-date field beyond the task due date.
Phone and inbound email are not workflow triggers. Work that starts from a call or an inbound email begins manually or through an external system.
Agent-facing task visibility is separate. Agent dashboards and task visibility are handled through the Agent Portal rather than the workflow builder.
Timers run daily. Wait timers resume through the daily background process, so they are not intended for precise sub-day automation.
Scope and entity are permanent. A workflow’s scope and a task type’s entity cannot be changed after creation.
When a step cannot be automated, the recommended pattern is to create a Task when the action needs to be tracked or an Alert when someone only needs to be notified. This keeps the process visible in BriteCore even when the final action requires a person.
