+
The bidirectional integration between Plansight's quoting platform and Vertafore's BenefitPoint agency management system — keeping every plan, rate, benefit summary, and renewal in sync between the system brokers quote in and the system of record they bill from.
A purpose-built, two-way data bridge between Plansight and BenefitPoint. Brokers quote and shop plans in Plansight, then push them to BenefitPoint with one click — and BenefitPoint's authoritative book of business flows back into Plansight so brokers always work from a single source of truth.
Brokers associate a Plansight account with a BenefitPoint account. Every product, plan, rate, benefit summary, and contribution rule on the BP side is imported and kept current — automatically — through scheduled change-tracking calls.
When a broker finishes shopping and the client picks a plan, Plansight builds the BenefitPoint product, benefit summary, rate structure, contributions, and eligibility — and pushes it directly into the BP record. No re-keying, no double entry.
Every plan tracks an origination reason — new, renewal, or replacement — and the integration applies the right copy-from-prior, send-fresh, or auto-match logic per reason. Renewal pushes auto-match the BP plan; new pushes prompt for taxonomy.
Every brokerage configures its own BenefitPoint API credentials and runs in isolation — separate Web Services authentication, separate per-brokerage cache, separate feature flags. The same code path serves single-office shops and 50-office multi-region brokerages alike.
Brokerages live in BenefitPoint. It's where they manage commissions, books of business, renewals, and the agency operations that keep the lights on. Plansight is where the work of quoting happens. Without integration, those two worlds require duplicate data entry on every plan that gets sold.
Quote in the platform built for it. Push the result into the system of record with one click. No spreadsheet hand-offs, no dual entry, no "I forgot to update BP." When BP is the source of truth on renewals, Plansight stays in lockstep — automatically.
Compliance, commissions, and reporting all run off BenefitPoint. The integration means every plan Plansight produces is BP-correct: right product type, right carriers, right rate structure, right benefit summary, right effective dates. Audit-ready by default.
The plan that wins on screen in Plansight is the same plan that gets billed, renewed, and serviced. No translation errors. No "we're showing one rate but BP has another."
Plansight is BenefitPoint's preferred quoting partner. The integration makes Plansight a natural extension of BP — the front-end where the modern broker workflow lives, feeding the agency-management spine BP already provides.
Quoting, presentation, and shopping are upstream activities — they're best done in a tool purpose-built for them (Plansight). Servicing, billing, commissions, reporting, and historical tracking are downstream activities — they belong in the system that's done them for decades (BenefitPoint). The integration is the seam: it makes the upstream and downstream behave like one system.
When a broker hits "Push to BenefitPoint" in Plansight, here's what happens.
The job loads every quote in the plan group from a fresh database read, verifies they all belong to the same plan group, and clears any prior error state. Single-mode pushes one quote; multi-summary mode pushes every quote as its own benefit summary.
Before building anything, the integration calls GetAccount to fetch the current primarySalesLeadUserID and primaryServiceLeadUserID directly from BP. These were historically cached on the Plansight quote, but recent changes always re-fetch them so renewals never carry stale lead assignments.
ProductModel::fromPlansightModels($quotes) assembles the BP product object: name, plan type, carriers (writing + billing), origination reason, effective and renewal dates, policy/group number, and every benefit attribute mapped through Plansight's BP-code dictionary.
By default, products push via the modern REST endpoint — CreateProductRest with a JSON body. Brokerages on custom WSDL URLs push via SOAP CreateProduct. The product is created with view level Core (110); admin overrides are available to "overwrite" an existing product.
After the product is created, postProcess() runs the dependent operations: UpdateBenefitSummary (or CreateBenefitSummaryFromCopy on renewal/replacement — which carries contributions and eligibility forward from the parent plan), CreateRateRest for the single rate type Plansight picked (tiered schedule matching the plan's 3/4/5-tier setup for medical, dental, and vision; age-banded for STD/LTD; per-unit volume basis for life; specific + aggregate pairs for stop loss), and a DeleteBenefitSummaryRest to clean up BP's auto-created "All Employees" empty summary if the broker wants to replace it. Contributions and eligibility are never pushed as standalone calls — on a fresh "new" product, the broker fills those in BP after the push lands.
If any step fails, the JSON error response is parsed and decorated. "Invalid billingCarrierID for the selected billingCarrierType" becomes "Billing carrier 'Aetna' is not valid for product type 'Medical PPO'" — with the carrier name, billing carrier type, and product type all resolved from the per-brokerage cache. The error is stored on the quote so the UI can show it next to the right plan.
The push runs as an async queue job. Pushing a multi-option plan group with renewal carry-over from prior plans can fan out to 20+ BP API calls — and BP's API can take a few seconds per call. Running on the queue means the broker's UI returns instantly, the user sees a "pushing..." status, and any retries happen without breaking the user's flow.
Two push-side capabilities are toggled per-brokerage rather than universally. Both are off by default; turn-on is a deliberate decision per brokerage.
replacement and links the new push to the prior product. For some brokerages this isn't desirable (their BP workflow expects every push to be a fresh new), so we expose a flag that disables the replacement path entirely — every push goes in as new.Both flags live on the brokerage record. Coordinate with whoever owns brokerage configuration before flipping either one — they meaningfully change what BP sees on the other side.
Plansight stays current with the BenefitPoint book of business through three nested jobs running on a low-priority queue.
PullProducts(brokerageId) finds every Plansight group with a benefitPointId and dispatches PullProductsByGroupId for each — typically hundreds of jobs for a large brokerage.
FindProducts(benefitPointId) lists every product on the BP account. The integration deduplicates BP's known internal product-replication bug, applies the reachBackRenewalDate filter to skip ancient plans, and dispatches PullProductById for each survivor.
Service::importProduct(groupId, productId) calls GetProductRest, FindBenefitSummaries, FindRates, GetContributionsSummaryList, GetEligibilityRuleSummaryList — and assembles a complete Plansight quote from the responses.
Every numeric BP attribute ID (45 = Per Individual deductible, 386 = Primary Care, 414 = Specialist, 902 = Telehealth, etc.) is translated to its Plansight equivalent through the master attribute map. Unsupported plan types are filtered against the deny-list.
A QuoteBenefitHistory is created or updated with source = 'benefitPoint', BP's product ID written back via setIntegrationData, and the right origination reason inferred from the BP product's history.
The full pull is heavy. For day-to-day freshness, the benefit-point:pull-changes artisan command runs on a schedule, calling BP's FindChanges API to pull only what's changed since last run — minutes of work instead of hours.
BenefitPoint's product taxonomy has hundreds of entries — annuities, executive benefits, individual lines, retirement products, and more. Plansight integrates the 24 plan types brokers actually quote in modern employee benefits.
Synced Medical HMO, PPO, POS, EPO, Indemnity
Synced Prescription Drug Carve-Out
Synced Stop Loss
Synced Telehealth, Patient Advocacy
Synced Transplant Carve-Out
ToDo Medical Gap (GAP)
Synced HRA
Synced HSA
Synced FSA
Synced COBRA Administration
ToDo FMLA / Leave Management
Synced Dental — Managed, PPO, HMO, Triple Option, Indemnity
Synced Vision & Voluntary Vision
Synced Basic Life and AD&D
Synced Voluntary Life and AD&D
Synced Short Term Disability (STD & Voluntary)
Synced Long Term Disability (LTD & Voluntary)
Synced Employee Assistance Program (EAP)
Synced Legal, Pet Insurance, Identity Theft
Synced Accident & Voluntary Accident
Synced Hospital Indemnity
Synced Critical Illness & Voluntary Critical Illness
Synced Cancer Coverage & Voluntary Cancer
Skip Group Term Life, AD&D-only, BTA
Skip 401(k), 403(b), 457, 529, IRA
Skip Annuities, Universal Life, Whole Life
Skip Individual Medical / Dental / Vision
Skip Executive Benefits (FCC) lines
Skip International Bundled, State Statutory DBL/TDB/TDI/SDI
BenefitPoint divides offerings into Plans (carry rate and benefit data — Medical, Dental, etc.) and Products (services without rate structures — Telehealth, COBRA, etc.). Plansight syncs Plan Information for both, but only pulls Plan Design + Rates for actual Plans.
Every plan type, product type, and benefit attribute · filterable by sync status
Customer-facing version: what we sync, by benefit type (print-ready) →
Customer-facing version: benefit attribute map, line by line (print-ready) →
BenefitPoint has always allowed a renewal to be a different product type than the plan it renews — productTypeID and parentProductID are independent fields on its Product struct. The restriction was Plansight's: the push hard-assigned the parent's type. PS-9170 lifts it, so a PPO group renewing as an HMO stays one renewal chain instead of becoming an orphan plan. The matrix below is the entire decision surface, derived from a live getProductTypes() call cross-referenced against Plansight's product-type registry — not from documentation.
Every type inside these families declares an identical rate-type set, so the prior plan's rates copy to the renewal untouched. This is the behaviour Medical demonstrates, and the case the feature was built for.
| Benefit family | Interchangeable product types | Rate types | Export |
|---|---|---|---|
| Medical medical |
100 HMO · 110 PPO · 120 PPO 3-Tier · 130 POS 2-Tier 140 POS 3-Tier · 150 EPO 1-Tier · 160 EPO 2-Tier · 170 Indemnity |
1 / 33 / 48 |
Yes |
| Dental dental |
180 Managed · 190 PPO · 191 Vol PPO · 195 HMO 196 Vol HMO · 200 Triple Option · 210 Indemnity + 1170 Voluntary Dental (additional product) |
3 / 35 / 49 |
Yes |
| State Disability / PFL spfl |
292 NY DBL · 293 NJ TDB · 294 HI TDI 295 RI TDI · 296 CA SDI · 297 PR TDI |
46 / 47 |
Yes |
| Short Term Disability stDisability |
290 STD · 291 Voluntary STD + 1190 Voluntary STD (additional product) |
5 / 6 / 7 / 8 / 9 / 10 / 11 / 15 |
Yes |
| Long Term Disability ltDisability |
300 LTD · 301 Voluntary LTD + 1180 Voluntary LTD (additional product) |
12 / 13 / 14 / 16 |
Yes |
| DHMO dhmo |
195 Dental HMO · 196 Voluntary Dental HMO | 3 / 35 / 49 |
No |
DHMO is the one family of the 31 that cannot be exported at all. Its two types would swap cleanly, but benefitPointExport is disabled for it in config/plantypes, so it never reaches BenefitPoint in the first place. Worth confirming whether that is still intended.
Same benefit family, but the two types rate on different structures. The swap is legitimate and BenefitPoint accepts it — the danger is that the prior plan's rates have nowhere to land.
| Benefit family | Product type | Its rate types | Export |
|---|---|---|---|
| Basic Life groupLife |
240 Life and AD&D | 25 / 26 / 27 / 28 / 51 |
Yes |
| 250 Group Term Life | 17 / 18 / 19 / 50 |
||
| Voluntary Life voluntaryLife |
245 Vol Life and AD&D | 25 / 26 / 27 / 28 / 51 |
Yes |
| 260 Voluntary Life + 1370 Vol Life/AD&D (additional product) |
34 |
Voluntary Life is the sharpest case. Swapping 245 to 260 goes from five rate types to a single one, with no overlap. Basic Life is the same shape — 240 and 250 share nothing. These two families are the entire reason a rates warning is worth building; no other family can hit it.
These have exactly one real plan type. A selector renders, but the only alternative is an additional product, which carries no rates and no benefit summary on the BenefitPoint side. Converting to one is a downgrade, not a lateral move.
| Benefit family | Plan type | Additional product |
|---|---|---|
| Vision vision | 230 Vision | 5690 Voluntary Vision |
| PBM Administration pbm | 173 Rx Carve-Out | 5510 Pharmacy Services |
| HSA hsa | 179 HSA | 1630 HSA / HRA Admin |
| FSA fsa | 330 Section 125 | 1600 FSA Admin |
| Critical Illness criticalIllness | none | 1160 Vol Critical Illness · 5480 Critical Illness |
| Cancer cancer | none | 1400 Voluntary Cancer · 5470 Cancer Coverage |
| Accident accident | none | 5500 Accident · 5792 Voluntary Accident |
Critical Illness, Cancer and Accident have no real plan type at all. Both of their options are additional products, so a "swap" there moves between two things that neither hold rates nor a benefit summary. Worth deciding whether the selector should appear for these families, since offering it implies more than it delivers.
One product type apiece, so there is nothing to change to and no selector renders. All of these still export to BenefitPoint normally — the restriction is only on changing type.
HRA Stop Loss New York Disability Employee Assistance Program COBRA Legal Leave Management New Benefits Medical Administration Pet Insurance Advocacy Identity Protection Telehealth Paytient Hospital Indemnity Organ Transplant
parentProductID comes from its own key and Plansight writes nothing back to the parent on push, so a type swap cannot sever or terminate the renewal chain.getRateTypes() returns what the brokerage may push, not what the type defines — it does not guard a cross-structure swap. The rateTypes collection off getProductTypes() does.Medical 125 (Tiered Benefit Medical PPO) exists in BenefitPoint and shares Medical's 1 / 33 / 48 rate structure, but it is commented out of Plansight's registry and therefore never offered. Uncommenting it would also change the new-plan dialog, so it stays out for now.
Verified 22 Aug 2026 against BrokerConnect V4.4, brokerage 1002 · registry source Service::$supportedProductTypesMap · PS-9170 is built and verified against live BenefitPoint pushes but is not yet merged to production.
BenefitPoint's product taxonomy has 426 entries. Only 49 of those carry real plan-attribute structure — these are the plans where "sync" means moving actual benefit data instead of just registering a product category. Plansight syncs 26 of those 49 today, and the page above lists them. This is what the other 23 look like.
The 377 BP plan types not catalogued above are all service/fee admin entries that BP itself flags as "No structure" — annuities, consulting fees, executive-benefit codes, individual lines without plan attributes. Plansight isn't missing any structured plan data on the benefit-line side. The decision space below is purely: of the 23 remaining structured types, which ones do we want to extend the integration to cover?
Gap Medical PPO (3-Tier) — BP 120 · 179 attrs
Gap Tiered Benefit Medical PPO — BP 125 · 144 attrs
Gap Medical POS (3-Tier) — BP 140 · 180 attrs
Gap MH/SA Carve-Out 1-Tier — BP 175 · 50 attrs
Gap MH/SA Carve-Out 2-Tier — BP 177 · 55 attrs
Same shape as the Medical plans Plansight already syncs — likely a schema extension to existing types rather than new top-level benefits.
Gap Limited Benefit 1-Tier — BP 232 · 65 attrs
Gap Limited Benefit 2-Tier — BP 233 · 65 attrs
Mini-med plans — capped-coverage products distinct from major medical. Would need a new top-level benefit type with its own field set.
Gap Work-Life Program — BP 315 · 19 attrs
Gap Wellness Program — BP 317 · 73 attrs
Gap Section 125 — BP 330 · 20 attrs
Work-Life and Wellness could fold into EAP, or stand alone. Section 125 is a tax-treatment doc — useful as compliance metadata but probably not a quoting line.
Skip Group Term Life — BP 250 · 28 attrs
Skip AD&D (standalone) — BP 270 · 37 attrs
Skip Voluntary AD&D — BP 280 · 45 attrs
Plansight syncs combined "Life and AD&D" (240) and "Voluntary Life and AD&D" (245). These are the unbundled siblings. Would extend Basic Life and Voluntary Life rather than add new types.
Skip New York DBL — BP 292 · 8 attrs
Skip New Jersey TDB — BP 293 · 8 attrs
Skip Hawaii TDI — BP 294 · 8 attrs
Skip Rhode Island TDI — BP 295 · 8 attrs
Skip California SDI — BP 296 · 8 attrs
Skip Puerto Rico TDI — BP 297 · 8 attrs
Six plan types, identical 8-attribute shape. Cheap to ship the whole set together — relevant for any brokerage with multi-state employers.
Skip Business Travel Accident — BP 320 · 47 attrs
Skip 401(k) — BP 340 · 76 attrs
Skip International Bundled (1-Tier) — BP 420 · 98 attrs
Skip International Bundled (3-Tier) — BP 410 · 98 attrs
Structured in BP but outside Plansight's modern-benefits scope. Retirement and international plans would represent a product expansion, not a sync extension.
The cheapest win on the board is the state statutory disability set — six plan types with 8 attributes each, all the same shape. Ship them as one set and Plansight covers every U.S. jurisdiction with mandatory state disability. The highest-data win is the Medical extensions — PPO 3-Tier, POS 3-Tier, Tiered PPO, and the two MH/SA Carve-Outs together carry 608 BP attributes, all in benefit field shapes Plansight already knows how to handle. The two big strategic decisions are Limited Benefit (do we add mini-med as a top-level benefit?) and Wellness/Work-Life (do they belong to EAP, or stand on their own?).
BenefitPoint identifies every benefit attribute by an internal numeric ID. Plansight maintains a master mapping that translates those numeric codes into Plansight's named fields, in both directions.
| Plansight Field | BP ID | Notes |
|---|---|---|
| Per Individual Deductible | 45 | Annual medical deductible, in-network individual |
| Per Family Deductible | 44 | Annual medical deductible, in-network family |
| Deductible Type | 973 | Embedded vs aggregate |
| HSA Eligible | 873 | High-deductible health plan flag |
| OOP Per Individual | 53 | Annual out-of-pocket maximum, individual |
| OOP Per Family | 52 | Annual out-of-pocket maximum, family |
| Primary Care | 386 | Office visit copay/coinsurance |
| Specialist | 414 | Outpatient specialist visit |
| Telehealth | 902 | Telemedicine |
| Emergency Room | 184 | ER copay/coinsurance |
| Urgent Care | 555 | Urgent care facility |
| Inpatient | 295 | Inpatient facility & physician |
| Mental Health Outpatient | 407 | Mental health outpatient services |
| Substance Use Inpatient | 670 | Substance use inpatient hospitalization |
| Rx Tier 1 (Generic) | 880 | Preferred generic drug tier |
| Rx Tier 4 | 84 | Non-preferred brand |
| Mail Order | 378 | Mail-order Rx |
BenefitPoint doesn't expose its attribute codes in normal API responses — they're internal IDs. Plansight extracted them via metadata calls (GetBenefitSummaryStructure, GetProductTypes, FindRates) when the integration was first built and maintains them as the source of truth for every push and pull. The full dictionary covers Medical, Pharmacy, Stop Loss, Dental, Vision, EAP, Basic Life, Voluntary Life, HRA, STD, and LTD.
Both sides of the pipe — what comes in from BenefitPoint, and where the resulting data lives in Plansight.
The modern REST endpoint for product creation, rate creation, contributions, eligibility rules, and benefit summary management. The default API surface for new pushes since 2024.
The legacy SOAP API. Plansight binds V4.4 — the .env points at BrokerConnectV4.4.wsdl, whose types come from common-v3.4.xsd. Still used for accounts, listings, structure fetches, and any brokerage configured with custom WSDL URLs. Auth via session token cached for 55 minutes. Read the 3.4 schema, not 3.2 — 3.4 declares fields 3.2 does not, including BenefitSummary.isHdhp.
Where every imported account, plan, rate, contribution, and eligibility rule lands. The same store that powers Plansight's quoting flow — meaning BP-pulled data is immediately available to brokers without a translation layer.
Each brokerage has a dedicated cache holding BP offices, users, writing carriers, and billing carriers. Refreshed by the benefit-point:brokerage-cache command. Powers every dropdown that asks the broker to pick a BP entity.
Bulk pulls and brokerage-wide syncs run on the redis-low queue. Push jobs run on the standard queue with retries and error context capture. Nothing blocks the broker's UI.
The benefit-point:pull-changes command runs on a recurring schedule, calling BP's FindChanges API to keep Plansight current without re-fetching the full book of business.
The integration is designed to work for any brokerage that runs its book of business on BenefitPoint and quotes new and renewal plans through Plansight. The shape of the work is the same regardless of size.
One BP API user, one office, one set of carriers. Onboard once, push and pull from there. The integration's simplest case — and where most of the value comes through with the least configuration overhead.
One BP API user can have access to multiple regions and offices. The integration scopes every operation to the offices the API user can see, so a national brokerage can run dozens of regional offices through a single Plansight tenant without cross-contamination.
Brokerages that operate as multiple legal entities (acquisitions, subsidiaries, partner-brand structures) typically maintain separate BP carrier rosters. Each entity gets its own brokerage configuration — separate credentials, separate cache, separate feature flags — and shares only what should be shared.
Brokerages with hundreds or thousands of employer accounts move large amounts of data on a renewal cycle. The async queue architecture and scheduled FindChanges sync are designed for that scale — bulk pulls run on a low-priority queue, daily delta syncs keep things fresh without re-fetching the full book.
The same operations, the same struct definitions, the same BP code dictionary, the same job runners serve every brokerage running on the integration. Tenant-specific behavior is expressed through per-brokerage feature flags and credentials — never through forks of the integration code itself. That's how it stays maintainable as more brokerages join.
A self-contained Laravel package inside the Plansight monolith, designed to be testable, debuggable, and operable per-brokerage without affecting other tenants.
Backend: Laravel · PHP 8 · ~300 files
API: Native PHP SoapClient + Symfony NativeHttpClient for REST
Storage: AWS DynamoDB (per-brokerage tenant data)
Async: Redis queues — default for push, redis-low for bulk pulls
Cache: Per-brokerage flat-file BenefitPointCache + 55-min session token
Auth: Per-brokerage encrypted Web Services credentials
integrations/BenefitPoint/ ├── Api.php ← auth, SOAP/REST client, retry ├── Service.php ← 3,309-line orchestrator ├── BenefitPointCache.php ├── Controller.php ← all UI/HTTP endpoints ├── ContributionData.php ├── RateData.php ← 188KB rate-mapping helper ├── Operations/ ← 42 API call wrappers ├── Structs/ ← 128 PHP DTOs (Account, Product, │ Rate, BenefitSummary, …) ├── Enums/ ← 112 BP value sets ├── Jobs/ ← 6 async queue jobs ├── Commands/ ← 6 artisan CLI commands ├── Concerns/ ← shared traits ├── Contracts/ ← Operation interface ├── Views/ ← Blade templates └── Scripts/BP.js
Per-brokerage feature flags
Integration on/off, multi-summary mode, custom WSDL URLs — all per-brokerage. Can disable mid-incident without code change.
Structured error capture
Every push error stores parsed JSON, raw response, and resolved entity names on the quote — surfaceable in the UI without digging through logs.
Truncation-aware logging
SOAP request/response logged to bpDebug, with smart truncation for noisy operations like findOffices, createBenefitSummary, and getBenefitSummaryStructure.
A typical client's plan lives in both systems for years. Here's how the integration handles each phase of the renewal cycle.
Broker shops a new plan in Plansight, picks a winner, clicks "Push to BenefitPoint". The integration picks the BP plan type from BP's taxonomy, builds the product with origination reason new, sends rates and benefit summary, and stores the BP product ID on the Plansight quote.
The plan lives in BP. Plansight's scheduled pull-changes command keeps the broker's view in sync — if anyone updates the plan in BP (rate change, carrier change, contribution adjustment), Plansight reflects it within the next sync window.
120 days from renewal, Plansight surfaces the renewing plans. The broker shops the renewal in Plansight, comparing carriers and options. The integration knows the parent plan and pre-populates Plansight with the prior plan's structure.
When the renewal is ready, the broker pushes with origination reason renewal. The integration auto-matches to the existing BP plan, copies forward Broker of Record, Splits, Eligibility, and Contributions from the prior plan, and overwrites only what changed — rates, benefit attributes, dates.
If the broker switches carriers entirely, origination reason becomes replacement. The new plan gets pushed fresh, but with the parent's identity preserved so BP's reporting connects the old policy and the new one as a single ongoing relationship.
Mid-year amendments (rate changes, carrier corrections, eligibility tweaks) flow through the same push pipeline. The broker edits in Plansight, pushes, and BP's record updates. No re-keying.
Every quote in Plansight carries an originationReason: new, renewal, or replacement. The integration's behavior — what's copied from the prior plan vs. sent fresh, what's auto-matched vs. user-picked, what error patterns are tolerated — branches off this single field. Get the origination reason right and the rest of the integration follows.
Patterns that hold across every operation, every brokerage, every plan type.
One Plansight account binds to exactly one BP account, and vice versa. No fan-out, no fan-in. This constraint keeps multi-office brokerages modeling their structure deliberately, and simplifies every downstream operation by removing ambiguity about which BP record a Plansight quote belongs to.
BP's control splits setting must be enabled on the BP side for the integration to function. Without it, associations succeed silently but pushes do nothing — a known failure mode that's now part of the pre-onboarding checklist.
Sync from BP → Plansight runs on a schedule. Push from Plansight → BP is always user-triggered. The integration never silently writes to BP — every push corresponds to a deliberate broker action with a visible audit trail.
Plansight maintains a 150+ entry list of BP product type IDs the integration intentionally skips: annuities, executive benefits, individual lines, retirement products. The list is checked in code on every operation. New plan types are added deliberately, never by accident.
Every push error is captured on the quote it failed for, with a parsed JSON payload, a raw response, and resolved names for billing carrier, writing carrier, and product type. The broker doesn't need a log file to understand what went wrong.
BP session tokens cache for 55 minutes. When BP returns "session is not valid", the retry loop forgets the cache and re-logs in once, transparently. Brokers never see auth churn.
Plansight has the receiving side of a BenefitPoint single-sign-on flow scaffolded and routed. The endpoint is live in production. BenefitPoint hasn't enabled the emitter on their side yet — once they do, the controller fleshes out the click-through experience.
A pair of routes registered in routes/web.php:128-130 — both GET and POST on /benefitPointSSO. The controller (app/Http/Controllers/BPSSOController.php) is currently a placeholder that logs the inbound request payload via Log::debug and returns. Built by Trevor.
BenefitPoint hasn't shipped the SSO emitter yet. When they do (Vertafore handles the timing), Plansight will see real signed payloads at /benefitPointSSO and the controller body needs to: validate the signature, resolve the BP user to a Plansight user, mint a Plansight session, and redirect to the right deep link (account, quote, etc.) inside Plansight.
SSO from BenefitPoint into Plansight removes the second login. A broker working in BenefitPoint can click a Plansight link and land on the right account/quote without re-authenticating. It's also the most natural point of integration to surface Plansight inside the BenefitPoint UI itself once Vertafore exposes the deep-link API.
Owner: Trevor on the Plansight side. Status: Waiting on Vertafore. When they have a date, the controller body is a half-day of work.
Eight findings from a fresh pass through integrations/BenefitPoint/ in Plansight APP 9d1afd54d5df. None are existential — the integration works in production every day — but each is the kind of issue that produces "unreproducible" bug reports until someone goes looking. Each finding ends with a Cursor prompt the developer can paste straight into Cursor on the Plansight APP repo. Rank order is rough impact-weighted.
Problem. Vertafore exposes FindChanges (returns only records modified since a timestamp) and Plansight has it implemented at integrations/BenefitPoint/Operations/FindChanges.php — but the only caller is Commands/PullChanges.php, which isn't wired into the main sync flow in Controller.php or Service.php. Every product sync today is a full refresh.
Why it matters. Full refreshes are slow and burn API budget. For brokerages with hundreds of accounts, this is the difference between a sync that takes seconds and one that takes minutes (or trips a rate limit, see #4 below).
Wire FindChanges into Service::syncBrokerageProducts(): check for a last_sync_at timestamp on the brokerage; if present, call FindChanges and use only the returned product IDs to drive detail fetches. Fall back to full sync when no timestamp exists or FindChanges errors. Update last_sync_at after a successful run.
Problem. When FindOffices, GetAvailableCarriers, or FindUsers returns an empty collection (transient error, partial outage, auth slip), Service.php:2579-2590 still writes the empty result over the prior cache. The next UI request that depends on offices or carriers gets a silently empty list. Users see "no offices available" with no error surfaced.
Fix sketch. Reject empty replacements before persisting — keep the stale cached value and log a warning. An "empty after fetch" should be treated as "fetch failed" until proven otherwise.
In Service::putBrokerageUserCache(), before writing each of offices, users, availableCarriers, and billingCarriers to Storage::put, check if the new value is empty. If it is and a non-empty cached value exists, log a warning ("BP cache update rejected — empty {key} from API") and keep the prior value. Only overwrite when the new value is non-empty OR the prior value was also empty.
Problem. Api.php:464-467 caches login tokens using just brokerage->id. The getLoginToken() method has a commented-out brokerageId parameter implying support for one Plansight brokerage bridging multiple BP tenants — but the cache key doesn't include it. If we ever turn that on (or a single brokerage's BP auth changes), tokens will collide across tenants.
Update loginCacheKey() in Api.php to include the Vertafore tenant ID when getBpData('brokerageId') is set: "benefitPointLoginCredentials_{$brokerageId}_{$tenantId}". Audit existing callers to confirm the right tenant context is passed.
Problem. Session-timeout retries use literal sleep(2) and sleep(5) at Api.php:122-127, 314-320, 330-336, 394-403. No exponential backoff, no jitter — under any kind of load spike, all retries hit BP at the same moment and amplify the spike. HTTP 429 (rate limit) is not detected at all on the REST path; we silently accept the failure and may retry-loop into a ban.
In Api::handle(), replace the fixed sleeps with exponential backoff + jitter: sleep(min(60, (2 ** $attempt) + mt_rand(0, 1000)/1000)). Detect HTTP 429 in the REST response branch and trigger the same retry loop with the documented carrier backoff (or default 30s) when a Retry-After header is present.
Problem. Controller.php:459-475 and Service.php:1429-1446 chain methods on $response->data (.count(), .reject(), .first()) without checking $response->wasSuccessful() first. When auth retries silently produce a null payload, you get "Call to a member function count() on null" — usually filed as a one-off bug.
The REST path has the same shape (Api.php:297-323) — JSON unpacking assumes the structure is what we expect, no schema validation.
Audit every ->handle()->data chain in integrations/BenefitPoint/Controller.php and Service.php. Wrap each in a guard: if (!$response->wasSuccessful() || empty($response->data)) { /* surface error */ }. For REST operations, add a small helper that validates the expected JSON keys exist before accessing nested fields.
Problem. Service.php:883-950 (the getBenefitType() switch on productTypeID), plus the static maps in ContributionData.php and RateData.php, hard-code BP's enum values. There's no validation that an incoming BP value is in the map. If Vertafore adds a new product type or renumbers a rate type, the parser silently maps to null or a default, and the data quietly stops flowing without anyone noticing.
Plansight's FindBPCodes command already exists to compare BP's GetProductTypes + GetRateTypes output against our hard-coded maps. It's just not run on a schedule.
Add a validating enum mapper to Service.php: mapBpEnum($value, array $map, string $context): ?string that logs a warning ("Unmapped BP enum {context}: {value}") when a value isn't in the map, then returns null. Use it in getBenefitType() and the equivalent helpers in ContributionData.php / RateData.php. Schedule FindBPCodes to run weekly and alert if maps have drifted.
Problem. Service.php:1529-1597 (mapPlansightToBpRate) copies tier values between Plansight and BP rate shapes. Two issues: it mutates $destItem['valueNum'] from source values without validating type, range, or BP field constraints (so an out-of-range value silently propagates and BP rejects the eventual write); and when tier counts diverge between Plansight and BP (3-tier dental on our side, 5-tier on theirs), the fallback path quietly drops un-mapped tiers without logging.
In Service::mapPlansightToBpRate(): (a) validate copied valueNum values are numeric and within constraints from GetRateStructure before assignment, log + skip on mismatch; (b) when source and dest tier counts differ, log every dropped tier with source/dest IDs and surface a single user-facing warning per quote that data was incomplete.
Problem. Today, when a user pushes a renewal or replacement, both Structs/Product.php:182-194 (SOAP path) and Structs/ProductModel.php:223-235 (REST path) hardcode productTypeID to the parent plan's type — so a Medical PPO can only ever renew as a Medical PPO. The user-selected plan type from the UI is silently ignored on renewals (it's only honored when originationReason === 'new').
Why this is a Plansight choice, not a BP rule. The BP Product complex type (common-v3.2.xsd line 2830) defines productTypeID, parentProductID, and policyOriginationReason as three independent fields with no cross-validation. Confirmed against the live BP API: renewals with a different productTypeID than the parent are accepted (e.g. PPO renewing as HMO).
Why it matters. Brokers do change plan structures at renewal — moving a client from PPO to HMO, splitting bundled plans, swapping carriers and product types together. Today they have to push as a "new" plan and then manually re-link the parent in BP, losing renewal-aware behavior (rate carryover, commission continuity, parent metadata). Allowing the type change at renewal restores the complete renewal flow.
In both integrations/BenefitPoint/Structs/Product.php (lines 180–204) and Structs/ProductModel.php (lines 221–245), update the renewal/replacement branch to prefer selectedProductTypeId over parentProductTypeId when the user explicitly picked a different one — falling back to parentProductTypeId when not. In Scripts/BP.js, render the existing plan-type <select> on renewal/replacement rows too (currently shown only for "new"), pre-selected to the parent's type, persisting via the existing saveSelectMenuValues endpoint; show inline notice "Plan type will change from {parent} to {selected} on push" when the selection differs from the parent. Add a bpDebug log line in Jobs/PushProduct.php when the constructed productTypeID differs from the parent's. Full spec, tests, and rollback plan: cursor-prompts/bp-renewal-allow-plan-type-change.md.
Five threads worth a 30-minute conversation with whoever owns BP integration. None are fixable in a single PR — they're decisions, not bugs.
FindChanges (Gap #1) is wired in, what's the intended frequency — hourly cron, on broker action, both? Should delta and full-refresh coexist with a periodic reconciliation run?FindBPCodes run that diffs against our hard-coded maps and pages someone if Vertafore added a new product or rate type we haven't mapped (Gap #6).The gap analysis above came from reading code. This section came from driving the live BrokerConnect API against a real brokerage in August 2026 — every claim below was reproduced against BenefitPoint itself, not inferred. Several of them contradict things Plansight believed for a long time.
The fact. The .env points at BrokerConnectV4.4.wsdl, whose types come from common-v3.4.xsd. Plansight's internal recipe documented v4.2, whose schema is missing fields that 4.4 has.
Why it matters. Reading the wrong schema hides real capability. BenefitSummary.isHdhp — finding #2 below — exists in 3.4 and does not exist in 3.2, which is the single reason it went unfound for years. Read the 3.4 schema, not the 3.2 one.
isHdhp — it was never attribute 873The fact. It is a first-class boolean on BenefitSummary, declared in Vertafore's published common-v3.4.xsd and validated against their own IRS HDHP Values table. It is not a brokerage custom field, and it is not attribute 873. Before this pass, isHdhp appeared exactly once in the entire Plansight codebase: in a comment.
BenefitPoint gates it on three things, all confirmed by experiment. All three must hold or the flag is refused:
| Gate | How it fails |
|---|---|
| Effective year is the current or previous year | 2027 and 2028 are refused. 2026 and 2025 pass. |
Attribute 873 says HSA | Anything else is refused. |
| Deductible and out-of-pocket, individual and family — all four, as numbers | Every subset was refused live. All four together were accepted. |
The consequence brokers will feel. A renewal is effective next year by definition, so the HDHP box will not tick on a renewal quoted the year before — which is most renewals. That is BenefitPoint's rule and not something Plansight can code around. If brokers expect it to tick, that is a conversation with Vertafore about their IRS HDHP Values window.
Problem. BenefitPoint does not ignore a flag it disagrees with — it rejects the whole write. And because Base extends Model with $guarded = [] and fromSoap() copies every returned key, isHdhp has been round-tripping on the copy path all along. On production today, renewing an already-flagged HDHP plan into next year can fail the benefit-summary push, with nothing in the message pointing at the HDHP flag as the cause.
Fix. Plansight cannot predict BenefitPoint's answer without reproducing its IRS tables, so the flag now yields: on a refusal that names it, the operation drops the flag and re-sends the summary once. The push succeeds and the result explains what BenefitPoint would not do. All four write paths degrade this way, and the degrade is deliberately narrow — unrelated errors are not swallowed. Built on the PS-9170 branch, not yet merged.
Problem. getAttributeValueDetail() converts currency attributes to UOM=dollars, but its pattern had no room for a comma. $500 went to BenefitPoint as the number 500; $5,000 fell through and went as text. The behaviour changes silently at a thousand — and Plansight formats these values for people, so real deductibles nearly all landed on the text side. BenefitPoint cannot compare text to its IRS table, which is what was actually blocking the HDHP flag.
Scope. Fixed for the four IRS attributes (44 / 45 / 52 / 53). The same comma blindness affects every other currency attribute — a $500 copay sends a number and a $1,500 copay sends text — so removing the attribute-ID gate is the obvious follow-up. Built on the PS-9170 branch, not yet merged.
Problem. BenefitPoint returns HMO summaries containing attribute 138 ("Deductible") with a null value, then refuses the same summary when it is sent back: Element value for attributeID = 138 must not be null. Attribute 138 sits at view level 110 (Core) on Medical HMO but 120 (Expanded) on Medical PPO, and Plansight never populates it. Plansight's summaries use view level 110, so it is required on HMO and not on PPO.
Reproduced on every fixture. Every rejection was an HMO; every PPO and Dental summary was accepted. This hits CreateBenefitSummaryFromCopy — the real renewal path — not just updates. All three broken summaries had been created by Plansight pushes in the first place.
Fix, proven. Drop attribute details BenefitPoint returned with no value before sending the clone; the same clone was then accepted. Built on the PS-9170 branch, not yet merged. Actually mapping attribute 138 would make the data right, rather than merely legal — that is a separate piece of work.
Problem. Both Plansight funding values push as LEVEL_FUNDED, and BenefitPoint's answer is ambiguous coming back — the import resolved it to "Express" every time. Delta sync therefore changed the funding type on plans nobody had edited. NONE_SELECTED likewise came back asserting Fully Insured.
Fix. Plansight's stored value wins when BenefitPoint's answer is ambiguous. Built on the PS-9170 branch, not yet merged.
Worth knowing: funding type is mapped on the REST path, which is the default. The SOAP path writes it as a BenefitPoint custom field (customFieldID 123814) that the code's own comment says Vertafore no longer supports — which only affects brokerages configured with useUserDefinedWsdlURLs.
Problem. Medical Fully Insured (rate type 1), Dental (3), Vision (4) and Stop Loss (39) map a plan's 3/4/5-tier structure to BenefitPoint's rateTypeTierID. Everything else silently falls back to 5-tier, regardless of how the plan is actually rated.
Why it matters. The rate lands, so nothing errors — the tiers are just wrong on the BenefitPoint side for most ancillary lines. A card covering the full mapping is drafted and not yet filed.
Problem. The push succeeds, BenefitPoint has the product, and the modal says nothing. The broker only learns it worked by reloading the page. Pre-existing, unrelated to any mapping work.
Why it matters. This is probably a bigger driver of "the BenefitPoint connection doesn't work" than any mapping bug on this page — it trains brokers to believe pushes fail. Needs its own card.
Operational facts established by calling the API, each of which has cost real debugging time at least once.
| Fact | Detail |
|---|---|
| BenefitPoint "test" is not a separate server | The test credentials point at benefitpoint.vertafore.com — the live host. Isolation is the brokerage account, not the environment. 14119 is the Plansight production book; 1002 is the shared sandbox. |
| Each brokerage has its own API password | Same username, different password per broker domain. A wrong one returns ns1:SYSTEM_ERROR, not "invalid login" — it looks like a Vertafore outage and is not. |
SOAP getProductTypes() returns 220 of 426 types |
It silently omits types the registry uses (5510, 5823, 5859, 5873) and reports Voluntary Life 260 as having no rate types when REST reports rate type 34. Only GET /products/types?returnAllTypes=true is complete. Do not rebuild rate-type data from the SOAP call. |
findBenefitSummaries is not denied |
The long-standing "not authorized" belief came from malformed calls. It needs criteria = {accountID, productID} with accountID required; with that it returns summaries normally. getBenefitSummary by id, getBenefitSummaryStructure and getCurrentUser all work too. |
findUsers is genuinely denied |
Denied for the Plansight API user on both brokerages. Use getCurrentUser to resolve the numeric BenefitPoint user id when findUsers returns zero. |
officeFilter takes office IDs, not names |
A name silently matches nothing and the employer search comes back empty rather than erroring. |
| Lead users must be on the account team | Setting a primarySalesLeadUserID that is not on the team returns userID ... does not belong to the account team members. |
| There is no delete for accounts or products | The API exposes only DeleteBenefitSummaryRest. Test fixtures created on a real account cannot be removed — plan accordingly before creating them. |
| Attachments are read-only | Only findAttachments and getAttachment exist. There is no attachment write of any kind. |
planInfo.stateList serializes to the literal string "Array" |
BenefitPoint rejects it with a generic Application_Error. Replace planInfo wholesale when cloning a product rather than mutating it. |
| The brokerage cache is a stored file | storage/app/benefitPoint/brokerageCache_<id>. Changing the brokerage ID does not invalidate it, and the UI's flush button only queues an Artisan job — which does nothing without a queue worker running. |
All findings reproduced 20–22 Aug 2026 against BrokerConnect V4.4, brokerages 14119 and 1002. Fixtures created during testing were restored or removed. Items marked "not yet merged" are built and verified on the PS-9170 branch but are not in production.
Developer reference for the attribute IDs the BenefitPoint API uses across plans and benefit summaries. Each row pairs a BP attribute ID with its human label and the Plansight field it maps to. Source: the same data that drives the interactive Sync Map — re-extracted as a flat ctrl-F-friendly table.
124 attribute mappings across 8 benefit types. Each row pairs a BenefitPoint attribute ID with its human label and the Plansight field it maps to. Use browser find (Cmd-F / Ctrl-F) to locate by ID, name, or Plansight column.
| BP ID | BenefitPoint name | Plansight field | Sync |
|---|---|---|---|
| Medical (46 attributes) | |||
| General Plan Information | |||
| 45 | Annual Deductible/Individual | DeductibleIndividual | Synced |
| 44 | Annual Deductible/Family | DeductibleFamily | Synced |
| 973 | Deductible Embedded or Aggregate | DeductibleType | Synced |
| 112 | Coinsurance — Push uses BP ID 295. | HospitalFacility | Synced |
| 386 | Office Visit/Exam | PrimaryCareDoctor | Synced |
| 414 | Outpatient Specialist Visit | Specialist | Synced |
| 902 | Telemedicine | Telehealth | Synced |
| 53 | Annual Out-of-Pocket Limit/Individual | OOPIndividual | Synced |
| 52 | Annual Out-of-Pocket Limit/Family | OOPFamily | Synced |
| 873 | High Deductible Health Plan (HSA-eligible) | hsa | Synced |
| Preventive Services | |||
| 974 | Preventive Care — BP section ID 455. | PreventativeServices | Synced |
| 975 | Preventive Screenings — Push uses 974. | PreventativeServices | Synced |
| 571 | Well-Child Care — Push uses 974. | PreventativeServices | Synced |
| 254 | Immunizations — Push uses 974. | PreventativeServices | Synced |
| 570 | Well Woman Exams — Push uses 974. | PreventativeServices | Synced |
| 339 | Mammograms — Push uses 974. | PreventativeServices | Synced |
| 16 | Adult Periodic Exams with Preventive Tests — Push uses 974. | PreventativeServices | Synced |
| 168 | Diagnostic X-Ray and Lab Tests | Diagnostic | Synced |
| 971 | Complex Radiology | Imaging | Synced |
| Maternity Care | |||
| 450 | Pregnancy and Maternity Care (Pre-Natal) | MaternityOffice | Synced |
| Inpatient Hospital Services | |||
| 295 | Inpatient Hospitalization | HospitalFacility | Synced |
| 439 | Pre-Authorization of Services Required | — | N/A |
| 503 | Semi-Private Room & Board (incl. services) — Push uses 295. | HospitalFacility | Synced |
| Surgical Services | |||
| 408 | Outpatient Facility Charge | OutpatientFacility | Synced |
| Emergency Services | |||
| 184 | Emergency Room | EmergencyRoomCopay | Synced |
| Urgent Care | |||
| 555 | Urgent Care Facility | UrgentCare | Synced |
| Mental Health | |||
| 287 | Inpatient Care | InpatientMental | Synced |
| 407 | Outpatient Care | OutpatientMental | Synced |
| Alcohol Abuse | |||
| 294 | Inpatient Hospitalization — Push uses 670. | InpatientSubstance | Synced |
| 292 | Inpatient Detoxification Services — Push uses 670. | InpatientSubstance | Synced |
| 412 | Outpatient Services — Push uses 673. | OutpatientSubstance | Synced |
| 675 | Outpatient Detoxification Services — Push uses 673. | OutpatientSubstance | Synced |
| Substance Abuse | |||
| 670 | Inpatient Hospitalization | InpatientSubstance | Synced |
| 671 | Inpatient Detoxification Services — Push uses 670. | InpatientSubstance | Synced |
| 673 | Outpatient Services | OutpatientSubstance | Synced |
| 674 | Outpatient Detoxification Services — Push uses 673. | OutpatientSubstance | Synced |
| Other Services and Supplies | |||
| 174 | Durable Medical Equipment & Prosthetic Devices | MedicalEquipment | Synced |
| 250 | Home Health Care | HomeCare | Synced |
| 508 | Skilled Nursing or Extended Care Facility | Nursing | Synced |
| 251 | Hospice Care | Hospice | Synced |
| Outpatient Rehabilitative Therapy | |||
| 424 | Physical | Rehabilitation | Synced |
| 385 | Occupational — Push uses 424. | Rehabilitation | Synced |
| 515 | Speech — Push uses 424. | Rehabilitation | Synced |
| Habilitative Services | |||
| 877 | Physical | Habilitation | Synced |
| 878 | Occupational — Push uses 877. | Habilitation | Synced |
| 879 | Speech — Push uses 877. | Habilitation | Synced |
| Dental (17 attributes) | |||
| General Plan Information | |||
| 44 | Annual Deductible/Individual | DeductibleIndividual | Synced |
| 45 | Annual Deductible/Family | DeductibleFamily | Synced |
| 55 | Annual Plan Maximum | AnnualMaxIndividual | Synced |
| 314 | Lifetime Orthodontia Plan Maximum | LifetimeOrthoMax | Synced |
| Diagnostic and Preventive Services | |||
| 390 | Oral Exams | Exams | Synced |
| 74 | Bitewing X-Rays | XRays | Synced |
| 109 | Cleaning and Scaling | Cleanings | Synced |
| Basic Services | |||
| 64 | Basic Filling | BasicFilling | Synced |
| 391 | Oral Surgery: Extractions and Other | OralSurgery | Synced |
| 190 | Endodontic Treatment | Endodontics | Synced |
| 419 | Periodontic Treatment | Periodontics | Synced |
| Major Services | |||
| 137 | Crowns, Jackets and Cast Restoration Benefits | Crowns | Synced |
| 255 | Implants | Implants | Synced |
| Orthodontia Services | |||
| 392 | Orthodontia | Orthodontics | Synced |
| 152 | Dependent Children | OrthodonticsAge | Synced |
| 17 | Adults (and Covered Full-Time Students) | OrthodonticsAdult | Synced |
| 314 | Adult Lifetime Maximum | LifetimeOrthoMax | Synced |
| Vision (13 attributes) | |||
| General Plan Information | |||
| 195 | Examination | EyeExams | Synced |
| Benefit Frequency | |||
| 194 | Examination | ExamFrequency | Synced |
| 309 | Lenses | LensesFrequency | Synced |
| 207 | Frames | FramesFrequency | Synced |
| 122 | Contacts | ContactsFrequency | Synced |
| Lenses | |||
| 507 | Single Vision Lens | SingleVisionLenses | Synced |
| 73 | Bifocal Lens | BifocalLenses | Synced |
| 553 | Trifocal Lens | TrifocalLenses | Synced |
| 66 | Basic Progressive | BasicProgressiveLenses | Synced |
| Contact Lenses | |||
| 356 | Medically Necessary | ContactsNecessary | Synced |
| 178 | Elective | ContactsElective | Synced |
| Frames | |||
| 208 | Frame Allowance | FrameAllowance | Synced |
| Other Services | |||
| 133 | Corrective Vision Services (e.g. Laser Surgery) | LasikDiscount | Synced |
| Basic Life (14 attributes) | |||
| Guarantee Issue Amount | |||
| 187 | Employee | — | On Roadmap |
| Overall Maximum | |||
| 188 | Employee | maximumBenefit-1 | On Roadmap |
| Features | |||
| 7 | Accelerated Benefit (Life Only) | acceleratedDeathBenefit | Synced |
| 567 | Waiver of Premium (Life Only) | premiumWaiver | Synced |
| 122 | Conversion (Life Only) | conversion | Synced |
| 433 | Portability | portability | Synced |
| AD&D Schedule | |||
| 497 | Seatbelt Benefit | — | Synced |
| 28 | Airbag Benefit | airBag | Synced |
| 590 | Repatriation of Remains | repatriation | Synced |
| 100 | Child Care Benefit | childCare | Synced |
| Reduction of Benefits Schedule | |||
| 2 | Tier 1 (Age 64 or Younger) | — | Synced |
| 3 | Tier 2 (65-69) | — | Synced |
| 4 | Tier 3 (70-74) | — | Synced |
| 5 | Tier 4 (75-79) | — | Synced |
| STD (10 attributes) | |||
| Elimination Period | |||
| 252 | Accident | waiting_period_accident | Synced |
| 505 | Sickness | waiting_period_illness | Synced |
| 8 | Hospitalization | First Day Hospital | Synced |
| General Plan Information | |||
| 71 | Benefit Percentage | — | Synced |
| 569 | Weekly Benefit Maximum | — | Synced |
| 350 | Maximum Period of Payment | — | Synced |
| 373 | Minimum Weekly Benefit | — | Synced |
| 142 | Definition of Earnings | — | Synced |
| 449 | Pre-Existing Condition Limitations | — | Synced |
| 433 | Portability | — | Not Synced |
| LTD (16 attributes) | |||
| General Plan Information | |||
| 71 | Benefit Percentage | ltDisabilityBenefitSchedule-1 | Synced |
| 582 | Guaranteed Issue | ltDisabilityGuaranteeIssue | Synced |
| 371 | Monthly Benefit Maximum | ltDisabilityMaximumMonthlyBenefit-1 | Synced |
| 351 | Maximum Period of Payment | ltDisabilityBenefitDuration | Synced |
| 374 | Minimum Monthly Benefit | — | Synced |
| 181 | Elimination Period | ltDisabilityEliminationPeriod | Synced |
| 466 | Recurrent Disabilities | ltDisabilityRecurrentProtection | Synced |
| 142 | Definition of Earnings | ltDisabilityEarningsDefinition | Synced |
| 801 | Earnings Test | ltDisabilityEarningsTest | Synced |
| Limitations | |||
| 365 | Mental Illness | ltDisabilityMentalNervous | Synced |
| 526 | Substance Abuse | ltDisabilityAlcoholDrug | Synced |
| 501 | Self-Reported | — | Synced |
| 449 | Pre-Existing Condition Limitations | ltDisabilityPreExistingLimitations | Synced |
| Features | |||
| 539 | Survivor Benefit | ltDisabilitySurvivorBenefit | Synced |
| 485 | 100% Return to Work Incentive | — | Synced |
| 113 | COLA | ltDisabilityCOLA | Synced |
| EAP (4 attributes) | |||
| Plan Design | |||
| 384 | Number of Visits / In-person sessions per Issue | eapInPersonSessionsIssue | Not Synced |
| 553 | Chemical Dependency / Drug & Alcohol Counselors | — | Not Synced |
| 202 | Legal Resource and Referral / Financial Counseling | — | Not Synced |
| 557 | Utilization Reporting | eapUtilizationReports | Not Synced |
| HRA (4 attributes) | |||
| Communication and Enrollment | |||
| 192 | Enrollment Meetings | — | Synced |
| 191 | Enrollment Kits / Startup Kits | — | Synced |
| Compliance | |||
| 170 | Discrimination Testing | — | Synced |
| 430 | Plan Documents | — | Synced |
Active work and open ideas. Tracked in JIRA project PS.
The feature described in Changing a plan's product type on renewal is built and verified against live BenefitPoint pushes — a replacement and a rate-carrying renewal both created as a different type with the parent chain intact. It is committed on a branch and has not yet been merged to production.
Riding along with it, each verified live and each described in the field notes above: the HDHP flag no longer fails the whole benefit-summary push, IRS currency values above $999 now send as numbers, Medical HMO summaries can be copied again, and the import stops rewriting Level Funded to Level Funded Express.
Follow-on work identified, not yet filed: remove the attribute-ID gate on the currency fix so every currency attribute stops flipping to text at a thousand; map attribute 138 rather than only stripping it; map tier counts for the other 46 rate types; and card the silent-success-on-push behaviour, which is likely the single biggest source of "the BenefitPoint connection doesn't work" reports.
Reconciled against the JIRA board on 24 Aug 2026. Status is BenefitPoint work only.
Eight reported BenefitPoint items sit at Un Reviewed — none assigned to a sprint, several unassigned entirely, and the oldest untouched since March.
ageBandGender enum casingFour of these eight are rate-push problems. That clustering is worth reading alongside finding #7 — most ancillary lines fall back to 5-tier regardless of how the plan is rated.
Longer-standing ideas still open: migrate the remaining SOAP operations to REST, and re-extract the attribute code dictionary from the current BenefitPoint API.