Solution: TrustShield Insurance

Work in Progress

This content is currently being reviewed for accuracy and will be updated soon.

Architecture Decisions

Three decisions define the architecture of this solution. Everything else flows from them.

Decision 1: Apex managed sharing for book-of-business isolation. Standard role hierarchy cannot satisfy the split-policy requirement (BR-2). A single policyholder held by two agents under the same hierarchy would expose both agents’ policies to each other under OWD-Private-with-role-hierarchy. Apex managed sharing (programmatic share records on Policy__c and Account) is the correct mechanism. OWD on Policy and Policyholder records is set to Private, and sharing grants are written programmatically when a policy is created or reassigned.

Decision 2: MuleSoft for carrier integration, not native Salesforce callouts. The combination of a SOAP carrier with 1.5-4 second response times, a REST carrier, async document retrieval from DocuWare, a nightly SFTP batch, and the explicit requirement to add a third carrier without re-architecture points to an integration platform. Native Salesforce callouts would scatter the complexity across multiple Apex classes, each with governor limit exposure, no reusable transport layer, and no configurable field mapping for ops staff. MuleSoft Anypoint Platform, although Salesforce-owned, is licensed separately from Sales Cloud and Service Cloud; TrustShield must budget an additional MuleSoft subscription on top of the core Salesforce licenses. At the volumes in this scenario (two production carriers, two to three Anypoint workers, nightly SFTP batch), the MuleSoft line should be sized at roughly $120,000 to $220,000 per year for the Titanium tier that includes Anypoint MQ and Secure Properties. This cost is called out explicitly in the project budget and is the single largest integration line item. The benefit is a structured integration layer with visual DataWeave mapping that ops staff can modify, a message queue for retry logic, and a carrier-agnostic connector pattern.

Decision 3: Experience Cloud with a dedicated permission set license for independent agents. 62 independent agents (1099 contractors) need access distinct from internal staff. Experience Cloud Customer Community Plus licenses give each agent their own authenticated session, enforce profile-level access that hides internal operational records, and map naturally to the Apex sharing grants that drive book-of-business isolation. The license cost is predictable and scales linearly as TrustShield adds agents. Customer Community Plus is the current license name in the Salesforce Experience Cloud pricing catalog; the parent platform rebrand from Community Cloud to Experience Cloud is from 2021 and does not change the underlying SKUs.

System Landscape

Data Model

Core Objects

Object	Type	Key Fields	Notes
Account (Policyholder)	Standard	Name, Address, Phone, Email	OWD: Private. Shared via Apex to writing agents per policy
Policy__c	Custom	PolicyNumber, Carrier__c, LineOfBusiness__c, EffectiveDate, ExpiryDate, Status, WritingAgent__c, Premium__c	OWD: Private. Junction to Account via lookup
Agent__c	Custom	LicenseNumber, LicenseType, LicenseExpiry, AppointmentStatus_Horizon__c, AppointmentStatus_SummitRe__c, AgencyPrincipal__c	Master record for contractor identity
Agency__c	Custom	AgencyName, PrincipalAgent__c	Groups agents for principal-level access
Carrier__c	Custom	CarrierName, APIType, EndpointURL, AuthMethod, IsActive	Supports the carrier-abstraction requirement
CarrierAppointment__c	Custom	Agent__c, Carrier__c, EffectiveDate, Status, LastConfirmedDate	Junction for agent-carrier appointments
Quote__c	Custom	Policy__c, Carrier__c, QuoteStatus, CarrierQuoteRef, RequestPayload, ResponsePayload, ExpiryDate	Holds in-progress or saved quotes
FNOL__c	Custom	Policy__c, Account__c, DateOfLoss, LossType, Description, CarrierRefNumber, NotificationTimestamp, HandlingRep__c, CarrierAckStatus	First notice of loss
CarrierAPILog__c	Custom	Carrier__c, Operation, RequestPayload, ResponsePayload, HTTPStatus, CarrierRefNumber, InitiatingUser__c, Timestamp	Immutable log: no delete, no update
Commission__c	Custom	Agent__c, Period, TotalAmount, PolicyCommissionLines (child)	Source for agent commission statements
Document__c	Custom	RelatedRecord__c, RelatedRecordType__c, DocuWareID, DocumentType, RetrievalStatus	Tracks DocuWare documents linked to SF records
AgentOnboardingTask__c	Custom	Agent__c, TaskType, Owner, DueDate, CompletedDate, Status	Checklist row for onboarding workflow
LicenseAuditLog__c	Custom	Agent__c, FieldChanged, OldValue, NewValue, ChangedBy, ChangeTimestamp	Immutable: enforced via trigger and Restrict Delete

