/insurance-brokerage-agency-billing-configure

name: insurance-brokerage-agency-billing-configure
description: "Configure end-to-end Agency Billing on a Salesforce FSC Insurance Brokerage org via dispatch MCP calls. Use this skill when users want to set up brokerage billing, configure agency billing, enable insurance billing features, create billing rules, set up accounting periods, assign billing permission sets, or create a demo policy for the Issue-to-Invoice flow. TRIGGER when: user mentions agency billing setup, brokerage billing configuration, insurance billing enablement, billing treatments, billing rules creation, accounting period setup, insurance policy billing information, or Issue-to-Invoice testing. Also use when users say things like set up my brokerage org for billing, configure billing on my insurance org, enable billing features, create billing treatments, set up GL accounts, or assign billing permissions. DO NOT TRIGGER when: user needs general Revenue Cloud Billing without insurance context, needs CPQ/quoting configuration, or needs claims processing setup."
metadata:
  version: "2.0"
  minApiVersion: "66.0"
  accessCheck:
  - type: "license"
    value: "InsuranceBrokerageFoundationPsl"

Insurance Brokerage Agency Billing Configuration

Automates the full Agency Billing setup on a Salesforce FSC Insurance Brokerage org. Runs 7 sequential phases using `dispatch` MCP calls to verify licenses, enable features, **assign permissions early**, configure billing settings, create billing rules, set org defaults, set up accounting, and create a demo policy for Issue-to-Invoice testing. **Phase order is critical**: permissions must be assigned before billing settings configuration.

Scope

• **In scope**: License verification, feature enablement (Context Service, Brokerage, Billing, Salesforce Pricing), billing settings configuration, billing rules creation (Legal Entity, Billing Treatments, Tax Engine, Payment Terms, Product Selling Models, Proration Policy), accounting setup (periods, GL accounts, GLAAR rules), permission set assignment, FLS creation via metadata endpoint, and demo policy creation.
• **Out of scope**: Revenue Cloud CPQ/quoting, claims processing, policy administration workflows, custom Apex development, LWC UI components. Data Pipelines (Sonic) requires an org-level `SonicLicensedOrg` feature not present on standard brokerage orgs — enable it manually if needed.
• **All phases fully automated** via `dispatch` (headless routes + Metadata CRUD + Tooling API). No manual steps, no SF CLI, no gaps.

---

CRITICAL — Standard Field Names (no __c anywhere)

Every field in this workflow is STANDARD. Never append `__c` to any field name. Here are the correct API names:

| Object | Field (correct) | WRONG (never use) | |--------|----------------|-------------------| | BillingTreatment | Status | ~~Status__c~~ | | TaxEngine | TaxEngineName | ~~TaxEngineName__c~~ | | PaymentTerm | DaysDue | ~~DaysDue__c~~ | | PaymentTerm / PaymentTermItem | PeriodUnit | ~~PeriodUnit__c~~ | | PaymentTerm | Active | ~~Active__c~~ | | LegalEntity | Active | ~~Active__c~~ | | BillingTreatmentItem | ChargeType | ~~ChargeType__c~~ | | BillingTreatmentItem | BillingType | ~~BillingType__c~~ | | BillingTreatmentItem | Active | ~~Active__c~~ | | ProductSellingModel | Active | ~~Active__c~~ |

---

Required Inputs

Do not ask the user for any information — proceed autonomously using defaults and the pre-configured environment.

• **Authenticated org**: The default target org is pre-configured in the MCP environment. Verify connectivity by calling `dispatch GET /chatter/users/me`.
• **Target user ID**: Capture the `id` field from the `/chatter/users/me` response and use it as AssigneeId for all license and permission assignments throughout all phases.

Defaults (always apply unless the user explicitly overrides in their initial prompt):

• All 7 phases execute in sequence
• Demo policy uses configuration from `references/demo-policy-config.md`
• Billing rules use configuration from `references/billing-rules-config.md`
• Permission sets from `references/permissions-config.md`

---

Workflow

All phases are sequential. Do not skip or reorder. **Critical cross-dependencies:**

• Phase 2 (Permissions) MUST run before Phase 3 (Billing Settings) — many billing settings require billing admin permissions
• Phase 2 (Permissions) MUST run before Phase 4 (Billing Rules) — BillingTreatment object access requires permissions
• Phase 2 (Permissions) MUST run before Phase 7 (Demo Policy) — InsPolicyBillingInfo fields require permissions + propagation time

Follow the execution order below exactly.

Phase 1 — Prerequisites

1. **Verify org connectivity and capture target user ID** — call `dispatch GET /chatter/users/me` and confirm a 200 response. **Capture the `id` field from the response and store it as `TARGET_USER_ID` — this SAME ID must be used throughout ALL phases for license assignments, permission set assignments, and any user-specific operations.** If Chatter is disabled, fall back to querying the User object: `dispatch GET /query?q=SELECT+Id,Username,Name+FROM+User+WHERE+IsActive=true+AND+Profile.Name+LIKE+'%25System+Administrator%25'+LIMIT+1` and capture the `Id` field from the first record.

**CRITICAL:** Do not re-query for the user ID in later phases. Use the same `TARGET_USER_ID` captured here for all subsequent operations. Re-querying can return a different user if multiple admins exist.

2. **Verify 19 required licenses** — read `references/prerequisites.md` for the full license list. Use `dispatch GET /query?q=<SOQL>` to query `PermissionSetLicense` records. If any are missing from the org, stop and inform the user.

3. **Assign missing licenses to target user** — query `PermissionSetLicenseAssign` for the `TARGET_USER_ID` captured in step 1. Assign any missing licenses via `dispatch POST /sobjects/PermissionSetLicenseAssign` using the same `TARGET_USER_ID`.

4. **Enable features** — read `references/prerequisites.md`