Who this is for
IT leaders, sales managers, and RevOps teams running Salesforce who need to manage tri-annual releases, Apex customisations, and integration complexity.
Question this answers
How do we manage Salesforce's release cycle, keep customisations stable, and control integration sprawl?
What you'll leave with
- How Salesforce's release cycle works and what to plan for
- Common customisation and integration challenges
- When to use Flow vs Apex vs external applications
- Key risks for complex Salesforce environments
Platform overview
Salesforce is the dominant CRM platform globally and in Australia. Originally a sales CRM, it's grown into a massive platform ecosystem covering Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud, and the broader Salesforce Platform (custom apps, Apex, Flow, Lightning).
For Australian businesses, Salesforce is often the CRM of choice for mid-to-large sales teams, but the platform's complexity grows fast. What starts as a clean Sales Cloud implementation can become a sprawling ecosystem of custom objects, Apex triggers, Flow automations, AppExchange packages, and integrations within a few years.
The challenge isn't whether Salesforce can do what you need — it almost certainly can. The challenge is managing the complexity that comes with a mature Salesforce environment.
Common version & support issues
Tri-annual releases. Three major releases per year (Spring, Summer, Winter) introduce new features, deprecate old ones, and can change platform behaviour. You can't opt out. Sandbox preview periods are available, but you need a structured process to use them effectively.
API version deprecation. Salesforce deprecates old API versions on a rolling basis. Apex code, integrations, and AppExchange packages that reference deprecated API versions will eventually break. Staying within 2-3 versions of current is best practice.
Governor limits. Salesforce enforces strict execution limits (governor limits) on CPU time, SOQL queries, DML statements, and more. As your org grows and processes become more complex, you can start hitting limits that didn't matter when the org was smaller.
Licence cost escalation. Salesforce licencing is per-user, per-month, and adds up fast. Enterprise edition, add-on clouds (Marketing, CPQ, Einstein), and AppExchange packages compound the cost. Many businesses are paying significantly more than they need to.
Upgrade and migration paths
Release management process. Establish a testing cadence: review release notes → identify impacted features → test in sandbox → validate integrations → approve for production. Assign release ownership to a specific person or team.
Edition optimisation. If you're on Enterprise or Unlimited edition but don't need all the features, consider whether Professional edition plus targeted customisation could reduce costs. Conversely, if you're on Professional and hitting limits, evaluate what Enterprise actually gives you.
AppExchange rationalisation. Audit all installed AppExchange packages. Are they all still used? Are they compatible with current API versions? Could any be replaced with standard Salesforce features or custom development?
Platform extension. Rather than building everything inside Salesforce, build external applications that connect via API. Customer portals, partner portals, complex reporting, and high-volume data processing often work better as separate applications — and don't cost per Salesforce user licence.
Customisation & integration challenges
Apex code debt. Mature Salesforce orgs accumulate Apex triggers, classes, and batch processes written by different developers over years. Common problems: overlapping triggers, unused code, hardcoded IDs, missing test coverage, and deprecated API references.
Flow governance. Salesforce Flow has become very powerful, which means Flows can now be as complex (and as fragile) as Apex code. Without governance — naming conventions, documentation, version control, testing — Flow automations become a maintenance nightmare.
Integration sprawl. Each integration point adds maintenance overhead:
- AppExchange packages: Managed packages that need version compatibility with each release
- Custom API integrations: Connections to ERP, marketing tools, accounting, etc.
- Middleware (MuleSoft, Zapier, etc.): Integration platforms that are themselves platforms to manage
- Data sync tools: Bi-directional sync between Salesforce and other systems
Data model complexity. Custom objects, custom fields, and relationships proliferate over time. Without a data architect reviewing the model periodically, the schema becomes increasingly messy and queries become slower.
Risks and decision points
Key risks
- Apex code quality
Untested, undocumented Apex is a liability during every release.
- Flow sprawl
Ungoverned Flows create the same problems as ungoverned code.
- Integration dependencies
Each integration is a potential point of failure during releases.
- Licence waste
Per-user costs add up. Regular audits prevent overspend.
- Vendor lock-in
The more you build in Salesforce, the harder it is to leave.
How HELLO PEOPLE can help
- Integration development: Build robust API integrations between Salesforce and your ERP, accounting, and marketing systems
- External applications: Build portals, dashboards, and tools that use Salesforce data without needing Salesforce licences
- Automation: Complex workflow automation that exceeds Flow's capabilities or needs to span multiple systems
- Licence optimisation: Audit usage and identify opportunities to reduce Salesforce spend
- AppExchange replacement: Build custom replacements for expensive AppExchange packages where it makes financial sense
Frequently asked questions
How often does Salesforce release updates?
Three major releases per year (Spring, Summer, Winter), plus continuous patches. Each release can introduce new features, deprecate old ones, and change API behaviour. You get a sandbox preview period, but the releases roll to production on Salesforce's schedule.
What happens to our Apex code during upgrades?
Apex governor limits, API versions, and platform behaviour can change between releases. Well-written Apex usually survives, but code that relies on deprecated APIs, hits governor limits, or uses undocumented behaviour can break. Test in sandbox before every release.
Is Salesforce too expensive for the value we're getting?
It depends on what you're using. If you're paying Enterprise or Unlimited prices but only using basic CRM features, you're likely overpaying. Conversely, if you're using the full platform (Apex, Flow, custom objects, integrations), the value is usually there. A licence audit can identify waste.
Should we use Salesforce Flow or custom Apex?
Flow for straightforward automation and business logic that non-developers should be able to modify. Apex for complex logic, high-volume processing, and integrations that need precise control. Most environments use both. The mistake is using Apex for simple things or Flow for complex things.
Can you help us reduce our Salesforce spend?
We can help in two ways. First, by auditing your licences and usage to find waste. Second, by replacing expensive Salesforce add-ons with custom-built alternatives where appropriate — some AppExchange packages add thousands per month when a custom solution would cost a one-time development fee.
Key takeaways
- Three releases per year — you need a structured testing process, not ad-hoc firefighting
- Apex code using deprecated API versions is a ticking clock. Stay within 2 versions of current.
- Flow is powerful but creates technical debt if ungoverned. Document and version-control your Flows.
- Integration sprawl is the biggest silent cost. Every AppExchange package and connected system adds maintenance.
- Don't build in Salesforce what's better built outside it. Portals, reporting, and complex integrations often work better as separate applications.