The split-policy requirement (BR-2) cannot be solved by sharing rules based on a field value on the Account, because the Account is shared but the policies on it are not: each policy has a distinct writing agent. The model works as follows:

Account OWD: Private. Policy__c OWD: Private.
When a Policy is created, an Apex trigger fires and creates an AccountShare record granting the WritingAgent__c user Read access to the Account, and a Policy__Share record granting the same user Read/Write access to the Policy.
If a second policy for the same Account is later created with a different writing agent, a second AccountShare row is inserted for the new agent, granting them Account Read access only (so they can see the policyholder name and contact info for their own policy context), but no Policy__Share for the first policy.
Each agent therefore sees the Account (read) and only their own Policy records (read/write).
Global search isolation is achieved because SOSL and search results respect record-level sharing. No additional configuration is required beyond the share rows.

Integration Architecture

Carrier Abstraction Layer

The Carrier__c object acts as a configuration record for each carrier. MuleSoft reads this record to determine the endpoint, authentication method, API type (SOAP vs REST), and active status before each call. Adding a third carrier requires a new Carrier__c record and a MuleSoft configuration artifact. No Apex changes, no redeployment.

Horizon P&C (SOAP)

MuleSoft hosts a dedicated Anypoint connector for Horizon using the WSDL schema.
DataWeave transformations in MuleSoft map Salesforce field names to Horizon WSDL field names. Operations staff can modify mappings in Anypoint Studio without a Salesforce deployment.
Salesforce initiates calls via Platform Events. The agent action (quote, bind, endorsement) fires a Platform Event. MuleSoft subscribes and executes the carrier call, then posts the response back via a second Platform Event consumed by Salesforce.
This pattern keeps the agent UI non-blocking. The agent sees a spinner until the response arrives via the Platform Event, typically within 4 seconds. Platform Events are asynchronous; the agent UI uses a polling or streaming mechanism (Streaming API/CometD) to display the response when it arrives. This is not a true synchronous request-response. The UI subscribes to the response event channel and updates when the event is received.
Authentication: username/password + static IP allowlist. MuleSoft Secure Properties stores credentials and handles annual rotation without Salesforce involvement.
Retry logic: if Horizon is unavailable, MuleSoft queues the request in Anypoint MQ with a 3-retry backoff. After exhausting retries, MuleSoft publishes a failure Platform Event. A Salesforce flow consumes this and creates an Ops_Alert__c record, sending an email to the operations distribution list within 5 minutes (BR-15).

Horizon Nightly SFTP Batch (BR-10)

MuleSoft polls the SFTP server nightly at 01:00 MT using a scheduled flow.
The file is parsed, and each row is matched to an existing Policy__c by PolicyNumber.
Matched records are updated (status, premium). New rows create pending Policy__c records flagged for manual review. Unmatched rows are written to a Reconciliation_Report__c record with the raw row content.
A summary email is sent to the ops team each morning with counts: updated, created-pending, unmatched.

Summit Re (REST)

MuleSoft connector for Summit Re REST/JSON API handles quoting and status retrieval.
Because API binding is not available in Phase 1 (BR-11), when a quote is ready for binding, the Salesforce UI displays a “Proceed to Bind” button that opens the Summit Re web portal URL with pre-filled parameters (policy number, agent ID). A PendingBind__c status record is created in Salesforce to track the outstanding bind.
The status record has an automated reminder to the agent after 48 hours if the bind is not confirmed. Ops staff can manually mark the bind as complete when Summit Re confirms.

