A Salesforce integration costs what its data flows demand. The biggest drivers are how many systems connect, which way data moves and in what volume, how fresh it must be, whether you use middleware or direct connections, how clean the source data is, and how failures get caught and fixed. Testing and ongoing monitoring are part of the price too. To get an accurate quote, describe each flow in writing before asking anyone for a number.
Price the flows, not the systems
Buyers often describe an integration as a pair of logos: Salesforce and the ERP, Salesforce and the billing platform. A partner cannot price that. What it can price is a list of flows, where each flow is one kind of record moving one way on one schedule. "Customers to the ERP when an opportunity closes" is a flow. "Invoice status back to Salesforce every hour" is another.
Two systems can easily produce a dozen flows, and each one carries its own mapping, transformation rules, error cases and tests. Counting flows is the single most useful thing you can do before a scoping call, because it turns a vague project into units of work a partner can estimate and you can compare across proposals.
The main cost drivers
| Driver | Raises effort | Lowers effort |
|---|---|---|
| Number of systems | Several systems exchanging overlapping records, each with its own owner | One or two systems with a clear, stable purpose |
| Direction | Two-way sync of the same fields, with rules for which edit wins | One-way flows where each field has a single system of record |
| Volume | Large initial loads, high daily counts, sharp peaks at month end | Modest, steady record counts that fit comfortably in scheduled jobs |
| Timing | Near-instant updates that users wait on | Hourly or nightly batches the business has agreed are fresh enough |
| Connection method | Custom code against a poorly documented or older API | A modern, documented API, an existing connector or middleware already in place |
| Data quality | Duplicates, missing IDs and inconsistent codes in either system | Shared identifiers and agreed values cleaned up before build |
| Error handling | Automatic retries, error queues, alerts and a resend tool | Simple logging where a failed record can wait for the next run |
| Testing | Many edge cases, full-volume tests and several teams to coordinate | A small set of scenarios and a sandbox on both sides |
| Monitoring | Business-critical flows that need watching every day | Low-impact flows checked on a routine schedule |
Direction, volume and timing
A one-way flow has one set of mappings and one place where errors surface. Make it two-way and you need conflict rules, loop prevention so an update does not bounce back and forth, and tests for both sides editing the same record at once. That is why two-way sync of a shared field is usually the most expensive line in any integration estimate.
Volume changes the method, not just the runtime. Salesforce's integration pattern guidance treats request-and-reply calls as suited to small, real-time exchanges, and points larger data operations toward Bulk API 2.0 and scheduled synchronization. Your org also has a daily allocation of inbound API requests shared by every connected system, so a chatty design can collide with the integrations you already run.
Real time is the driver buyers most often ask for and least often need. A rep checking credit before quoting may need an answer in seconds. A finance report on invoice aging almost never does. For each flow, ask the business how old the data may be, in minutes, hours or days, and let that answer set the timing.
Middleware or point-to-point
A direct connection is cheaper to start: no platform to license or stand up, and fewer moving parts. It is often the right call for a single, well-bounded job. One of our clients, a payment-processing ISO, connected Salesforce to its payment processor through a custom API integration that submits merchant applications for underwriting and captures the merchant ID that comes back. One purpose, one partner system, one owner.
Middleware, such as MuleSoft, costs more up front but spreads that cost across every flow it carries. Transformation, queuing, retries and monitoring are built once and reused. The break-even point arrives when a third or fourth system joins, or when the same record has to reach several destinations. If a proposal recommends a platform for one simple flow, or direct code for six systems, ask for the reasoning in writing.
The costs buyers miss
Most integration overruns come from work nobody put in the original estimate. Look for these in every proposal:
- Data preparation: matching existing records across systems and adding external ID fields before the first sync, so updates land on the right record.
- The other side of the connection: access, credentials, sandbox copies and developer time from whoever owns the ERP, billing or warehouse system.
- Security setup: a purpose-built integration login scoped to the objects and fields each flow touches, not borrowed admin credentials.
- Error handling you can operate: an error queue, an alert to a named person, and a way for that person to correct and resend a record.
- Full-volume testing: a run that matches your busiest day, not only a handful of hand-picked records.
- Cutover: the initial load, a reconciliation of totals between systems, and a plan for records created during the switch.
- Documentation and handover: field mappings, schedules, error codes and who to call, written down before the project team leaves.
Ongoing costs after go-live
An integration is never finished. Salesforce ships three major releases a year, the systems on the other side upgrade on their own calendars, and business changes add fields and record types that must flow through. Budget for someone to watch error queues and job results, investigate failures, and adjust mappings when either side changes. Middleware licensing, if you use it, recurs as well.
Decide who owns this before launch. Some companies keep it with an internal developer; others fold integration monitoring into a managed services agreement so the same team that built the flows responds when they fail. Either works, as long as a named person receives the alerts.
Writing a scope partners can price
A partner can only price what you can describe. Before requesting proposals, write a one-page brief for each flow with the following:
- The record type, the source system, the destination and the event or schedule that triggers it.
- Typical and peak daily volumes, plus the size of any historical load.
- How fresh the data must be, stated as a time the business agrees to.
- Which system owns each field, and what happens if both sides change it.
- How each system can be reached: API documentation, existing connectors, middleware already licensed.
- Known data problems, such as duplicates or records without a shared identifier.
- Who should hear about a failure and how quickly, and who will own monitoring after go-live.
Ask each partner to return the same list with assumptions attached, so you can see where one quote is higher because it includes error handling or full-volume testing and another is lower because it leaves them out. If you cannot answer half of these questions yet, a short paid discovery is a better first step than a fixed price. Abstrakt has been a Salesforce Consulting Partner since 2017, and our U.S.-based team scopes integrations flow by flow for exactly this reason.
