The Salesforce Ecosystem: Partners, ISVs, and Building Your Support Network

The Partner Ecosystem Landscape

The Salesforce partner ecosystem has several distinct segments, each serving different purposes and requiring different selection criteria.

Global System Integrators (GSIs) — Accenture, Deloitte, Capgemini, IBM, Infosys — offer large teams, global delivery capabilities, and broad Salesforce practice depth. They are appropriate for enterprise-scale programmes, multi-cloud deployments, and organisations that need a single accountable delivery partner across multiple workstreams. The trade-off: GSIs are expensive, hierarchical, and often deploy less experienced staff on delivery work after the account team wins the engagement. Governance of the actual resource mix is critical.

Boutique Salesforce specialists — mid-size firms (100-500 employees) with deep Salesforce expertise but narrower industry or product specialisation. Often deliver more experienced consultants at a lower blended rate than GSIs. Appropriate for focused implementations (Sales Cloud, Service Cloud, a specific cloud) where industry-specific knowledge is more important than breadth. The trade-off: capacity constraints — they may not have surge capacity for large programmes and may be absorbed by competing priorities.

Salesforce direct professional services — Salesforce's own delivery capability, accessed through Success Plans or project-based engagements. Deepest product knowledge; limited by availability and by the nature of Salesforce's conflict with its partner channel. Useful for complex technical challenges (Hyperforce migrations, Data Cloud implementations) where product knowledge is the primary requirement.

Independent Salesforce Contractors — individual consultants or small firms. High expertise, high flexibility, highest delivery risk on large programmes due to limited bench depth and contractual fragility. Appropriate for specific roles (an architect or technical lead supplementing an in-house team) rather than as primary delivery partners.

Five Criteria for Selecting Implementation Partners

1. Relevant experience. Has the partner delivered a comparable engagement — similar size, similar industry, similar Salesforce products — in the last 24 months? Ask for three client references and call them. Ask specifically: what went wrong, how did the partner respond, and would you use them again? One "no" on the last question is disqualifying.

2. Named resource quality. Who specifically will be on your engagement? Request CVs for the lead architect, programme manager, and team lead. Verify certifications. Ask whether the proposed resources are currently available or whether they will be finishing other projects. A strong named team that rotates out mid-engagement is worse than a consistently adequate team that stays. Require named resource continuity clauses in contracts.

3. Knowledge transfer commitment. What is the partner's explicit plan to build your internal team's capability? Partners who create dependency rather than building capability are optimising for their own long-term revenue, not your organisational interests. Require a knowledge transfer workplan as a contract deliverable.

4. Governance model. How does the partner propose to manage scope, risk, and change? A partner who says "we'll work agile and sort it out" without a clear governance framework will be very difficult to hold accountable. Require a written programme governance document as part of the statement of work.

5. Commercial model transparency. Fixed-price contracts shift delivery risk to the partner but incentivise scope gaming. Time-and-materials contracts shift risk to the customer but require strong internal governance to prevent scope creep. Hybrid models (fixed-price phases with T&M for change requests) require clear scope documentation upfront. Understand which model the partner is proposing and why, and negotiate appropriately.

ISV Evaluation: The AppExchange Decision Framework

The AppExchange has over 7,000 applications. The average enterprise Salesforce org has 20-40 AppExchange packages installed. Many of those packages are underused, not supported, or creating technical debt. ISV selection discipline prevents AppExchange sprawl.

Four factors determine whether an AppExchange product should be installed:

1. Functional fit. Does the ISV product solve the specific problem better than custom development or native Salesforce configuration? If the gap between what Salesforce provides natively and what the business needs is small, the overhead of managing an AppExchange dependency (upgrades, compatibility, vendor relationship) may not be justified.

2. ISV stability. How large and financially stable is the ISV? Check their funding history, their customer list, and their Salesforce AppExchange listing age. A startup ISV with 50 customers and seed funding is a meaningful business continuity risk for a core capability. For mission-critical functionality, prefer ISVs with 3+ years on AppExchange, 500+ customers, and clear revenue sustainability.

3. Managed package architecture. Is the package well-architected? Does it create excessive custom objects, Governor Limit pressure, or hard dependencies on Salesforce internals that could break with platform updates? Request a technical architecture review from your Salesforce architect before installing any managed package in production. The AppExchange security review assesses security, not architecture quality.

4. Exit strategy. If the ISV is acquired, pivots, or shuts down, how dependent are you on their product? For deeply embedded ISV products, understand what data is stored in managed objects (which you cannot access if the package is removed) and what the migration path is to native Salesforce functionality or an alternative.

Building a Healthy Multi-Partner Model

Large Salesforce programmes often involve multiple partners — an SI delivering the implementation, an ISV providing specialised functionality, Salesforce Professional Services advising on architecture, and potentially a managed service provider running BAU operations post-go-live. Managing these relationships requires deliberate design.

Designate a primary accountable partner for each workstream — avoid situations where two partners share accountability for the same outcome, as this reliably results in each blaming the other when problems arise. Define the interfaces between partner workstreams explicitly: who is responsible for integration testing between the SI's Salesforce work and the ISV's managed package? Who owns the architecture decision when there is a conflict between the SI's approach and the ISV's recommendation?

Maintain an internal Salesforce architect role — even if it is a single person — who is not employed by any partner. This person's job is to make architectural decisions that are in your organisation's interest, not in the partner's interest. Without this internal capability, architectural decisions will default to whatever the primary SI recommends, which may or may not align with your long-term platform goals.

Managing Partner Transitions

The decision to change implementation partner mid-programme or at programme completion is one of the most disruptive events in a Salesforce programme. Managing it well requires preparation before the transition, not just good intentions during it.

Every engagement with a delivery partner should include documentation requirements that assume the partner will be replaced: comprehensive technical documentation of all custom development, data dictionary for all custom objects and fields, a runbook for deployment processes, and handover documentation for any integrations. These requirements should be in the contract as deliverables, not left as informal expectations.

For planned transitions (programme end, moving to a managed service model), allow 4-6 weeks of parallel running between the outgoing and incoming partner. For unplanned transitions (partner failure, contractual dispute), the documentation quality you required upfront determines how difficult the transition is. Organisations that required good documentation typically take 6-8 weeks to transition. Organisations that did not may take 6-8 months.