Salesforce Financial Services Cloud (FSC) extends the standard Salesforce platform with financial-services-specific objects: FinancialAccount, FinancialAccountRole, FinancialGoal, FinancialHolding, PersonAccount, and the Household model. These objects hold client relationship data that becomes exponentially more valuable when connected to custodian data (positions, transactions, cash flows), portfolio management data (performance, allocations, models), and financial planning data (goals, projections, Monte Carlo results). Milemarker builds that connection without requiring any Salesforce customization.
The FSC Data Model
Financial Services Cloud is not just a CRM with a financial theme. It is a purpose-built data model for wealth management relationships, and understanding its structure is the first step to understanding why integration is both necessary and difficult.
The Core FSC Objects
- PersonAccount — your client as an individual person. In FSC, individuals are represented as a hybrid Account/Contact record rather than a standard Salesforce Contact. This is unique to FSC and affects how data must be extracted.
- FinancialAccount — an account your client holds, such as an IRA, joint taxable account, trust, or 529. This object sits at the heart of FSC and connects the person to their financial life.
- FinancialAccountRole — the link between a person and a financial account, capturing whether they are the owner, a beneficiary, a trustee, or another role. A single FinancialAccount can have multiple roles.
- Household — a grouping of related PersonAccounts. FSC's Household model captures the family unit, preserving member relationships and shared financial context.
- FinancialGoal — planning data attached to a client or household, often underused because it requires manual entry and rarely connects to actual plan projections.
- FinancialHolding — position-level data within a FinancialAccount, also frequently underused since this data lives more reliably in custodian and portfolio management systems.
Beyond the FSC Objects
FSC firms also carry the full weight of the standard Salesforce platform. Task and Event records capture activity history. Note and ContentNote records hold documentation. Opportunity records track new business. Case records manage service requests. Each of these standard objects can have thousands or millions of records in a mature firm's Salesforce org.
On top of that, most FSC implementations include custom objects built by internal admins or Salesforce consultants — fields and objects that capture firm-specific data not covered by the standard FSC model. And many firms have installed managed packages from the Salesforce AppExchange, which add their own objects and fields into the mix.
This complexity — standard Salesforce objects, FSC objects, custom objects, and managed package objects all living in the same org — is exactly why integration is hard. And it is why most firms have never successfully connected FSC to their other systems.
The Integration Challenge
Salesforce's API Is Powerful but Complex
Salesforce exposes multiple API surfaces: the REST API for record-level operations, the Bulk API for high-volume extraction, the Streaming API for real-time change detection, the Composite API for batching multiple requests, and the Metadata API for schema discovery. Building a reliable integration requires knowing when to use each, how to handle governor limits, and how to recover from partial failures. This is not a problem a general-purpose integration tool solves well.
Rate Limits Constrain Extraction
Salesforce enforces API call limits on a 24-hour rolling basis. The limits vary by edition and add-on purchases, but they are real constraints that affect how much data you can extract per day. A naive integration that hammers the REST API can exhaust your org's API budget and degrade performance for your users. Proper integration requires rate limit awareness, Bulk API prioritization, and intelligent backoff behavior.
FSC's Data Model Does Not Map Cleanly to Other Systems
FSC's FinancialAccount is not the same as a custodian account number. A Household in FSC may not correspond to a household in your portfolio management system. FinancialAccountRole relationships carry meaning that gets lost if you treat FSC records as flat rows. Connecting FSC data to other systems requires understanding both sides of the mapping — the FSC object model and the target system's data model — and building transformation logic that preserves the relationships rather than flattening them.
Custom Objects Add Unpredictable Schema Elements
Every FSC org is different. A firm that has been on Salesforce for five years with an active consultant relationship may have dozens of custom objects and hundreds of custom fields. A newer firm may have a relatively clean org. Any integration that does not read the org's actual schema at setup time will miss data that matters to your team.
Custom Development Is Expensive and Fragile
Most integration projects that attempt to connect FSC to other systems require Salesforce consultants to design the approach, integration specialists to build the connector, and ongoing maintenance when Salesforce releases updates — three times per year — break the integration. The typical cost for a single custom connection runs from $50,000 to $100,000 or more, and the connection often fails within a year without continued maintenance investment. The result: most firms have Salesforce disconnected from everything except email and calendar.
How Milemarker Connects FSC
OAuth 2.0 Connected App — Read-Only, No Passwords Stored
Milemarker connects to your Salesforce org through an OAuth 2.0 Connected App configured with read-only access. Your Salesforce administrator authorizes the connection from within your org's setup. No passwords are stored by Milemarker. The authorization can be revoked at any time from your Salesforce settings without affecting any other system.
Native FSC Object Model Support
Milemarker's FSC connector understands the full FSC object model natively — including the PersonAccount hybrid structure, the FinancialAccountRole relationship model, and the Household member linkage. It does not treat FSC as generic Salesforce. Every FSC-specific relationship is preserved through the extraction and normalization process so that household structures, account ownership chains, and role hierarchies remain intact in your warehouse.
Full Schema Discovery
At setup, Milemarker reads your org's complete schema using the Salesforce Metadata API. Every standard object, every FSC object, every custom object, and every managed package object is discovered. Field-level data, picklist values, lookup relationships, and formula field results are all included in the extraction plan. Your org's specific configuration drives what gets extracted — not a generic template.
Bulk API for Initial Backfill, Streaming API for Incremental Updates
Milemarker uses the Salesforce Bulk API for the initial historical backfill. Bulk API jobs process large volumes of records in batches under separate governor limits, meaning the extraction does not compete with your users' API consumption. After the backfill, the Streaming API provides real-time change detection so your warehouse stays current with new and modified records without polling the REST API repeatedly.
Rate Limit Management Built In
Milemarker monitors your org's API limit consumption throughout the extraction process. When limits approach thresholds, the connector throttles automatically and resumes when capacity is available. Your users experience no degradation in Salesforce performance, and your operations team does not need to manage or monitor the integration's API behavior.
Normalized into Your Snowflake Instance
All extracted FSC data is normalized into Milemarker's unified wealth management schema and loaded into your Snowflake data warehouse — which your firm owns and controls. FSC records do not land in a proprietary Milemarker database. They land in your Snowflake instance, where your analytics team, your BI tools, and Milemarker's AI layer all read from the same data.
Client Identity Resolution Across All Systems
The critical step after extraction is linking FSC PersonAccount records to the same client's records in other systems. Milemarker's identity resolution layer matches FSC PersonAccount IDs to custodian account numbers, portfolio system client IDs, and financial planning system records using a combination of shared identifiers — tax IDs, account numbers stored in FSC custom fields, and name-based fuzzy matching. Every link is auditable and overridable by your operations team.
What Connects to FSC Through Milemarker
Custodians
Schwab, Fidelity, Pershing. Positions, transactions, and cash flows are joined to FSC client records so every custodian account links to the CRM relationship that owns it.
Portfolio Systems
Orion, Black Diamond, Tamarac. Performance and model data is linked to FSC households so portfolio analytics connect to the CRM layer that defines client relationships.
Financial Planning
eMoney, MoneyGuidePro. Goal and projection data enriches FSC client profiles so planning outcomes connect to the CRM records that track the advisory relationship.
Document Management
DocuSign and box integrations. Documents are linked to client records across systems so compliance documentation connects to the Salesforce activity history that documents the advisory process.
Compliance Systems
Trade surveillance and communication monitoring are connected to CRM activity history so compliance reviews have the full advisory context alongside the surveillance data.
Market Data
Benchmarks, indices, and security-level data enrich portfolio analytics in the warehouse, giving context to custodian positions and portfolio system performance numbers.
After Integration: What Becomes Possible
Connecting FSC to Milemarker changes what your team can see, build, and ask — at every level of the organization.
Flat Iron Wealth, a hypothetical mid-size RIA on FSC, illustrates the difference. Before Milemarker, advisors opened Salesforce for relationship context, the custodian portal for account positions, Orion for performance, and eMoney for planning projections before every client meeting. Four systems, four logins, no common data model. With Milemarker, all four systems land in a single Snowflake warehouse joined by client identity. A single query surface, one version of the truth.