Most financial-planning decisions get triggered by a life moment, not by an investment thesis. Buying a house, getting married, having a child, retiring, losing a parent, starting a business. Each of these resets the conversation about goals, products, and risk tolerance. Each of them creates an obvious opening for an advisor or banker to re-engage.
Financial Services Cloud (FSC) ships the Life Events object as the way to capture these moments inside the CRM. The object is small. The advisor-facing workflow that connects an event to a re-planning conversation is what turns the data into pipeline.
What Life Events captures
The Life Events object is a standard FSC object. Each record represents one life moment for one Person Account. Standard fields:
- Account. The Person Account experiencing the event.
- Event Type. Picklist of the type of moment.
- Event Date. When the event occurred or is expected to occur.
- Source. Where the data came from. Customer-reported, externally observed, advisor-noted.
- Status. Anticipated, Confirmed, Realised.
FSC's standard Event Type picklist covers 12 common cases:
- Marriage
- Divorce
- Birth of Child
- Death in Family
- Job Change
- Retirement
- Home Purchase
- Home Sale
- Business Start
- Business Sale
- Inheritance
- Major Health Event
Implementations almost always extend this list. Common additions: education milestone (child starting university), relocation, separation, immigration, charitable-gift event. Each addition needs a downstream workflow plan; an event with no associated re-planning action is dead data.
Why the source field matters
The Source field distinguishes how the bank learned about the event. Three sources show up in practice:
Customer-reported. The client mentioned the event during a meeting, on a call, in a form, or through a self-service channel. The advisor logged it in the CRM. Highest trust, lowest volume.
Externally observed. The bank's data systems picked up a signal that implies the event. A spike in deposits matching a property-sale transaction. A change in salary direct-deposit pattern. A new mailing address. Lower individual trust, but at scale these signals identify events the customer never reported.
Inferred. A predictive model identified the customer as likely to experience an event soon. "Probability of home purchase in next 12 months: 80%." Used carefully, this drives proactive advisor outreach. Used carelessly, it produces creepy customer experiences.
Implementations that mix sources in one Life Events object without distinguishing them end up with inconsistent advisor workflows. The advisor following up on a customer-reported event has different context than the advisor following up on an inferred event. Source needs to be visible at every consumer of the Life Events data.
The advisor-facing workflow
The unlock from Life Events is the workflow that connects the event to advisor action. Three patterns Sapota has built on production FSC engagements:
Immediate alert plus next-best-action. When a Life Event record is inserted with high-priority types (Marriage, Home Purchase, Retirement), an immediate notification flows to the relationship advisor. The Action Plan template specific to the event type opens automatically, populated with the recommended next steps. The advisor sees the moment and the playbook together.
Scheduled re-planning prompt. Lower-priority event types do not need immediate action but warrant a check-in. The event triggers a scheduled task on the advisor's queue, with a calendar lag tuned to the event type (Birth of Child triggers a 60-day post-event prompt; Job Change triggers a 30-day prompt).
Financial-Goal recalculation. Goals attached to the Person Account get flagged for review when the underlying assumptions change. A child's birth resets the education-savings goal. A retirement event triggers the retirement-income goal review. The Goal records carry a "Review Recommended" status until the advisor processes them.
All three workflows depend on the Life Events data being current. The customer-reported path is the slow trickle. The external-observation path produces the bulk of the volume.
Integration patterns
The external-observation source is where most production volume comes from. Three integration patterns common on FSC implementations:
Transactional pattern matching. The core banking system's transaction stream feeds into a rules engine that flags candidate events. A high-value debit from an existing account to a real-estate-broker payee implies Home Purchase. A change in salary direct-deposit source implies Job Change. The rules engine writes Life Event records with Source = Externally Observed and Status = Anticipated.
Document-driven inference. Customer-submitted documents (mortgage applications, account update forms, KYC updates) get parsed for life-event signals. A change of marital status on a form produces a Marriage or Divorce event. A change in dependent count produces a Birth or Major Health Event.
Third-party data overlay. External data providers (credit bureaus, public records, marketing-data vendors) supply event signals as part of standard data refresh. Quality varies; the data needs cleaning before it lands in FSC. Implementations that skip the cleaning step end up with noisy Life Event volumes that the advisor team learns to ignore.
The integration shape is the single biggest factor in how much value Life Events produces. Customer-reported alone covers 10 to 20% of actual events. The rest live in the integration pipeline.
Privacy and consent
Externally observed and inferred Life Events carry consent risks. A customer who has not consented to behavioural inference may object to being marked as a Retirement candidate based on age and transaction pattern. The consent profile attached to each Person Account should govern which Life Event sources are allowed.
Three practical guardrails:
Source-aware retention. Customer-reported events keep their data indefinitely. Externally observed events get a finite retention window (typically 12 to 24 months) after which they are purged if not promoted to Confirmed status.
Opt-out propagation. A customer who opts out of marketing receives no advisor outreach driven by inferred events. The opt-out flag on the Person Account masks the inferred-event records from any outreach surface.
Audit logging. Every advisor action driven by a Life Event gets logged. The audit trail supports any subsequent customer challenge about "how did you know I was buying a house".
The compliance team owns the consent-and-retention policy. The implementation team builds the enforcement.
Reporting and pipeline measurement
The Life Events object becomes a measurement surface in mature implementations. The reports that matter:
Event-to-conversation conversion. Of all Life Events created, what percentage produced a logged advisor conversation within the recommended lag window. Measures advisor follow-through.
Event-to-product conversion. Of all Life Events with an advisor conversation, what percentage produced a new product opening within 90 days. Measures the cross-sell effectiveness of the workflow.
Source-level lift. Which Source (customer-reported, externally observed, inferred) produces the highest conversion rate. Often surprising: externally observed events frequently convert better than customer-reported, because the bank's signals identify intent before the customer announces it.
These reports drive continuous improvement on the integration rules, the Action Plan templates, and the advisor training. The Life Events object stops being a data warehouse and starts being a sales engine.
Designing the Life Events workflow for an FSC implementation? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs Life Events architecture, integration design, and advisor-facing workflow on every FSC engagement. Get in touch ->
See our Salesforce service page for the team.
