Salesforce Integration: A Practical Guide for 2026

What "integrating Salesforce" actually means

Salesforce rarely works alone. Leads come from the website, orders live in the ERP, invoices in accounting, tickets in a support tool. An integration moves that data, or the action behind it, between systems automatically.

Almost every Salesforce integration does one of three jobs:

• Data sync. Keep records such as accounts, contacts, products and orders the same in two systems.
• Process automation. One system's event starts work in another: a closed-won deal creates an invoice, a new ticket alerts the account owner.
• Showing data in place. Users see ERP orders or shipment status on the Salesforce account page without copying the data in.

Know which job you need before you compare tools. A tool that is great at copying records may be poor at real-time events, and the other way around.

Your four options, compared

Start with the simplest option that covers your data, volume and rules. Move up only when you hit a real limit.

ETL and data pipeline tools are a fifth, narrower option. They copy Salesforce data into a data warehouse for reporting, and some push modeled data back (reverse ETL). Use them for analytics, not for operational processes that need to happen in seconds.

Salesforce integration patterns, in plain words

Salesforce's Integration Patterns and Practices guide names six integration patterns (it calls the first two Remote Process Invocation, Request and Reply and Fire and Forget). Pick one per data flow; a real project usually mixes two or three.

A good rule: use events for things that happen (an order shipped), batches for things that are large (a full price list), and request and reply only when a person is waiting for the answer.

The Salesforce APIs and when to use each

Salesforce offers several APIs for the same data. The right one depends on volume, direction and how fast the other side needs to know.

One edition trap: according to Salesforce's documentation, API access is included in Enterprise, Unlimited, Performance and Developer editions. Professional Edition needs an API add-on bought from Salesforce, and many tools that call the API won't work without it.

The integration user and the Salesforce Integration license

Never run an integration under a real person's login. When that person leaves, the integration breaks, and every change it makes looks like their work.

Create a dedicated integration user instead. Salesforce provides a license type for exactly this:

• Salesforce Integration user license. API-only access: the user can call APIs but can't log in to the user interface. According to Salesforce, orgs in supported editions get a limited number of these licenses at no extra cost (Salesforce announced five per Enterprise, Unlimited and Performance org at launch), and more can be bought.
• Profile. The license comes with the Minimum Access - API Only Integrations profile, which replaced the older API Only System Integrations profile in new orgs. It grants almost nothing on its own, and its API-only restriction can't be switched off.
• Permission sets. Assign the Salesforce API Integration permission set license, then a permission set with only the objects and fields this integration needs. One user and one permission set per integration makes audits and troubleshooting much easier.

Some connectors need a full Salesforce license for their user, for example when they also run features inside the user interface. Check the connector's documentation before you assign licenses.

Security: external client apps and OAuth

Integrations authenticate through OAuth 2.0, set up in an app definition inside Salesforce. Two changes matter for anything you build in 2026:

• External client apps replace connected apps. Starting with the Spring '26 release, creating new connected apps is restricted by default; an org that still needs one has to ask Salesforce Support. Existing connected apps keep working, but Salesforce recommends external client apps for new integrations. Connected apps that come inside an installed vendor package still install.
• Password-based logins are on the way out. Salesforce is retiring the SOAP API login() call in the Summer '27 release (Spring '26 already switched it off by default in new orgs), and external client apps don't support the OAuth username-password flow. Integrations that store a username, password and security token need to move to OAuth.

For server-to-server integrations, use the JWT bearer flow (a certificate, no stored password) or the client credentials flow (runs as one assigned integration user). Use the authorization code (web server) flow when real people connect their own accounts, as with email and calendar tools. Limit the OAuth scopes, restrict which users can use the app, and keep secrets in a vault, not in code.

API limits: plan for them before go-live

Salesforce counts inbound API calls per org over a 24-hour period. According to Salesforce's documentation, an Enterprise Edition org gets 100,000 calls plus 1,000 per full Salesforce or Salesforce Platform license, and you can buy more. Every integration and connector shares that pool.

Salesforce lets a paid org go a little over the limit during an occasional spike, but past a hard cap calls fail with a REQUEST_LIMIT_EXCEEDED error. That can take every integration down at once. Keep usage well below the limit:

• Use Bulk API 2.0 for anything that moves thousands of records.
• Use events, not polling. Change Data Capture and Platform Events tell you what changed, so you don't ask every minute.
• Batch your writes. Composite and collection requests update many records in one call.
• Only sync what changed. Filter by last-modified date and skip unchanged values.
• Watch usage. API usage shows in Setup and through the REST API limits resource, and API Usage Notifications in Setup can email you at a set percentage. Alert at 70–80%, not at 100%.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

How to plan a Salesforce integration, step by step

These steps work for any integration, from a connector you install in an afternoon to a custom ERP sync.

