Bamboo PMOProposed MBR-10 Jira status not retrieved

Policy Change Triggers, Notifications and Syncs

Proposed tenth MBR initiative · prepared 16 August 2026

Sixteen areas reviewed. Twelve are within Bamboo’s control to change.

An automated e-delivery opt-out cancelled a customer's policy. We cannot say how many others.

  • A new customer does not sign the e-delivery document. After 30 days our system opts them out automatically.
  • That opt-out runs as a full policy change. It re-prices the policy and re-runs every vendor check.
  • It also removed the customer's automatic payment. Nobody told the customer or Operations.
  • The invoice went unpaid. The policy cancelled for non-payment.
  • The customer paid. We could not reinstate it — our own automated transaction blocks back-dated work. They stayed uninsured with their money on the account.
  • Operations asked for the list of affected policies on 1 July. It still does not exist.

What this is costing Bamboo

Customer and regulatory impact
Policies cancelling that should not cancelCustomer believes autopay is running. It is not. Confirmed on one policy. Total unknown.
Customers uninsured after payingReinstatement blocked by our own automated transaction. The gap in cover is ours, not theirs.
Premiums changing with no change to coverAn opt-out raised Coverage A because a vendor returned different property data on the re-run.
Documents to the wrong addressPolicyCenter has not passed address, phone, email or name changes to BillingCenter since 18 June. Our story cards record that misdirected checks lead to DOI complaints.
Return premium emails not sendingThe same broken link stops the automated return premium notifications reaching customers.
Operations working blindThe audit record shows that a change happened but not what changed. Every policy is opened and compared by hand.

The numbers

12 of 16
areas are within our control to change
8 configuration, 3 process, 1 from the Palisades upgrade. The remaining four are fixed by Guidewire and cannot be changed, so the exposure there is what we put through them.
2 months
PolicyCenter has not synced contacts to BillingCenter
Broken by our R4.3 Palisades upgrade, 18 June. GWMAIN-15516 still open. The manual workaround has also stopped working.
6 weeks
since Operations asked which policies were affected
GWMAIN-14375, requested 1 July and asked again since. Not built.
6
separate faults open on one message queue
GWMAIN-16675, raised 4 August, unassigned. One is a race condition on the autopay approval message.
0
alerts when any of this happens
Nothing alerts when autopay is removed, a premium changes automatically, or a queue stalls. Every failure so far was found by a person noticing a symptom.
303 of 346
requirement cards carry the same risk rating
All rated "4 - Full Product Alignment", including e-delivery, which Guidewire has no equivalent for.

What we are asking for

1
Stop automated processes running against live policies during business hours They hold the same write access as an underwriter and run unattended. Restrict them to overnight and stop them binding where a premium has changed.
Days
2
Produce the list of affected policies The data is in PolicyCenter. Until this exists we cannot say whether it affects nine customers or nine hundred.
Days
3
Assign the message queue faults and the contact sync regression GWMAIN-16675 is unassigned. GWMAIN-15516 has been open two months on a fault we introduced.
This sprint
4
Notify on changes to how money is collected or how a customer is contacted Guidewire already provides activities, notifications and alerts. None is configured for these changes.
Weeks
5
Decide whether e-delivery should be a policy change at all It is a contact attribute, not a policy term. As modelled, it re-prices the policy every time it fires. Design decision for the Salt Lake City session.
Design decision
The request

Approve a tenth MBR initiative for change control and system observability. None of the nine existing initiatives covers it. All nine are affected by it. Handling these inside individual initiatives means fixing each symptom separately and never the cause.

All sixteen areas, with what each can set off, the impact on the insured and on the policy, a proposed action, and the Guidewire page or Jira key behind every claim, are on the Issue chart tab. Sources: Guidewire PolicyCenter and BillingCenter Application Guides release 2026.07.0, Jira project GWMAIN, and 622 Bamboo story cards. Jira statuses are as at 16 August 2026.

1. Every area where a change can set something else off

One row per area of the system. Read across for whose setting it is, what it can trigger downstream, what the insured experiences, what happens to the policy record, and what should be done. Select any coloured trigger in the What it can set off column to show only the areas that affect it, listed in full beneath. The Executive summary tab has the case in six bullets and the five actions we are asking for.

2. Every automated process that can modify a live policy

This is an inventory, not a list of defects. Eight entries are standard Guidewire behaviour and are recorded so that the complete set is visible. Three are Bamboo's and appear as findings in section 1. This inventory is not known to be complete. Producing a complete one is the first task of the proposed initiative.

3. Changes that should generate a notification and currently do not

Guidewire provides activities, notifications and alerts as standard functionality. None has been configured for a change to how money is collected or how a customer is contacted. That set of changes accounts for most of the customer impact identified in this review.

4. What each setting origin means

Every finding in section 1 is assigned exactly one of these four values. The values do not overlap.