Who to hire for Informatica on Salesforce

A hiring brief that says "we need an Informatica partner" is an invitation to be sold the largest project the firm can imagine. Informatica covers data integration, quality, master data, cataloguing and governance, and the people who are excellent at one of those are often only adequate at another. The acquisition adds a second complication. The close of the acquisition brings Informatica’s rich data catalog, integration, governance, quality and privacy, metadata management, and Master Data Management (MDM) services to the Salesforce platform. That is a long list, and it is exactly why you must say which part of the list you are hiring for.

The first thing to settle is what has actually changed for you. Salesforce says in its announcement: "Informatica will strengthen Data 360, ensuring data from across organizations is not only unified, but clear, trusted, and actionable." For a buyer today that sentence is a direction of travel, not a delivery date. Your partner should help you separate what is available now from what has only been announced, and should be willing to write that distinction into the plan. A firm that presents the roadmap as if it were shipped product is selling you the slide.

#Three lanes of work, three different hires

Think of Informatica work as three lanes. They overlap in the same platform but they call for different people.

The first lane is moving data into and out of Salesforce, particularly Data 360. This is pipeline work: connections, transformations, schedules and error handling. The second lane is mastering customer, account or product records, where the hard problems are matching, survivorship and stewardship. The third lane is cataloguing and governance: lineage, definitions, classification and policy.

A partner strong in the first lane will build you a fast and reliable pipeline and may be quietly uncomfortable about the second. A master data specialist will worry, rightly, about who is allowed to change a golden record, but may never have configured a Salesforce connected app. The table sets out one way to separate them when screening.

#Skills and certifications for each lane

For the Salesforce side, the useful credentials are Salesforce Certified Platform Integration Architect for anyone designing how data crosses system boundaries, Salesforce Certified Platform Data Architect for large data volumes, ownership and sharing, and Salesforce Certified Data 360 Consultant for anyone who will configure ingestion, unification and activation in Data 360. Trailhead lists all three on its credentials pages.

For the Informatica side, the vendor runs its own professional certification programme, signposted from its site. Ask which specific Informatica certifications the named engineers hold, and which module of the platform each one covers. A certificate in cloud data integration does not make someone a master data modeller, and the reverse is also true. Where nobody on the proposal holds a vendor credential, ask for a project that demonstrates equivalent depth, and consider whether the price reflects that.

#The Data 360 connection is where claims meet reality

If your project touches Data 360, ask the candidate to describe the connection from memory. Informatica documents the mechanism: "Integration requires configuring a connected app on the Data 360 platform and providing the consumer key and secret in Informatica’s platform." The detail is in Informatica's Data 360 connector article.

A competent partner will talk naturally about the connected app, the OAuth flow, the integration user and its permissions, and what happens when the secret is rotated. They will also mention naming: As of October 14, 2025, Data Cloud has been rebranded to Data 360. If a firm's documentation still says Data Cloud throughout, it was probably written before October 2025 and may not reflect current screens.

Beyond setup, press on three design questions. How will they deduplicate and standardise before the load, rather than relying on Data 360 identity resolution to fix everything afterwards? How will they handle deletes and corrections, which are harder than inserts? And how will they stop a high-volume load from consuming credits or API capacity you need elsewhere?

#What goes wrong when it is treated as a generic integration project

The characteristic failure is a technically successful pipeline that nobody trusts. Data flows, schedules run, and then a sales director finds two records for the same customer with different owners. The cause is almost always an undecided business rule, not a defect. Matching and survivorship are decisions about who wins when two systems disagree, and a partner who lets them be settled by whoever configures the tool has handed a business choice to a developer.

A second failure is scope drift from the platform's breadth. A proposal starts as a Data 360 load, and by the second workshop it includes cataloguing every table in the warehouse. Each addition is defensible and none is costed. Insist on a first release that stands on its own.

The third failure is ignoring the Salesforce side. Informatica specialists sometimes assume that writing to Salesforce is simply an API call. Validation rules, triggers, flows, duplicate rules and sharing can all reject or alter what you load, so a partner needs someone who understands the target org as well as the source.

#Informatica or MuleSoft: a question the partner must answer plainly

Salesforce now owns two integration products, and the announcement says the Informatica capabilities will combine with MuleSoft to form a broader end-to-end integration offering. For a buyer that raises a fair question: which tool should carry which load? A sensible partner will not answer by brand loyalty. In broad terms, API-led, event-driven connections between operational systems are the natural territory of an integration platform such as MuleSoft, while bulk movement, cleansing, matching and governed data sets are where Informatica has long been strong. The boundary blurs, and your estate may already contain one or both.

