October 29, 2025
Something changed that most guides on this topic have not caught up with. Informatica is now part of Salesforce. Its own site trades as "Informatica from Salesforce" and carries a Salesforce copyright. So a Salesforce integration built on Informatica is no longer a third-party bridge between two vendors. It is one vendor's data platform talking to another product in the same portfolio.
That matters less for the click path and more for how you plan. The platform is now called Informatica Data Management Cloud, or IDMC — the older name was IICS, and most tutorials still use it. Menus have moved. And every guide you will find online walks the same five steps: set up your environment, create a connection, pick source and target, build a sync task, watch the logs. Those steps are not wrong. They are just the easy part. The hard part starts after "Test Connection" succeeds, when someone asks why the nightly load created eleven thousand duplicate contacts, or why the org ran out of API calls at 2 p.m.
This guide covers the decisions those tutorials skip. How to authenticate without using a password. Which API to choose and at what row volume the answer changes. Where the Secure Agent should sit. Why upsert with an External ID prevents the duplicate problem. And how much of your daily API allocation a single sync task can consume. Read the API table before you build anything.
Informatica is a Salesforce company now. Three practical consequences follow.
Naming. The platform is IDMC. Documentation, licensing, and the console use it. Older material says IICS or just "Informatica Cloud." Carry both names in your internal notes so a search finds your runbook either way.
Roadmap direction. Salesforce is publishing joint architecture guidance with Informatica, aimed at grounding agentic features in trusted data. If your integration exists to feed AI features, that direction is worth tracking.
Commercial conversation. Your Informatica contract and your Salesforce contract now sit with the same parent. Whether that helps you at renewal is a question for your account team, but it is a question worth asking.
What has not changed is the engineering. The connector still authenticates against your org. It still consumes your API allocation. It still creates duplicates if you configure it carelessly. The acquisition does not soften any of that.
If you are choosing between Informatica and other integration platforms, our Salesforce integration services team maps the decision against volume and system count before recommending a tool.
Nearly every guide on this topic tells you to enter a Salesforce username, password, and security token. Three of the four leading pages do exactly that.
Do not follow them. Salesforce has been steadily restricting username-password flows, and even where the option still exists it is the weakest choice available. A password in a connection config is a password that outlives the person who set it.
Do this instead:
Create a dedicated integration user. Not a real person's login. A named integration account, so audit trails show which system acted.
Authenticate with OAuth through a connected app. Set it up in your org, scope the OAuth permissions to what the integration actually needs, and connect IDMC to that.
Scope the permission set narrowly. If the integration reads Accounts and writes Contacts, grant those. Do not grant Modify All Data because it was faster to configure.
Restrict by IP where you can. Lock the integration user to the ranges your Secure Agent uses.
Record the token expiry. Refresh tokens can be revoked or expire. If nobody owns that date, the integration fails silently on a Saturday.
Confirm the currently available authentication options against Salesforce's own documentation before you build, because this area keeps tightening. Ongoing user and permission hygiene sits with our Salesforce administration services practice, since an integration user with drifting permissions is a live risk.
Here is the decision no competitor covers, and it determines whether your load finishes.
The Informatica Salesforce connector lets you choose. That choice changes throughput, API consumption, and error behavior.
| API | Best For | Typical Volume | API Call Cost | The Catch |
|---|---|---|---|---|
| Standard (SOAP or REST) | Small, frequent syncs and near-real-time updates | Under roughly 50,000 rows | Up to 200 records per call | Burns your daily allocation fastest |
| Bulk API 1.0 | Large one-off or nightly loads | 100,000 rows and up | Batches of up to 10,000 records | CSV only; you manage serial versus parallel |
| Bulk API 2.0 | Large recurring loads | 100,000 rows and up | Fewest calls; Salesforce handles batching | Less control over batch behavior |
Three rules make this easy.
Under 50,000 rows and you need it fresh — use the standard API. The call cost is acceptable at that volume.
Above 100,000 rows — use Bulk, and prefer 2.0. Salesforce manages the batching, which means fewer calls and less for you to tune.
Choosing Bulk 1.0 with parallel mode on a table with lookups will produce row-lock errors. Run serial when records share parent records. It is slower and it finishes.
The authoritative reference for current limits and behavior is Salesforce Developers — check it before you commit, because the numbers do move between releases.
If you are still weighing tool categories rather than APIs, our post on Salesforce integration tools and what each method costs compares platform options against budget and maintenance load.
Two competitors mention installing the Secure Agent. Neither says where to put it.
The Secure Agent is the runtime that executes your tasks. It has to reach both Salesforce and whatever system sits on the other side.
Put it next to the slower system. If you are moving data from an on-premises database, the agent belongs on your network beside that database. Pulling from a remote database across the internet and then pushing to Salesforce doubles the network hop.
Give it real resources. Agents that share a small VM with other workloads become the bottleneck. Watch memory during your first full-volume run.
Run two agents for production. One agent is a single point of failure. A second in the same group means a failed host does not stop the nightly load.
Do not run production and development on the same agent. A developer testing a full-object read will slow your production sync.
Check agent CPU and memory during the first end-to-end run at real volume, not at sample volume. That test is where sizing problems surface. Practitioner discussion of ETL runtime placement is well covered by Jitendra Zaa if your team is sizing this internally.
This is the single most common cause of duplicate records in Salesforce loads, and no competitor names it.
The pattern that creates duplicates looks reasonable. A task inserts new records. Another task updates existing ones. Deciding which is which happens by matching on name or email.
That matching fails constantly. "Acme Corp" and "Acme Corporation" are different strings. An email changes. A record gets created manually between runs. Each failure inserts a record that should have been an update.
The fix is structural. Create a custom field on the Salesforce object marked as an External ID. Populate it with the primary key from the source system. Then configure the task as an upsert against that field.
Now Salesforce does the matching for you. A row with a known External ID updates. A row with a new one inserts. There is no string comparison to get wrong.
Three notes on doing this properly. Mark the field unique as well as External ID, so bad data fails loudly rather than quietly. Never reuse an External ID value for a different source record. And backfill the field on existing records before your first upsert, or the first run inserts everything.
Backfilling existing records at volume is its own exercise — our Salesforce data migration services team handles that reconciliation where the history is messy.
With the External ID in place, the mapping task becomes straightforward. Four things still go wrong.
Required fields left unmapped. Every required field on the target object needs a source or a default. Missing one fails the whole batch, not just a row.
Picklist values that do not exist. Source data says "Prospect." Your picklist says "Prospecting." Map the values explicitly rather than passing text through.
Date formats. Salesforce expects ISO format. Source systems often do not. Transform, do not hope.
Record types and ownership. If the object uses record types, set one. If ownership matters, set an owner. Records that land with the wrong owner are invisible to the people who need them.
Test with a deliberately awkward sample. Take fifty rows including your longest text values, your oldest dates, and at least one record with special characters. Clean sample data proves nothing.
Then run the same fifty rows twice. A correct upsert configuration updates on the second pass and creates nothing. If your record count grows, the External ID mapping is wrong. Integration patterns for this kind of validation are covered well by Salesforce Codex.
Your org has a daily API request limit. It depends on your edition and licence count. No competitor on this topic mentions it exists.
That matters because an integration is not the only thing consuming it. Mobile apps, middleware, reporting tools, and other connectors all draw from the same pool. Hit the ceiling and everything stops, not just the load.
Three habits keep consumption sane.
Check the number before you build. Setup shows your API usage in the last 24 hours. Know your headroom.
Filter at the source, not in the mapping. Reading a whole object and discarding rows in Informatica still consumes the calls to read them. Push the filter into the source query.
Use incremental loads. Sync records changed since the last run rather than everything every night. Full loads are for the initial migration and for recovery, not for routine operation.
Set an alert at seventy percent of your daily limit. That gives you a day's warning rather than an outage. Broader patterns for limit-aware design appear regularly on Apex Hours.
Our post on Salesforce integration patterns and best practices covers the architectural choices behind incremental design.
Every competitor guide ends at "check the error logs." That is where the real work starts.
Rows fail for ordinary reasons. A validation rule rejects a value. A required lookup points at a record that does not exist. A text field overflows. In a batch of fifty thousand, a few hundred failures is normal.
The question is what happens to them. Three answers, in order of maturity.
Nothing. The failures sit in a log nobody reads. Your systems drift apart quietly. This is the common state.
A report. Failed rows write to an error file, and someone reviews it weekly. Better, and it still depends on a person remembering.
A reprocessing path. Failed rows write to a table or file, get corrected, and feed back through the same task. This is the version that keeps systems aligned.
Build the third one. Configure the task to write rejected rows with their error message, then create a scheduled task that re-reads the corrected file.
Then watch one number: failed rows as a percentage of rows attempted. A stable low percentage is fine. A rising one means something upstream changed and nobody noticed.
Run this before the integration touches live data. It takes an afternoon and it catches almost everything above.
| Check | Why It Matters | What a Pass Looks Like |
|---|---|---|
| Dedicated integration user | Audit trails must name the system, not a person | Named integration account, not a real user's login |
| OAuth connected app | Passwords in configs outlive their owners | No password stored in the connection |
| Permission scope | Over-permissioned integrations are a live risk | Only the objects and fields the task uses |
| API choice matches volume | Wrong API means the load never finishes | Standard under 50k rows; Bulk 2.0 above 100k |
| External ID field | Prevents duplicate creation | Field marked External ID and unique, backfilled |
| Double-run test | Proves upsert is configured correctly | Second run updates; record count does not grow |
| Awkward sample data | Clean samples hide real failures | 50 rows with long text, old dates, special characters |
| API headroom | Hitting the limit stops everything, not just this | Under 70% of daily allocation with the task running |
| Secure Agent sizing | The agent is the usual bottleneck | Memory stable during a full-volume run |
| Error reprocessing path | Failures nobody fixes become data drift | Rejected rows written with errors and re-readable |
| Two agents in production | One agent is a single point of failure | Second agent in the same group |
Every row is checkable in under thirty minutes. A failing row is cheap to fix now and expensive after go-live.
Simulating full volume before production is worth doing properly — our QA automation services team runs these loads at scale so the bottleneck surfaces in test rather than on the first Monday.
It is the practice of connecting Salesforce to other systems so data moves automatically rather than by hand. Common targets are ERP, data warehouses, marketing platforms, and support tools. Informatica IDMC is one of the platforms that does this work.
Scope usually covers process mapping, choosing the integration method, connection and authentication setup, field mapping, transformation logic, error handling, and volume testing. Salesforce integration services differ most in whether ongoing monitoring is included. Ask, because an unmonitored integration fails quietly.
Yes. The connector, the Secure Agent, and your existing tasks all work as before. What has changed is the branding, the platform name (IDMC), and the joint roadmap. Nothing about your current builds breaks because of the acquisition.
It is strong where data quality and transformation matter, and where you are moving large volumes between many systems. Salesforce CRM integration through IDMC suits data-heavy landscapes better than lightweight point-to-point needs, where a simpler connector often wins on cost.
Ask which API they would use for your row volume and why. Ask how they prevent duplicates. Ask what happens to failed rows. A Salesforce integration company that answers all three with specifics has built this before; one that talks only about connectors has not.
When volumes are high, when the source system is on-premises, when data quality is poor, or when the integration feeds financial reporting. A Salesforce integration partner earns their fee on the decisions in this article, not on the click path.
Filter at the source, load incrementally rather than fully, and pick the right API for your volume. Then alert at seventy percent of your daily allocation so you get warning instead of an outage.
Someone must, or it drifts. Salesforce ships three releases a year, source schemas change, and tokens expire. Where in-house capacity is thin, our Salesforce managed services practice owns that monitoring and the failed-row queue.
The click path in every guide takes twenty minutes. The decisions in this article are what determine whether the integration still works in month fourteen. Minuscule Technologies works as a Salesforce engineering partner, not a connector installer. We design and operate data integrations with engineering discipline and DevOps-led governance — new builds, rescues of loads that create duplicates, and untangling syncs that quietly stopped running.
Three things shape our delivery. Our Accelerators and Starter Packs ship ready-made parts — integration-user and connected-app baselines, External ID patterns, error-reprocessing scaffolds, and API-consumption dashboards. Our Agentic DevOps practice runs mappings, connection config, and transformation logic through AI-assisted CI/CD, so a change to a sync is a reviewable deployment rather than an edit in production. And our re-engineering work retires duplicated tasks and full loads that should be incremental, with total cost of ownership as the number we report against. Those are the Salesforce integration solutions that hold up after the first release cycle.
Book a free integration review. We will run the eleven-row checklist against your setup, tell you which API your volume actually needs, and flag anything that will create duplicates or exhaust your API allocation. It takes about a week, with no obligation. The findings are yours either way. Schedule your strategic Salesforce call and find out what your nightly load is really doing.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
