General Agents

How retail brokers and GAs share work in Plansight

The relationship in one paragraph

A General Agent is a co-broker of record with the Retail Broker — equally entitled to plan documents, census data, loss runs, and renewal information from the carrier. They are not waiting on the Retail Broker to do their work. When both are Plansight customers, sharing makes the experience seamless; when only one side is, Plansight still has well-defined patterns to keep the GA and Retail Broker working together as a unit.

When connected: the GA can run their own carrier RFP independently and push the resulting quotes back into the Retail Broker's presentation — even for benefit types the Retail Broker did not include in their own RFP. (A target presentation must already exist on the Retail Broker's side — see Known Obstacles below.)

A

Both GA and Retail Broker are Plansight customers

Onboarding: collect the GA's retail broker list, cross-check against Plansight customers, and provision sharing immediately.

  • Shared employer groups appear in the GA's instance automatically
  • GA can run their own RFP independently (incognito from the Retail Broker)
  • GA pushes results when ready (target presentation required — see obstacles)
  • Retail Broker's logo auto-pulls into GA-built presentations (already works)
The seamless path — the highest-value scenario for both sides.
B

GA is a Plansight customer, Retail Broker is not

Use Offices inside the GA's instance to manage each Retail Broker's brand — logo, colors, presentation template.

  • One Office per Retail Broker; associate each shared employer with that Office
  • Multi-office GAs (e.g. a 30-location enterprise) use Regions above Offices
  • Deliverables: branded PDF (logos + colors auto-applied) or Excel export (no logos; broker copy/pastes into their own deck)
The growth path — selling the GA reinforces the pitch to bring their Retail Brokers onto Plansight too.
C

Retail Broker is a Plansight customer, GA is not

Best answer: sell the GA a single-user license. It is inexpensive and unlocks the full Scenario A experience.

  • Stopgap: add the GA as a user inside the Retail Broker's instance with a unique email
  • If the GA works across multiple Retail Brokers, they will need a unique email per brokerage — intentionally friction-heavy to push them toward a license
  • Assign them only the employer groups they have access to
The conversion path — lead with the license offer; make the stopgap intentionally clunky.

The three steps

Connecting a Retail Broker and a General Agent in Plansight is a three-step flow: Plansight links the two brokerages in admin, the Retail Broker shares the employer group, and then the General Agent can build presentations with the Retail Broker's logo automatically applied. Each step is shown below.

1 Connect

Plansight links the Retail Broker and the GA

In admin, we provision the GA as a connected agent on the Retail Broker's instance. One-time setup per brokerage relationship.

Plansight Admin
links the two brokerages
Retail Broker
Plansight customer
linked
General Agent
Plansight customer
2 Share

Retail Broker shares an Employer Group with the GA

The Retail Broker picks which employer groups to share. Each shared group appears in the GA's instance as a synced copy — plan documents, RFP history, and assets included.

Retail Broker
owns the client record
shares employer group
Employer Group
plans · RFPs · documents
appears in GA instance
General Agent
synced copy — read access
3 Brand

GA builds a presentation — Retail Broker's logo auto-pulls

When the GA generates a presentation for a shared employer, Plansight automatically swaps in the Retail Broker's logo (not the GA's). Already live — no engineering needed.