DocuWare (REST + OAuth 2.0)

MuleSoft handles OAuth 2.0 token management for DocuWare, refreshing tokens transparently.
Document retrieval is fully asynchronous (BR-14). When an agent requests a document, a Platform Event fires. MuleSoft retrieves the document from DocuWare and pushes it to Salesforce Files, then fires a completion event. A Salesforce notification appears for the agent. The agent never waits on a synchronous callout.
New documents generated in Salesforce (FNOL reports, agent agreements) are pushed to DocuWare via MuleSoft. The returned DocuWare document ID is stored on the Document__c record.
DocuWare abstraction: all document interactions route through MuleSoft, not direct Apex callouts. If DocuWare is replaced, only the MuleSoft connector changes. Salesforce sees only the Document__c record and a Salesforce File. There is no direct DocuWare API dependency in Salesforce code.

API Logging (BR-12)

All carrier API calls (request, response, status, carrier reference, initiating user, timestamp) are written to CarrierAPILog__c by MuleSoft after every call. The object has no delete permission for any profile. A Salesforce trigger blocks any DML update on existing rows. Rows older than 24 months are moved to an ArchivedCarrierAPILog Big Object via a scheduled Apex batch, preserving queryability for compliance reporting while keeping the transactional object lean. Records in the Big Object are retained for 7 years, after which a second scheduled job deletes rows past retention.

DOI Access-Log Retention (BR-7)

Colorado DOI examinations can require up to 7 years of user access history. Shield Event Monitoring provides the telemetry but does not, by itself, satisfy long-term retention: the native EventLogFile object retains event data for 30 days by default, and a maximum of 1 year with the Shield Event Log File Storage add-on. A two-tier archive pattern closes the gap:

Tier 1 (0-365 days, in Salesforce): Shield Event Monitoring writes to EventLogFile. The Salesforce Event Log File Browser AppExchange tool and CRM Analytics apps provide on-demand compliance queries for the recent window.
Tier 2 (1-7 years, external SIEM or archive): A nightly MuleSoft flow reads new EventLogFile rows via the Analytics API, streams them to TrustShield’s SIEM (Splunk Cloud is the stated platform) and to an S3 Glacier archive with a 7-year lifecycle policy. The SIEM is the primary interactive query surface for DOI audit requests beyond the one-year Salesforce window; the S3 archive is the immutable system of record for the full 7 years.
Tier 3 (Field history): Field Audit Trail is enabled on Agent__c, Policy__c, and CarrierAppointment__c fields relevant to DOI examination. Field Audit Trail retains field change history for up to 10 years natively, covering the 7-year DOI bar without external archive.

The compliance officer’s DOI-ready report pulls from three sources: CarrierAPILog__c and its Big Object archive for integration-layer access, the SIEM for user access telemetry beyond 1 year, and FieldHistoryArchive for field change history. A single CRM Analytics dashboard with external connectors aggregates all three for the examiner.

Profile and Permission Set Design

User Group	License	Profile	Key Restrictions
Independent agents	Experience Cloud Customer Community Plus	Agent - External	No internal ops views, no management dashboards, no other agents’ data
Internal agents (captive)	Salesforce (full CRM)	Agent - Internal	Same data scope as external but on core UI
Customer service reps	Salesforce	CSR	Read-only on Policy__c and Account; no edit permission via profile
Ops and admin	Salesforce	Ops Staff	Full access to Policy, FNOL, integration logs
Management	Salesforce	Management	Full access plus reporting dashboards
Compliance officer	Salesforce	Compliance	Read-only on all Agent, Policy, FNOL, Log objects; Field Audit Trail enabled
Agency principals	Salesforce or Experience Cloud	Agent + Permission Set: Agency Principal	Sees own book + all agents in their agency via sharing group
DOI examiner	Salesforce (time-limited)	DOI Examiner (read-only profile)	See below