Ask the candidate to draw the boundary for your case and to say what they would do if you already own one of the two. A firm with experience of only one product will tend to propose it for everything. A firm with experience of both will tell you where each is overkill, and may even recommend that a small flow be built natively in Salesforce. Treat that honesty as a positive signal rather than a lost sale. Where you do already have MuleSoft, the sibling guide on integrating Informatica with Salesforce covers the design questions in more depth.

#A realistic first engagement

Pick one attribute and one flow, and prove the whole chain. For example, take customer email and billing country from the finance system, profile and standardise them, match them against existing records, load them to Data 360 or CRM, and show the result to the person who owns the data.

Scope it over four to six weeks with three outputs: a profiling report that quantifies the problem, a working pipeline with error handling, and a rules document that the business owner has signed. That last document is the one that survives staff changes. Add a short measurement, such as the count of duplicate groups before and after, so that the sponsor can see value without waiting for a programme.

#A worked example of a rule that must be decided by the business

Suppose your finance system holds "Acme Pty Ltd" with a Sydney billing address, while Salesforce holds "ACME Proprietary Limited" with a Melbourne address owned by a different account executive. A match rule can reasonably decide these are the same company. It cannot decide which address survives, which owner keeps the relationship, or whether the two sales teams should be told. Those are survivorship and stewardship decisions.

Good partners bring a short decision log to the workshop and ask for each rule to be signed by a named person. They also design a path for disputes, such as a queue a steward reviews weekly, so that unusual cases do not stall the pipeline or get quietly overwritten. When you interview, ask for an example of such a log and how often the rules were changed in the first six months. A rule set that never changes after go-live probably is not being used.

#Volumes, environments and run costs

Informatica projects often look cheap in the build phase and expensive to run, because schedules, volumes and environments multiply. Before signing, have the partner state the expected record volumes per run, the refresh frequency, and the number of environments they plan to use for development, test and production. Ask how the Informatica side is licensed for your usage, and what happens to the bill if volumes double. Ask also about the Salesforce side: API limits, Data 360 consumption and storage all respond to how often and how much you load.

A candid partner will give you a rough sizing and a monitoring approach, rather than promising that cost will take care of itself. Include a clause requiring a handover of run documentation, so that you know who watches the schedules and what to do when a job fails at two in the morning.

#Ten questions, grouped by lane

For ingestion: which load pattern would you use for our largest object, and why? How do you handle a partial failure halfway through a load? What would you do differently if we need near-real-time updates?

For mastering: who decides survivorship rules in your projects, and how do you record the decision? How do you present a disputed match to a steward?

For governance: show me lineage from a source field to a Salesforce field. How do you keep definitions current after the project team leaves?

For everything: what do you recommend we leave out of phase one? Which parts of the acquisition announcement would you not yet rely on? How will you hand the platform to our own team, and what will they be able to do unaided on day one?

A good bidder answers each of these with an example and a trade-off. A poor one answers with a feature list.

#Checking references and evidence

Ask for a reference on the same lane you are hiring for. A glowing reference about a data warehouse migration says little about master data stewardship. Ask the reference what the partner refused to do, what they would change, and whether the data quality scorecards were still being used a year later.

Request artefacts rather than case studies: a mapping specification, a match rule document, a profiling report. Redacted versions are fine. If a firm cannot produce a single artefact from any previous project, the work was either confidential beyond reason or less rigorous than claimed.

#Commercial models and the statement of work

Fixed price suits the profiling and first pipeline, because the outputs are clear. A capped time-and-materials arrangement suits the later phases, where discovery will change the shape of the work. Avoid open-ended arrangements for master data, because rules discussions can absorb unlimited time.

Put these into the statement of work: the named lanes in scope and the lanes explicitly out; the systems and objects covered; data volumes and refresh frequency; who approves match and survivorship rules; the environments to be used; performance and error-handling expectations; and the knowledge transfer deliverables. State who provides licences and environment access, because delays there are the most common cause of overruns. The licence terms themselves are a separate conversation, covered on the licence page and in Informatica Salesforce implementation cost.

#When you can skip a partner

If you only need to move a modest, clean dataset into Salesforce on a schedule, and your team already holds the Informatica skills, you do not need a partner for that. The same goes for a single, well-understood Data 360 ingestion using the documented connector, provided someone on your side has the Data 360 consultant credential or equivalent experience.

You do need help when you must reconcile customer records across several systems, when business owners disagree about which source is right, or when governance and lineage are regulatory requirements. For the surrounding questions, read what happened to Informatica and should I migrate from Informatica.