General Agent builds presentation
inside their own instance
RB Logo
RETAIL BROKER LOGO
Branded for the Retail Broker's client
Where to manage the link: Plansight Admin → Brokerage → Connected Agents. Adding the GA here is the prerequisite for any sharing.
Granularity of sharing: Either all employer groups, or a hand-picked list — chosen on the Retail Broker's side, not the GA's.
Logo logic, code-confirmed: Brokerage::sharedBrokerageLogos() swaps the GA's logo for the source broker's whenever ga = 1 and a sharedBrokerageId is set. Office logo overrides still win.
1
How the connection is created: The retail broker requests Plansight to link them with a specific GA. Plansight sets up the connection internally (the GA brokerage must have General Agency mode enabled). Once linked, the retail broker can choose which clients to share with that GA.
Employer (Client)
your master record, with documents & current plans
SHARED
→
GA gets a synced copy when you share the client
Employer (synced copy)
read-only view of your client
The RFP
yours — for each benefit type, you pick a strategy (see below)
VISIBLE
→
GA can view, but cannot edit your RFP or plans
Shared RFP
read-only for the GA
Inside the RFP, for each benefit type the retail broker picks one mode (controls YOUR distribution only)
Current Benefitsno shopping by you
Marketingyou send your own RFP out to carriers
General Agentyou don't distribute; the GA covers it
You pick one or the other in the builder — Marketing and General Agent are mutually exclusive per benefit type on your side. But the mode you pick doesn’t gate your GA. Even if you choose Marketing (and never select GA), your GA can still push plans into the same RFP/presentation. The mode flag describes who you plan to use; it never blocks who’s allowed to contribute. (We use “RFP” and “presentation” interchangeably — you can’t really have one without the other.)
Presentation
your client-facing deliverable
CO-EDIT
↔
GA can edit & print on your behalf
Shared Presentation
GA can update & print
Carrier Quotes
land in your presentation — even for benefit types not in your RFP
PUSH BACK
←
GA runs their own RFP & pushes the quotes back into your presentation
GA's own RFP
GA sources quotes independently, then pushes them to you
The bottom line: You own the client, the plans, the RFP, and the presentation. Your GA can view your work, edit and print your presentation, and — the killer move — run their own carrier RFP on the side and push the resulting quotes straight into your presentation. New benefit types from the GA show up in your client's presentation automatically.
1
Setup: A retail broker requests Plansight to link a specific GA. Plansight admin adds the GA's brokerage ID to the retail broker's gaBrokerList. The GA brokerage must have ga = 1 set. One retail broker can be linked to multiple GAs.
Employer (Group)
master record
TWIN
→
28 fields auto-sync from retail's record via sharedGroupId
Employer (Group, twin)
sharedGroupId → retail's Group
sharedBrokerageId → retail brokerage
RFP
single record, owned by retail
sharedBrokerageIds: [GA.id]
each benefit-type entry carries a mode flag
PERMIT (read-only)
→
sharedBrokerageIds grants read; write blocked by policy
no separate record — read via permission
Per-benefit-type strategy inside the RFP (controls retail's distribution path)
Current Benefitsno shopping by retail
Marketingretail distributes RFP to carriers
General Agentretail doesn't distribute; routed to GA
Builder UI enforces XOR on the retail's selection — Marketing and General Agent cannot both be checked for one benefit type. But this flag does NOT gate the GA's push. shareToBroker() at RfpController.php:3828 auto-flips planType{X}Ga = 1 on push regardless of what retail picked, so the GA can push plans for any benefit type into retail's RFP/presentation in parallel — including when mode = Marketing. The mode flag describes retail's distribution intent; it does not enforce permission. (Note: shareToBroker() also zeros out retail's Marketing flag on push at line 3832, by design — the system collapses to GA-mode after a push.) Throughout: “RFP” and “presentation” are used interchangeably.
Presentation (Proposal)
composite key [rfpId, id]
owned by retail
PERMIT (read + write)
↔
policy allows GA to edit & print the shared Proposal
no separate record — editable via permission
Quote (cloned in)
gaQuoteId, gaRfpId,
gaBrokerageId, gaGroupId
attached to retail's presentation
COPY ←
←
shareToBroker() clones quotes from GA's RFP into retail's account; sync IDs cleared
GA's own RFP & Quotes
separate RFP in GA's account
not visible to retail directly

Sharing patterns

TWIN
A second record is created on the GA's side, linked back to the retail master by sharedGroupId. ~28 fields auto-sync retail→GA on change.
PERMIT
One record only, owned by retail. sharedBrokerageIds grants read access to the GA. Write access depends on the object's policy.
CO-EDIT
Same permission grant as PERMIT, but the policy explicitly allows the GA to edit and print — used for Proposals.
COPY (upstream)
The only flow back to retail. shareToBroker() clones the GA's quotes into retail's account with ga* back-pointer fields; sync IDs cleared. Quotes can land in retail's presentation even if its RFP doesn't include that benefit type.
What the GA cannot do: edit the retail broker's RFP, edit the retail broker's current plans, or otherwise mutate the retail master records (other than via the quote-push). The permission split is enforced at the policy layer, not at the data layer.
Don't confuse: syncQuoteBenefitHistoryId is a separate, intra-account mechanism — it links a new Quote to a source BenefitHistory within the same broker's account when re-shopping a renewal. It is NOT the GA→retail mechanism. The GA-side clone path explicitly clears these sync IDs.

Known obstacles

Items we know are friction today — documented so the team can name them when customers hit them, with the current workaround.

Push with no target presentation

When a GA finishes their RFP and is ready to push quotes back to the Retail Broker, today there must already be a presentation on the Retail Broker's side to receive them. If the Retail Broker has not started one yet, the push has nowhere to land.

Workaround: the GA calls the Retail Broker and asks them to spin up a placeholder presentation so the push can complete. Engineering follow-up tracked — the goal is to let the push auto-create the target.

GA-to-Retail-Broker migration (employer history push-down)

If a GA has been managing employer groups in their own instance for years and one of their Retail Broker partners later buys a Plansight license, there is currently no way to push that employer history down to the newly-licensed Retail Broker. The Retail Broker has to start fresh.

Workaround: Retail Broker rebuilds the employer record from scratch on their side, then shares it back to the GA. Engineering research in progress — this is the most urgent gap to solve.

GA cannot edit the Retail Broker's current plans

A shared employer's current plans are read-only on the GA side. Since GAs are co-brokers of record, they should be able to update current plans — today they have to request edits through the Retail Broker.

Workaround: the GA asks the Retail Broker to make the edits. Future work item — scope opening up current-plans editing on the GA side while leaving shared RFPs read-only.

Plan attribute settings do not inherit from the Retail Broker

When the GA starts an RFP on a shared employer, the RFP uses the GA's default attribute settings — not the Retail Broker's. That means attribute visibility, ordering, custom labels, and view level all diverge from what the Retail Broker would have produced.

Workaround: the GA manually matches the Retail Broker's settings. Engineering card in progress to make this an automatic starting-state inheritance.

Sharing clients is one-by-one

When a Retail Broker onboards a GA, they have to share each employer group individually. For a Retail Broker with hundreds of groups, this is tedious busywork that delays the GA from getting productive.

Workaround: work through the list manually. Future work item — bulk-share-all-clients action with filters.

Download setup-flow PDF Download customer-view PDF Download internal-team PDF
Inside Plansight