When organizations evaluate or implement a CRM like Nonprofit Cloud, one of the most important, and often misunderstood, decisions is how much to configure versus how much to customize.
At Heller Consulting, this isn’t considered a technical preference. We see it as a strategic decision that shapes everything from long-term cost to staff adoption to the system’s ability to evolve over time.
Across our work, a clear philosophy has emerged: Prioritize configuration wherever possible, and approach customization deliberately. Here’s what your organization should consider before deciding.
What we mean by configuration vs. customization
Most modern CRM platforms, especially Salesforce and Microsoft, are designed to be extended through both. The question isn’t whether customization is possible, but when it’s appropriate.
Configuration refers to using native platform capabilities: Fields, objects, automation tools, reporting, and other low-code or no-code features.
Customization refers to extending the platform through code or bespoke development to create functionality not available out of the box.
Why Heller prioritizes configuration
1. Long-term sustainability matters more than short-term perfection
One of the most consistent patterns we see is that heavily customized systems become harder to manage over time. Custom code requires specialized knowledge, introduces dependencies, and can make even small changes more complex.
That’s why we prioritize native functionality first. Using declarative, low-code tools reduces technical debt and supports long-term sustainability for your organization.
Equally important, it ensures your system can be maintained by your internal team—not just external developers. We routinely evaluate design decisions against a simple question: can your team support this without ongoing outside help?
2. Your CRM should align with platform best practices
It’s natural to want a new system to mirror your old one. But replicating legacy processes through customization often leads to unnecessary complexity, longer timelines, and a less intuitive user experience.
Instead, we encourage organizations to adapt processes where it makes sense and take advantage of how the platform is designed to work. This means leveraging the existing structure and functionality of the platform first, before extending it.
In practice, this shift can dramatically improve usability and reduce friction for staff.
3. Configuration accelerates time-to-value
Customization adds building and testing time. When teams attempt to solve every edge case upfront, projects expand quickly.
A configuration-first approach allows teams to focus on core functionality and deliver value earlier. In many cases, we recommend launching a minimum viable system that meets immediate needs, then enhancing it iteratively based on real-world usage. This approach leads to faster adoption and better-informed decisions about where additional investment is actually needed.
4. Flexibility and adaptability over time
Configured solutions are easier to evolve. As your fundraising model changes, programs expand, or reporting needs shift, declarative tools allow your team to adjust workflows without reengineering the system.
Customization can still be extended and maintained but it creates more friction with every change.
For organizations navigating growth or transformation, this flexibility is critical.