Agency Principal Access (BR-3)

Agency principals need visibility across their agency’s agents without seeing outside data. The solution uses a Public Group per Agency, managed by a flow that adds/removes agents as agency membership changes. The principal gets Read access to all records owned by members of their agency group via a Criteria-Based Sharing Rule on Policy__c (Agency__c = principal's agency) granting Read access to the principal’s user record.

DOI Examiner Provisioning (BR-33)

A custom Lightning flow, triggered by the compliance officer, creates a new Salesforce user with the DOI Examiner profile, sets the user’s IsActive = true, and creates an automated scheduled job to set IsActive = false on the expiry date entered by the compliance officer. User creation and deactivation events are written to a DOIExaminerAccess__c audit object. The compliance officer can deactivate early at any time. This satisfies the time-limited, auto-expiring, auditable access requirement without third-party tooling.

Immutable Audit Logs (BR-31)

Two mechanisms enforce immutability. First, the LicenseAuditLog__c and CarrierAPILog__c objects have no Update or Delete permissions on any profile, including System Administrator, enforced at the profile level and backed by an Apex trigger that throws a DmlException on any attempted update. Second, Field Audit Trail (available with Shield or as an add-on) is enabled on the Agent__c license and appointment fields, providing platform-level, tamper-evident history that satisfies DOI examination standards.

License-Expiry Block on Quote Submission (BR-32)

MuleSoft checks the LicenseStatus__c field on the Agent__c record before forwarding any carrier API call. If the status is Expired or Pending Renewal, MuleSoft rejects the call and returns a structured error. Salesforce receives this via Platform Event and displays a blocking message in the agent UI. A ComplianceAlert__c record is created and the compliance officer receives an email notification. The check is in MuleSoft (not only in the UI) so it cannot be bypassed through the API layer.

Migration Strategy

TrustShield has 6 years of policy history in AMS360 and 8 years of documents in DocuWare. The migration is a two-phase effort.

Phase 1: Pilot Data (Months 1-4)

Load a representative slice of active policies (current policy year) and their associated agents to validate the sharing model before full migration. Use Salesforce Data Loader or the Bulk API 2.0 for Policy__c and Account records. Apex sharing triggers fire during load. Validate that share rows are correct before proceeding.

Phase 2: Full Historical Load (Months 4-10)

AMS360 to Salesforce: Export all policy and policyholder records from AMS360 as CSV. Transform using a mapping sheet agreed with TrustShield ops. Load via Bulk API 2.0. Historical commissions loaded to Commission__c for the previous 3 years (IRS requirement for 1099 contractors).
DocuWare: Documents stay in DocuWare in place. The Document__c object in Salesforce stores the DocuWare document ID and metadata. MuleSoft retrieves documents on demand. No bulk migration of document binaries into Salesforce is needed or recommended given the contract renewal uncertainty.
Agent records: Migrated from spreadsheets. The SI partner runs a data quality sprint to standardize license numbers and expiry dates before load.

Reconciliation

A post-migration reconciliation process compares AMS360 policy counts to Salesforce policy counts by agent, by line of business, and by carrier. Discrepancies are flagged in a reconciliation report reviewed by TrustShield ops before cutover.

Reporting Approach

Report or Dashboard	Audience	Source	Notes
Agent production dashboard	Individual agents	Policy__c filtered by OwnerId	Personalized via Experience Cloud dynamic dashboard
Agency production report	Agency principals	Policy__c scoped to agency’s agents	Shared via Public Group sharing
Open FNOL daily report	Claims director	FNOL__c, grouped by CarrierAckStatus	Scheduled delivery at 07:00 daily
FNOLs over 24 hours without carrier ref	Claims director	FNOL__c, filter on CarrierRefNumber is null and CreatedDate older than 24h	Part of same dashboard as above
DOI compliance report (BR-30)	Compliance officer	Policy__c + Agent__c + LicenseAuditLog__c	Report type spanning Policy and Agent; exportable CSV/PDF via standard report export
Agent license expiry	Compliance officer, agency principals	Agent__c, filter LicenseExpiry within 60 days	Scheduled report + automated flow alert
Integration failure log	Ops	CarrierAPILog__c, filter HTTPStatus not 200	Ops team monitors daily

Management dashboards (production by carrier, premium volume trend, claims frequency) are built on the same objects. Agents do not have access to these report folders.

Requirements Addressed

Req	Requirement Summary	Solution Element
BR-1	Agent sees only own policyholders and policies	OWD Private on Account and Policy__c; Apex sharing grants only to writing agent
BR-2	Split-policy: two agents on same policyholder, neither sees the other’s policy	AccountShare Read for each writing agent; PolicyShare only for the specific writing agent
BR-3	Agency principals see full agency book	Public Group per agency; criteria-based sharing rule grants principal Read on agency policies
BR-4	CSRs read-only on all policyholders/policies	CSR profile with no Edit on Account or Policy__c; View All Records on those objects
BR-5	Ops and management see all records; agents blocked from management dashboards	Ops/Management profiles with View All Data; report folders restricted by role
BR-6	Compliance officer read-only on all agent and audit records	Compliance profile; Field Audit Trail enabled; DOIExaminerAccess__c object
BR-7	All record access logged for DOI, 7-year retention	Three-tier pattern: Shield Event Monitoring (Tier 1, 0-365 days in Salesforce) → nightly MuleSoft export to Splunk SIEM (Tier 2, 1-7 years queryable) → S3 Glacier archive with 7-year lifecycle (Tier 3, immutable system of record). Field Audit Trail on Agent, Policy, and Appointment records covers field change history for up to 10 years. CarrierAPILog__c + Big Object archive covers integration-layer access.
BR-8	Horizon SOAP integration: quote, bind, endorse, status	MuleSoft Anypoint connector; Platform Events for async dispatch; retry via Anypoint MQ
BR-9	Field mapping configurable without code deployment	DataWeave in MuleSoft; ops-editable mapping in Anypoint
BR-10	Nightly SFTP batch from Horizon: process and reconcile	MuleSoft scheduled SFTP poller; Reconciliation_Report__c for unmatched rows
BR-11	Summit Re REST: quotes; manual bind handoff	MuleSoft REST connector; PendingBind__c record; portal URL handoff in UI
BR-12	All carrier API calls logged 7 years	CarrierAPILog__c written by MuleSoft; no delete/update permissions; batched to ArchivedCarrierAPILog Big Object at 24 months; purged from Big Object at 7 years
BR-13	DocuWare integration: retrieve and push documents	MuleSoft connector for DocuWare REST + OAuth 2.0; Document__c stores DocuWare ID
BR-14	DocuWare retrieval async	Platform Event → MuleSoft → Salesforce Files → completion notification
BR-15	Fallback and retry for Horizon outage; ops alert within 5 minutes	Anypoint MQ retry queue; failure Platform Event → Ops_Alert__c → email flow
BR-16	Third carrier addable without re-architecture	Carrier__c configuration record; MuleSoft reads carrier config at runtime
BR-17	Agent quote-to-bind workflow in Salesforce	Quote__c LWC with carrier-specific action buttons; Horizon SOAP flow; Summit Re portal handoff
BR-18	Personalized agent home page	Experience Cloud dynamic dashboard scoped to logged-in user
BR-19	Agent onboarding in 7 days with tracked checklist	AgentOnboardingTask__c; Salesforce Flow orchestration; DocuSign for e-signature; MuleSoft for DocuWare storage
BR-20	License expiry alert at 60 days; auto-suspend on expiry	Scheduled Flow on Agent__c.LicenseExpiry; MuleSoft license check blocks API calls on expired status
BR-21	Agent commission statements by month/year, PDF download	Commission__c + CommissionLine__c objects; Visualforce or LWC PDF render; scoped by OwnerId
BR-22	Independent agents on Experience Cloud, distinct access	Customer Community Plus license; Agent - External profile; no internal views exposed
BR-23	Structured FNOL data capture	FNOL__c with required fields; linked to Policy__c and Account
BR-24	Carrier-specific FNOL notification	Flow on FNOL__c creation; Horizon: SOAP via MuleSoft; Summit Re: email via Salesforce Email Action
BR-25	FNOL captures carrier ref, first-contact timestamp, rep name	Required fields on FNOL__c; populated by CSR or auto-populated from carrier response
BR-26	Claims director daily FNOL report	Scheduled Salesforce report delivered at 07:00; includes overdue filter
BR-27	Policyholder email confirmation within 1 hour of FNOL	Flow on FNOL__c: email template sent immediately on creation. Design trade-off: if the carrier reference number arrives asynchronously (after the FNOL is submitted), the initial confirmation email cannot include it. The solution sends an immediate confirmation without the carrier ref, then triggers a second email via Flow when the CarrierRefNumber field is populated. This satisfies the 1-hour SLA while acknowledging the async nature of carrier acknowledgment.
BR-28	Agent record carries license and appointment data	Agent__c fields: LicenseNumber, LicenseType, LicenseExpiry, AppointmentStatus per carrier
BR-29	Appointment records per agent-carrier	CarrierAppointment__c object; Horizon appointments loaded via CSV import; Summit Re manual entry
BR-30	DOI-ready compliance report exportable CSV/PDF	Joined report across Policy__c and Agent__c; standard Salesforce export; scheduled run available
BR-31	Immutable audit log for license and appointment changes	LicenseAuditLog__c; no delete/update on any profile; Apex trigger enforcement; Field Audit Trail
BR-32	Block quote submission if agent license expired	MuleSoft pre-call check on Agent__c.LicenseStatus; reject with compliance alert if expired
BR-33	Time-limited DOI examiner user provisioning	Compliance officer flow creates user with expiry-date scheduled deactivation; DOIExaminerAccess__c audit object

Risk Assessment

Risk 1: Apex sharing trigger performance under bulk load. The split-policy sharing model depends on Apex triggers inserting share rows on Policy creation. During the historical data migration (potentially tens of thousands of records), the trigger will fire repeatedly and may hit CPU or DML limits under bulk load. Mitigation: make the trigger bulk-safe from the start, use Database.SaveResult arrays rather than individual inserts, and run the migration during off-hours with Data Loader chunk size limited to 200 rows per batch to stay within governor limits.

Risk 2: MuleSoft sizing for the Horizon SOAP response window. At 1.5-4 seconds per call, agents initiating quotes during peak hours could generate concurrent MuleSoft worker threads that exhaust the Anypoint worker allocation. Mitigation: size the Anypoint plan for at least 2 workers in production (not the default shared worker), and implement a Platform Event queue that smooths spikes rather than firing synchronous callouts directly.

Risk 3: DocuWare contract expiry creating a migration gap. The contract renewal decision is in 14 months and the project runs 18 months. If TrustShield does not renew, they need a document management replacement with an 8-year archive migration, mid-project. Mitigation: the architecture already abstracts DocuWare behind MuleSoft. The SI partner should document the MuleSoft connector swap procedure as a Runbook during Phase 1, so it is ready to execute if the contract is not renewed. Budget contingency for document migration should be flagged to the CEO now.

Risk 4: No in-house Salesforce developer post-go-live. The architecture relies on Apex triggers (sharing model, audit log enforcement) and MuleSoft flows. A single admin cannot maintain Apex or MuleSoft without developer support. Mitigation: negotiate a managed services retainer with the SI partner for Apex and MuleSoft support in Year 1. Identify and document the top 10 Apex-touching processes so the admin knows when to escalate. Target moving as many flows as possible to declarative Flows to reduce Apex surface area.

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.

Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.