Use these 25 questions when evaluating a Salesforce consulting partner before an integration project, organized into seven categories and scored 0 to 3 per question. Each question comes with the red flag answer that should worry you, and the scorecard at the end summarizes all 25.
A Salesforce consulting partner configures the platform; a Salesforce integration partner designs and operates the data flows between Salesforce and everything else, and most firms claim both.
The questions with the highest signal are about who the architect is, which integration pattern the partner defaults to, and how they price uncertainty. The stakes are measurable: 26% of IT projects were delivered late in the past 12 months, and IT teams spend 36% of their time on custom integrations.
These questions can be used in early calls, ask for artifacts rather than answers, and add up the score before you sign the statement of work.
How to Use These 25 Questions
These are the questions to ask a Salesforce consulting partner in the shortlist stage, not after the proposal lands. The same questions to ask apply whether the firm calls itself a consulting partner, an implementation partner, or a system integrator. A proposal is a marketing document. The answers to these questions are evidence, and the firm-level rubric we use when shortlisting is a separate exercise from the project-level diligence below.
Score every question from 0 to 3. Twenty-five questions gives a maximum of 75 points. As a starting threshold, treat 55 and above as strong, 40 to 55 as proceed with conditions written into the SOW, and below 40 as a partner you should not sign for an integration project of any size.
| Score | Meaning |
|---|---|
| 0 | No answer, deflection, or a red-flag answer |
| 1 | Generic answer that could apply to any project |
| 2 | Specific answer tied to your systems and constraints |
| 3 | Specific answer backed by an artifact: a diagram, a runbook, a named reference |
The scoring only works if you ask for artifacts. A Salesforce consulting partner who can talk about API governance but cannot show you a naming convention document has not done it recently. This is the same logic behind the capabilities an integration consultant should hold in 2026: the evidence matters more than the claim.
Why Integration Evaluation Is Different in 2026
Three things changed. First, AI agents now depend on integration architecture and integration quality. 88% of organizations are moving toward agentic transformation, 86% of IT leaders say agents without proper integration add complexity rather than value, and half of all AI agents currently operate in silos. The integration project you scope this year is the data layer your agents run on next year, which is why what MuleSoft shipped for agent connectivity this year belongs in a partner evaluation.
Second, build-and-leave no longer works. Salesforce ships three major releases a year, upstream systems change their schemas, and the average enterprise runs close to 1,000 applications. Every one of those is a reason an integration that worked in May breaks in June. A Salesforce implementation partner who prices go-live as the finish line is pricing the wrong project, and why centralized governance cuts ongoing integration effort is the counterargument they should be making to you.
Third, the partner market is crowded with generalist practices. Most system integrators now have a Salesforce team and a MuleSoft team, and many staff both with people who learned the platform on the last project. The questions to ask below are designed to separate a Salesforce integration partner with production scars from a firm that has a logo on a partner page. Incepta’s own enterprise architecture practice sees the difference most often in the handoff, not the pitch.
Architecture and Pattern Questions (Q1 to Q5)
This is the highest-weight category of questions to ask a Salesforce consulting partner. If a partner scores poorly here, the red flags compound and nothing in the commercial section fixes it.
A Salesforce consulting partner’s default integration architecture tells you what your system will look like in 24 months, and how an architecture review surfaces system-of-record gaps before build is the best predictor of whether they have thought about that horizon.
Q1. What integration pattern will you default to for our project, and when would you not use it?
Point-to-point integration connects two systems directly and is the most common integration architecture in orgs that grew without a plan. It works for one or two connections and collapses at scale: five systems create 10 unique connections, ten systems create 45, each with its own error handling and monitoring.
API-led connectivity, the three-layer model of System, Process, and Experience APIs, builds each connection once and reuses it, and API-led reuse is what keeps the fifth integration project cheaper than the first. 58% of IT leaders had adopted an API-led strategy as of the 2025 benchmark, so a partner without a view on it is behind the market. Incepta’s MuleSoft consulting practice treats the pattern choice as the first design decision, not a later refactor.
The answer that should worry you: point-to-point with no discussion of scale, or “API-led” recited without an explanation of what each of the three layers does for your project.
Q2. How do you handle idempotency, retries, and failed messages?
Every integration fails in production eventually. The question is whether a failed order creates a duplicate, disappears, or lands in a dead-letter queue where someone can see it. Idempotency means a retried message produces the same result as the first attempt. Retry logic with backoff and a dead-letter queue is the baseline for any flow that touches revenue, and the MuleSoft platform assessment exists in part to find flows that skipped it.
Ask for: a sample error-handling design or a diagram showing where failed messages go.
The answer that should worry you: “we log the error.”
Q3. Describe a production integration you operated that resembles ours
The word that matters is “operated.” Many partners can describe a build. Fewer can describe the third month of production, when volumes spiked, an upstream API changed, and someone had to fix it at 2 a.m. Ask for the same ERP or data platform you run, because SAP through OData behaves nothing like NetSuite through SuiteTalk, and the SAP integration work Incepta delivered for a global apparel enterprise is the kind of reference you want in specific, not general, terms.
The answer that should worry you: a demo environment offered in place of a production reference.
Q4. What is your API governance model, and how does it prevent sprawl?
API governance covers naming conventions, versioning policy, a reuse catalog, and the review step that stops a developer from building a fourth customer API when three already exist. Without it, you get integration sprawl that costs more to maintain than it did to build. A Salesforce consulting partner who has done this can show you the documents. The iPaaS comparison guide explains how the major platforms enforce governance differently, but the partner’s process matters more than the platform feature.
The answer that should worry you: governance is “handled by the platform.”
Q5. Show me the target architecture diagram you would produce for us in week one
A good partner already has a view of your architecture before the first line of code. They ask about identity, the integration layer, ERP, billing, data platforms, and observability. A weak partner draws Salesforce in the middle and arrows going out. The Salesforce assessment journey produces exactly this integration architecture diagram as a deliverable, which is a useful comparison for what “week one” should look like.
The answer that should worry you: a Salesforce-only diagram with no clarity on which system is the system of record for customer, product, and order.
Platform Selection Questions (Q6 to Q8)
An integration platform as a service (iPaaS) is a managed cloud platform for building and running integrations. MuleSoft, Boomi, Workato, and SnapLogic are the four most common in Salesforce environments. Middleware is the broader category that includes self-hosted enterprise service buses, and custom code means Apex callouts or bespoke services. The label matters less than the reason a Salesforce consulting partner gives for the recommendation, which is why how the four major platforms differ by workload is a better reference than any vendor comparison sheet.
Q6. Which platform are you recommending, and what in our requirements drove that?
The recommendation should trace back to your requirements: connection count, volume, on-premises systems, API management needs, and who will maintain it. A Salesforce implementation partner with a single certification will recommend that platform regardless of fit, and a firm that has implemented both explains where each fits in a way a single-platform shop cannot.
The answer that should worry you: the recommendation matches the only platform the partner is certified on.
Q7. Tell me about a project where you advised against your preferred platform
This is a trust question. A Salesforce implementation partner who has never told a client that MuleSoft is more than they need, or that Workato will not scale to their volume, is selling rather than advising. The Workato versus MuleSoft comparison lays out the cases where each loses, which is the kind of honesty you are testing for.
The answer that should worry you: the partner cannot name one.
Q8. Have you modeled platform licensing inside the proposal?
iPaaS licensing depends on API call volume, runtime environments, and add-ons, and it can exceed the consulting fee over three years. A partner who models it during scoping is protecting you from a budget surprise in month four. Incepta’s MuleSoft license management service exists because this modeling is routinely skipped.
The answer that should worry you: licensing is “the vendor’s conversation.”
Team and Delivery Questions (Q9 to Q12)
The people in the sales meeting are rarely the people who build the integration project. These four questions to ask close that gap, and the red flags here are the easiest to miss, and the staffing model where engineers sit inside the client’s operating rhythm is one benchmark for what continuity looks like.
Q9. Who is the architect on this engagement, by name, and how many hours per week are they on it?
The architect makes the decisions that determine whether your integration layer is maintainable. If that person is spread across six accounts, your project gets a junior developer’s architecture with a senior name on the slide. Ask for the name and the allocation. The engagement models compared, from freelancer to full partner show how architect access varies by model.
The answer that should worry you: “a senior architect will oversee the project.”
Q10. Which of the people in this room will be on the project at go-live, and is any work subcontracted?
Team continuity is where integration projects quietly fail. The developer who built the DataWeave transformations leaves, and the runbook was never written. Subcontracting adds a second layer of the same risk. A partner that commits named people through go-live and post-launch support is a partner you can hold accountable, and Incepta’s integration services team is structured around that commitment.
The answer that should worry you: the partner cannot commit to continuity or is vague about who does the work.
Q11. Walk me through your first two weeks
The first two weeks should be a discovery phase: system inventory, data ownership, volumes, existing integrations and their failure history. A partner that opens sprint one with build tasks is guessing at your requirements. What a real discovery phase produces before any build starts is documented step by step.
The answer that should worry you: sprint one starts building before discovery closes.
Q12. What is your typical time to first working API in a client environment?
Time to first working API is a proxy for delivery discipline. A partner with a repeatable model can give you a number in days. A partner without one gives you a range in months. Incepta’s structured MuleSoft onboarding program exists to make that number predictable.
The answer that should worry you: no number.
Commercial and Statement of Work Questions (Q13 to Q15)
The SOW is where every earlier answer from a Salesforce consulting partner either gets written down or evaporates. A statement of work for a Salesforce integration project should specify deliverables, environments, the discovery phase, acceptance criteria, change order terms, and post-go-live scope. The pricing model reveals how honest the partner is about uncertainty, and a scoped assessment that turns an undocumented org into a priced plan is the alternative to guessing.
| Pricing model | Who carries scope risk | When it fits | What to ask for |
|---|---|---|---|
| Fixed-price | Partner | Scoped, documented org after discovery | The discovery output the price is based on |
| Time and materials (T&M) | You | Exploratory work, undocumented org | Weekly burn reports and a not-to-exceed figure |
| Capped T&M | Shared | First integration with partial documentation | The cap, and what triggers a change order |
Q13. Fixed-price, T&M, or capped T&M, and why for a first integration?
Fixed-price transfers scope risk to the Salesforce consulting partner and only works if discovery was real. Time and materials transfers it to you. Capped T&M splits it. For a first integration project on an org nobody has documented, the honest answer is usually a fixed-price discovery followed by a capped build. Fixed-price scoped proposals are the norm among the firms worth shortlisting for MuleSoft work.
The answer that should worry you: uncapped T&M on an undocumented org, or fixed-price with no discovery phase.
Q14. What triggers a change order, and what is your change order rate on similar projects?
A change order is a formal scope amendment with a cost attached. Every project has them. The partner’s change order rate on comparable projects tells you how accurate their scoping is, and the triggers tell you how they define scope creep versus discovery. Incepta’s digital transformation engagements track this figure because it is the clearest measure of scoping quality.
The answer that should worry you: “we rarely need them.”
Q15. How do you price the uncertainty of an org nobody has documented?
A quote produced without discovery questions about your org is a guess with a dollar sign. Ask what the partner assumed about your data quality, your existing integrations, and your automation volume. The platform assessment ROI calculator shows how much that uncertainty is worth pricing before build.
The answer that should worry you: a quote that arrived before any discovery questions did.
Data, AI, and Regulatory Readiness Questions (Q16 to Q19)
Data quality is the largest single risk in a Salesforce integration project, and it is the category where a Salesforce implementation partner most often gives a confident answer with nothing behind it. 80% of organizations name data silos as the top barrier to their automation and AI goals, and 95% of IT leaders report difficulty connecting AI to existing systems. What to fix in your data layer before an AI project starts before the integration build, not after.
Q16. Do you run a data readiness phase before build, and what does it produce?
A data readiness phase profiles the source systems, identifies duplicates and mismatched fields, and defines who owns each data domain. Its output is a document, not a promise. This applies whether you run one Salesforce cloud or five, because Sales Cloud, Service Cloud, and Data 360 each carry their own data model. Incepta’s data management practice treats this as a gate before any integration work begins.
The answer that should worry you: data quality is “a migration task.”
Q17. Will the APIs you build be consumable by AI agents?
An agent-ready API is well-documented, tightly permissioned, and exposed through a protocol that agents can call, such as the Model Context Protocol (MCP) or MuleSoft Agent Fabric. Even if you have no AI project today, an integration layer built this year without agent consumption in mind gets rebuilt in two. How agents reach data outside Salesforce explains the mechanism, and the capability tests that separate agent builders from agent demos cover the deeper Agentforce evaluation.
The answer that should worry you: agents are “a phase two conversation.”
Q18. How do you handle data residency, audit logging, and access controls for our jurisdiction and regulator?
The right answer to this question begins with a question back: which regulator, which region, and which data classes. A Salesforce consulting partner who answers before asking is answering from a template. Data residency rules, runtime region selection, log retention, and least-privilege access differ by jurisdiction, and Incepta’s API security practice starts every engagement by establishing which rules apply.
The answer that should worry you: “the platform is compliant.”
Q19. If our existing org is degraded, what evidence would rule out remediation before you propose a rebuild?
Remediation repairs what exists. Re-implementation replaces it. The firm proposing a rebuild is the firm that gets paid for one, so ask what evidence ruled out repair. Automation volume, custom code coverage, and data model integrity usually decide it, and an independent Salesforce platform assessment should produce that evidence before any vendor proposes either path.
The answer that should worry you: a rebuild proposed before an assessment.
Operations and Handoff Questions (Q20 to Q23)
Support and managed operations both get called “post-go-live support” in proposals, and post-go-live is where a Salesforce consulting partner earns or loses the reference you will give them. Support responds to tickets. Managed operations monitors, alerts, and owns mean time to resolution. Ask which one you are buying for your integration project, because what round-the-clock monitoring coverage looks like in practice is very different from a help desk email address.
Q20. What is your mean time to resolution for a production integration failure, and is monitoring 24/7 or business hours?
Mean time to resolution (MTTR) is the number that tells you whether a failed order sync is a 20-minute problem or a two-day one. Business-hours monitoring means a Friday night failure is a Monday morning discovery. A Salesforce integration partner that operates integrations can quote an MTTR from their own data. Incepta’s enterprise integration service publishes monitoring coverage as part of every SOW.
The answer that should worry you: no MTTR figure.
Q21. How do you hand off: runbooks, documentation, training cadence?
A runbook is the document your team opens when an integration fails at 3 a.m. and the partner is not on the phone. If it does not exist, the original developer is the runbook, and the original developer has left. Ask to see a sample runbook from a previous engagement. Incepta’s MuleSoft training and certification programs exist so that internal teams can operate what the partner built.
The answer that should worry you: “the documentation is in the code.”
Q22. What happens to our integrations at the next Salesforce release?
Salesforce releases three times a year. Each release can change API behavior, deprecate endpoints, or alter field-level defaults. A partner with an operating model tests integrations in a sandbox against the preview release before it hits production. A partner without one finds out when you do. The CloudHub 2.0 migration guidance shows the same discipline applied to runtime upgrades.
The answer that should worry you: no release-testing process.
Q23. Can we operate this without you?
This is the exit question, and the answer reveals the partner’s business model. A partner confident in their handoff says yes and describes the training cadence. A partner whose revenue depends on your dependency hesitates. Incepta’s Forward Deployed Engineering model is built to make itself optional over time.
The answer that should worry you: any hesitation.
The Questions a Good Partner Asks You (Q24 to Q25)
The best Salesforce consulting partner in your shortlist is often identifiable by what they asked, not what they answered. Two final questions to ask flip the lens, and a structured read on an existing MuleSoft estate is one example of what a partner who asks the right questions produces.
Q24. What did you ask us that no other partner asked?
A partner who has scoped integration projects before asks about things a generalist skips: peak transaction volumes, the failure history of your existing integrations, who owns the customer data model, and which downstream reports break when a field changes. If every partner asked the same questions, none of them has done this at your scale. Incepta’s Customer 360 practice starts from the data ownership question for exactly this reason.
Q25. What would you need from us in the first two weeks?
The answer should be specific: sandbox access, a system inventory, named data owners, sample payloads, and the person who can approve a change to the data model. A partner who needs nothing from you is planning to build without you. The MuleSoft security assessment request list is a useful template for what a structured partner asks for.
Before you sign, a competent Salesforce consulting partner should also have asked about your system inventory, data ownership, volumes and peaks, existing integrations and their failure history, and your regulator and region. If none of those came up, the proposal in front of you is priced on assumptions, and the five converting jobs (consolidation, extension, integration, remediation, AI-enablement) are a useful frame for which assumptions matter most.
Red-Flag Summary and Scorecard
Use this scorecard in the room. The high-weight rows are the ones where a zero red flag should end the conversation, and Incepta’s Salesforce integration services page shows how these answers translate into a scoped integration project.
| # | Question | Category | The answer that should worry you | Weight |
|---|---|---|---|---|
| 1 | Default integration pattern | Architecture | Point-to-point, or API-led with no explanation | High |
| 2 | Idempotency, retries, failed messages | Architecture | “We log the error” | High |
| 3 | Production reference like ours | Architecture | A demo instead of a reference | Med |
| 4 | API governance model | Architecture | “Handled by the platform” | Med |
| 5 | Week-one architecture diagram | Architecture | Salesforce-only diagram | Med |
| 6 | Platform recommendation rationale | Platform | Matches their only certification | Med |
| 7 | Advised against preferred platform | Platform | Cannot name one | Med |
| 8 | Licensing modeled in proposal | Platform | “The vendor’s conversation” | Med |
| 9 | Named architect and hours | Team | “A senior architect will oversee” | High |
| 10 | Continuity and subcontracting | Team | No commitment | Med |
| 11 | First two weeks | Team | Build starts before discovery closes | Med |
| 12 | Time to first working API | Team | No number | Med |
| 13 | Pricing model rationale | Commercial | Uncapped T&M, or fixed-price with no discovery | High |
| 14 | Change order triggers and rate | Commercial | “We rarely need them” | Med |
| 15 | Pricing uncertainty | Commercial | Quote before discovery questions | Med |
| 16 | Data readiness phase | Data and AI | “A migration task” | Med |
| 17 | Agent-ready APIs | Data and AI | “Phase two” | Med |
| 18 | Residency, logging, access | Data and AI | “The platform is compliant” | Med |
| 19 | Evidence ruling out remediation | Data and AI | Rebuild proposed before assessment | High |
| 20 | MTTR and monitoring hours | Operations | No MTTR figure | Med |
| 21 | Runbooks and handoff | Operations | “Documentation is in the code” | Med |
| 22 | Next Salesforce release | Operations | No release-testing process | Med |
| 23 | Operate without you | Operations | Hesitation | Med |
| 24 | What did you ask that others did not | Mirror | Same questions as everyone else | Med |
| 25 | What you need from us | Mirror | Nothing | Med |
Get a Second Set of Eyes on the Proposals You Already Have
If the proposals in front of you were priced before anyone asked about your data, your volumes, or your existing integrations, the numbers are assumptions. A platform assessment replaces the assumptions with evidence before the integration project starts.
- Maps your existing integrations, their failure history, and the system-of-record gaps a rebuild proposal may be hiding
- Produces the week-one architecture diagram and the discovery outputs that make fixed-price scoping honest
- Gives you the evidence to score Questions 5, 15, and 19 before a partner answers them
Have the proposals in front of you reviewed against your actual org, or talk to the Incepta team about the integration project you are scoping.
Frequently Asked Questions
What is the difference between a Salesforce consulting partner and a Salesforce integration partner?
A Salesforce consulting partner configures and customizes the platform itself: Flows, Apex, page layouts, permission sets. A Salesforce integration partner designs, builds, and operates the data flows between Salesforce and every other system. Most firms claim both. The questions in this article test whether the integration half is real, and the capabilities an integration consultant should hold is the companion reference.
Should I hire separate firms for Salesforce configuration and integration?
In most cases, no. Separate firms create duplicated discovery, coordination overhead, and accountability gaps when an issue spans both domains. A single team that delivers Salesforce and integration under one engagement keeps design decisions aligned across the stack and removes the question of whose fault a broken sync is.
How many of these 25 questions should a partner answer well before I proceed?
Use the 0 to 3 score. A total above 55 out of 75 is a strong partner. A total between 40 and 55 means proceed with the weak answers written into the SOW as conditions. Below 40, do not proceed. Any zero on a high-weight question (1, 2, 9, 13, or 19) should trigger a second conversation before the score matters, and the firm-level shortlist rubric is a separate filter.
Is a partner with only one iPaaS certification disqualified?
Not automatically, but their platform recommendation should be treated as a starting point rather than advice. A single-platform partner cannot tell you when their platform is the wrong fit. If your project clearly needs that platform, the risk is low. If the fit is uncertain, firms worth shortlisting for MuleSoft work include several with multi-platform certification.
What is a reasonable time to first working API?
For a partner with a repeatable delivery model and a client environment that is ready, a first working System API in a sandbox should take days, not weeks. The number depends on access, data readiness, and the complexity of the source system. Incepta’s structured onboarding model for MuleSoft is designed to make the number predictable rather than aspirational.
How do I check a partner’s references for integration projects specifically?
Ask the reference three questions: what broke in production after go-live, how long it took the partner to fix it, and whether the runbook was accurate. Generic references confirm the partner is pleasant to work with. Integration references confirm they can operate what they build, which is the standard behind Incepta’s published success stories.
Do I need to ask about AI agents if we have no AI project planned?
Yes. The integration layer you build now is the data access layer any future agent will use. APIs that are documented, permissioned, and exposed through an agent-callable protocol cost little extra to build today and avoid a rebuild later. How Agentforce and MuleSoft work together explains what “agent-ready” means in practice.
What should be in the SOW before I sign?
At minimum: a defined discovery phase with its outputs, named team members and their allocation, the integration pattern and platform with rationale, acceptance criteria per integration, change order terms, monitoring coverage and MTTR commitments, and the handoff deliverables. The engagement models and cost structures worth comparing before the SOW stage are covered separately
