Why starting with standard capabilities may be the right answer more often than we think, without compromising what matters most to the business.
Toronto, October 14, 2026
At its core, this article tackles a deceptively simple question:
How much of Salesforce Financial Services Cloud (FSC) should you use as designed, and when does the business require something more?
For years, customization has been one of Salesforce’s great strengths. But with increasingly capable industry platforms such as FSC, it’s worth asking whether that flexibility sometimes leads us to build things we no longer need to build.
I have some history with this question.
When Phil Dias and I built Tier1, we took Salesforce and created a highly specialized, productized CRM platform for capital markets. We didn’t customize Salesforce for the sake of customization. We did it because we believed the complexity of the business required it.
I still do.
Which is one reason a recent Salesforce FSC implementation by our solution partner, Metacube, caught my attention. Their starting point was almost the opposite: use standard FSC wherever possible and customize only where there was a compelling reason to do so.
That got me thinking.
Have we sometimes been too quick to customize Salesforce? ”
Start With the Problem, Not Salesforce
The client was a large Asian bank serving both retail and corporate customers. The problem will sound familiar to anyone who has worked around a large financial institution.
- Product data lived in the core banking system.
- Holdings and transactions were in operational systems.
- Relationship managers didn’t have a single view of the client, and preparing for an important client meeting could mean pulling information together manually from multiple places.
By the time everything was assembled, some of it was already stale. And opportunities to deepen a relationship could be identified weeks after they actually mattered.
The objective wasn’t really to “implement Salesforce FSC”; it was to give a relationship manager one place to understand a client well enough to have a better conversation.
That distinction matters.
What Does Success Actually Require?
One thing I’ve learned from years of building software for financial services is that technology decisions get much easier once you’re very clear about the business problem you’re trying to solve.
So before deciding how much of FSC to use, I’d start by defining the success criteria.
- What does the relationship manager absolutely need?
- What’s important but not essential?
- What’s useful but perhaps not worth introducing significant complexity to achieve?
Then I’d put those requirements against FSC.
A simple rubric might look something like this:
Obviously, a real assessment would go considerably deeper than five rows. But I like the discipline behind it.
Out of the Box shouldn’t become an objective in its own right.
If something is important to the success of the business, you shouldn’t leave it out simply because it makes the implementation easier. ”
But the opposite is also true. If the platform already does something well, why spend time and money recreating it?
Standard First, Not Standard Only
That’s what I find interesting about Metacube’s approach at this bank.
Our partner deliberately anchored the solution on the standard FSC data model. Where FSC met the requirement, they configured rather than developed. Where it didn’t, they extended the solution, particularly at the presentation and integration layers, while leaving the underlying FSC objects largely standard.
I like the discipline behind that approach. Before introducing custom code, additional maintenance and future upgrade risk, ask whether the business requirement can be met with the standard platform.
But there’s an equally important second part:
Don’t compromise an important business requirement just to keep the implementation standard. The goal isn’t to minimize customization at all costs. It’s to minimize unnecessary customization. ”
What Did They Actually Build?
Metacube’s approach wasn’t to avoid customization altogether. They combined standard FSC capabilities with targeted custom development and integrations to deliver the functionality the bank actually needed.
The resulting Customer 360 workspace brought together retail and corporate client information in one place.
A relationship manager could open a client and see the basic profile, financial accounts, stated financial goals, total portfolio value and significant life or business events. Instead of assembling the picture before a meeting, the picture was there.
But some of the more interesting capabilities were outside the obvious “out-of-the-box” CRM capabilities:
- The Product Hierarchy – the bank needed a consistent way to understand its products across the institution. Metacube synchronized products from the core banking system into a four-level hierarchy, moving from broad product families down to detailed product variants. That created a common product taxonomy for analytics, reporting, and identifying potential gaps in a client’s portfolio.
- The Financial Accounts experience went further. Metacube used OmniStudio and custom Lightning Web Components to provide an aggregated view of holdings, including portfolio analysis by branch, maturity and detailed product type, together with a feed of recent transactional data.
- The Financial Summary brought the economics of the relationship into the same experience: the bank’s share of the client’s business, operating income generated by the relationship and recent transaction volumes.
That’s where the Customer 360 starts becoming more interesting to me:
It isn’t simply here is everything we know about the customer.
It’s: here is what you need to know to decide what to do next with the customer.
Would We (Should We) Have Done This at Tier1?
My conclusion: Probably not. Or at least, not to the same degree.
When we built Tier1, we believed those requirements justified building a purpose-built product on top of Salesforce rather than trying to make a more generic CRM model fit the business.
I don’t look back at that and think we got the philosophy wrong. But I do think FSC has changed the starting point. ”
Salesforce now provides considerably more financial-services-specific capability than the platform we started with years ago. FSC itself is designed around a financial-services data model and industry workflows rather than beginning with generic Sales Cloud objects. Far more sophisticated UI building blocks are available from Salesforce today, than when we were designing our product.
So perhaps the question has changed.
Instead of asking “What do we need to build on Salesforce?”, maybe the first question today should be: “What do we actually need that FSC doesn’t already give us? ”
That’s a very different starting point.
I’ve always liked the principle often attributed to Albert Einstein: As simple as possible, but not simpler.
It’s a philosophy that resonates with me, particularly when it comes to software architecture.
Customization has a cost. You have to: Design it. Build it. Test it. Maintain it. And continue reconciling it with a platform that Salesforce itself is constantly evolving.
Metacube’s approach meant the bank could continue to take advantage of the standard FSC model and Salesforce roadmap while concentrating custom engineering on areas where it created differentiated business value. That’s a compelling argument for resisting customization when it isn’t necessary.
But I think the second half of that Einstein line is equally important.
If something is genuinely important to the business, leaving it out because it complicates the implementation isn’t simplicity. It’s compromise. ”
That’s why I like the idea of starting with success criteria. Understand the workflows. Rank what’s important. Determine what good looks like. Then compare those requirements honestly against FSC.
- Use what’s already there when it works.
- Configure when configuration gets you there.
- Extend where you need differentiation.
And when something genuinely important can’t be delivered adequately with the standard platform, don’t be afraid to build it.
Maybe the goal isn’t “Out-of-the-Box” after all.
The more I thought about this implementation, the less I liked describing it as an “out-of-the-box” FSC implementation. That makes it sound as though the accomplishment was avoiding development.
It wasn’t.
The real accomplishment was putting the complexity in the right places.
The standard FSC model handled much of the foundation. Integration brought in the bank’s product, account and transactional information. Targeted development created the experiences and analytics that mattered to relationship managers.
And the business requirement, rather than an architectural ideology, determined where each was appropriate.
That’s probably where I’ve landed on this.
Start standard. Establish what success requires. Test FSC against those requirements. Configure wherever you can. Extend where you need to. Customize where the business case genuinely demands it. ”
In other words, “As simple as possible. But not simpler.”
I’m curious how others who have implemented Salesforce in financial services think about this.
Where have you found standard FSC to be enough, and where have you concluded that the business really does demand something more?
Want to Go a Little Deeper?
This article was inspired by a real Financial Services Cloud implementation by our partner Metacube for a large Asian bank. A more detailed case study covers the Customer 360 solution, product hierarchy, financial account experience, integrations and architecture.
If you’d like a copy, reach out to us. And if you’re working through the same configure-versus-customize question, we’re always happy to compare notes.
We welcome a conversation. Contact us.