1. Write down the business outcomeOne sentence per flow: "When a deal closes, finance gets an invoice within an hour without retyping anything." Flows without an outcome are the first to cut.
2. List the data and pick a system of recordFor each object, and for important fields, decide which system owns the truth. Salesforce may own the account name while the ERP owns the credit limit. Two owners for one field is how sync loops start.
3. Choose the pattern and timing for each flowReal time, near real time or nightly. Most teams ask for real time everywhere; most data is fine within minutes or overnight, and that is cheaper.
4. Pick the toolCheck AppExchange and the other vendor's connector first. Go to an iPaaS or custom code only for what the connector can't do. Confirm your edition has API access.
5. Set up the integration user and appA Salesforce Integration user license, a permission set with only the needed objects and fields, and an external client app with a server-to-server OAuth flow.
6. Map fields and valuesFill in a mapping sheet: field, type, direction, owner, transformation. Map picklist values one by one, and decide which external ID field links the records.
7. Clean data before the first syncMerge duplicates, fill required fields and fix bad picklist values in both systems. An integration copies your mess faster than people can.
8. Build and test in a sandboxUse a full or partial copy sandbox connected to the other system's test environment. Test creates, updates, deletes, bad data, the same message twice and the other system being down.
9. Load history, then switch onRun the initial load with Bulk API 2.0, check record counts on both sides, then turn on the live sync. Turn off old manual imports and duplicate automations the same day.
10. Monitor and own itName an owner, set alerts for failed records and API usage, and review the error log weekly for the first month.

Object mapping: who owns what

A typical starting point for a CRM-to-ERP or CRM-to-finance integration. Your ownership rules may differ; the point is to decide them in writing.

Common pitfalls and how to fix them

• Duplicates. The integration matches on name or email and creates a second record. Fix: store the other system's ID in an external ID field on the Salesforce record and upsert on it.
• Sync loops. System A updates B, B's update triggers a sync back to A, forever. Fix: one owner per field, skip updates made by the integration user, and only sync values that actually changed.
• Record ownership. Everything the integration creates belongs to the integration user, so sales reps can't see or own it. Fix: set the owner explicitly from assignment rules or a mapping table.
• Picklist mismatches. "CA" in one system, "California" in the other, and records fail validation. Fix: map every value in the mapping sheet and alert on unknown values instead of dropping them.
• Validation rules and automation. A new required field or Flow blocks integration writes overnight. Fix: include the integration in your release testing, and design automations so they handle records created by the integration.
• API limits. A full resync at month-end uses the day's pool. Fix: Bulk API 2.0 for large jobs, events instead of polling, and an alert on usage.
• Data that should not sync. Card numbers, health data, salaries or private notes end up in Salesforce because "all fields" was easier. Fix: sync only mapped fields, and get sign-off from whoever owns privacy and security.
• Silent failures. The sync stops and nobody notices for a week. Fix: error alerts to a named person, plus a daily count check between systems.

When a custom integration makes sense

Connectors and iPaaS cover most needs. Custom code on the Salesforce APIs earns its cost when:

• the other system is your own product, a legacy app or a database with no connector;
• the logic is specific to your business: pricing, approvals, multi-step order flows;
• volume or speed goes beyond what a connector or no-code plan handles at a sane price;
• the integration is a feature you sell to your own customers who use Salesforce.

A typical custom build includes an authentication setup through an external client app, a mapping and transformation layer, idempotent upserts on external IDs, an event listener or scheduled jobs, retries with a dead-letter queue, logging and alerts, and tests against a sandbox.

These ranges come from the API integration cost guide, which breaks down where the hours go. For warehouse and pipeline projects, see the cost of data integration.

Popular Salesforce integrations

Each of these has its own guide with the options, mapping and pitfalls for that pair of systems:

• HubSpot and Salesforce: the native connector, sync rules and how to stop duplicate contacts.
• Salesforce and QuickBooks: turning closed deals into invoices and bringing payment status back.
• Jira and Salesforce: linking cases to issues so support and engineering see the same status.
• Salesforce with Outlook and Gmail: email, calendar and activity logging options.
• Salesforce CTI: connecting a phone system for click-to-dial, screen pops and call logging, and planning the move off Open CTI before it retires in 2028.
• Salesforce with Slack and Microsoft Teams: deal alerts, record previews and approvals in chat.
• Salesforce and SAP: customers, materials, pricing and orders between CRM and ERP.
• Salesforce and NetSuite: quote-to-cash sync between sales and finance.
• Health Cloud and FHIR: connecting Salesforce Health Cloud to EHRs with healthcare data standards.

Go-live checklist

Tick what is already true for your integration. It shows how ready you are to switch the sync on in production.

FAQ

Where Gilzor fits

Gilzor's engineers can map the data flow, build the Salesforce integration and support it after launch, whether that means configuring a connector, extending an iPaaS flow or writing a custom integration on the Salesforce APIs. See Salesforce integration services for how that work is set up. Bring your list of systems and flows; the mapping work in this guide becomes the project scope.