A connector moves data, an integration owns what happens next
A connector and an integration get used as if they're interchangeable, and that mix-up is where a lot of data sync projects between Power Automate and Salesforce quietly fail. A connector is the part that gets a record from one system into another, a flow that reads a form submission, maps five fields, and calls the Salesforce API to create a lead. That part is genuinely not hard anymore. Microsoft ships a Salesforce connector out of the box, the field mapping takes an afternoon, and in a demo it works every single time.
An integration is a different claim. It has to say what happens when Salesforce rejects the record because a validation rule fired. It has to say what happens when someone on the admin team renames a picklist value or makes a field required next quarter. It has to say what happens when the flow times out mid run and creates the same lead twice. And it has to name who gets paged at 2am when none of that gets handled and a rep opens a territory that's been empty for four days.
Nobody signs off on a project by asking those questions directly, and that's exactly the problem. The demo only ever answers a narrower one: does data move. The case for a small integration contract makes the argument for writing the failure modes down before anyone opens a low-code canvas, and I've come around to thinking that document is the real deliverable, more than the flow itself.
The lead flow that looked finished in the demo
Here's the version of this I've watched happen more than once. A Power Automate flow picks up new leads from a web form, does light field mapping, Full Name, Email, Company, Lead Source, and calls the Salesforce Create Record action. In UAT it processes forty test leads without a hiccup. It ships. For two and a half weeks it runs clean, twenty to thirty leads a day landing in the right queue with the right owner assigned by a Salesforce assignment rule.
In week three, the Salesforce admin team ships a change nobody on the Power Platform side hears about: a validation rule called Require State For Web Leads, added because a regional sales director complained his reps kept getting leads with no state and no way to route them. The rule requires State/Province whenever Lead Source equals Web and Country is blank. The flow was never mapping Country. Every lead from that form starts failing with a REQUIRED_FIELD_MISSING fault.
Nobody sees it happen, because the flow's error handling is a Configure Run After setting on the Create Record step, set to run whether the previous step succeeded or failed, log a generic message, and move on. There was no retry built in, and no notification went anywhere, so the rejected record simply vanished. The flow shows a green checkmark in the run history every time, because as far as Power Automate is concerned the flow completed. It just completed having silently dropped every lead that hit the rule. A sales manager finally asks why his territory pipeline looks thin, and someone traces it back 11 days and 340 leads later.
The failure that never shows up in a demo
The developer who built the flow wasn't careless. The demo and the acceptance test only ever exercise the case where B accepts the record. Nobody runs a test where the destination rejects on purpose, because writing that test means deciding first what should happen when it does, and that decision usually doesn't get made until the failure is already loud enough to reach a sales manager.
A second failure mode shows up when the flow itself misbehaves, not the destination. Power Automate has a default timeout and a default retry policy, and if the Salesforce API call runs slow, say a workflow rule on the Lead object is doing a callout of its own, the flow can time out, retry, and successfully create a second lead for the same web form submission. Now there are two records and two owners, and a rep is working a duplicate while the original sits untouched. Catching that requires a durable key on the source record, something like the form submission ID or a hash of email and timestamp, checked against Salesforce before the create fires. A field guide to durable business keys covers what that key needs to survive contact with two systems that don't agree on what makes a record unique.
The validation rule in the scenario above wasn't something the Power Platform team could have prevented by writing better flow logic. It's a change on the far side of a wall the two teams don't share visibility across. A map of every system a lead record touches before either team ships a change is the real defense, because it turns Salesforce's admin panel and Power Automate's flow designer into gates instead of surprises.
The test for whether you actually built an integration
Before anyone signs off on a project like this as done, walk through four moments out loud in the go live meeting instead of trusting the demo. First, what happens the instant Salesforce returns a fault instead of a success. Does the rejected lead land somewhere a human checks that day, or does the flow log a line nobody reads and move on.
Second, who finds out before customers do when a field gets renamed or a validation rule gets added on the Salesforce side. If the answer is nobody, because the Power Platform team and the Salesforce admin team sit in different meetings and read different release notes, that's the same gap that turned into 340 missing leads above, and it will happen again on a different object with a different rule.
Third, what stops the flow from creating the same record twice after a timeout and a retry. If the answer is nothing, every slow API call is a future duplicate sitting in a pipeline report waiting for whichever rep gets assigned it.
Fourth, and this is the one teams skip most often, who is actually on call for this flow. Not which team owns the Power Automate license, a named person or a named rotation who gets paged when it fails at 2am on a Tuesday, and what runbook they open when it does. A queue holding a failed record isn't the same thing as someone owning it, and plenty of projects mistake the existence of an error queue for the existence of an owner.
Who gets paged, and what they do when it fires
In the account I keep coming back to, the actual fix took under a day once someone found the problem. Add Country to the field mapping. Add a branch off Configure Run After that catches the fault and posts the failed payload to a Teams channel RevOps actually watches. Then set up a scheduled flow that reconciles the morning's web form submissions against Salesforce leads at 6am, to catch anything that slips through some other way. None of that is complicated. All of it was missing because the original scope said deliver the lead sync, and nobody wrote down that the sync included a failure path.
That reconciliation step matters more than it sounds like it should. A dashboard showing the flow's success rate tells you the flow ran. It won't tell you the record it created matches what the source system thinks exists, and it won't catch the lead Salesforce silently merged into an existing contact through its own duplicate rule. The first thirty minutes of a platform incident assumes you already have a paging path and a runbook to open. Most Power Platform to Salesforce syncs never get that far, because there was no incident defined in the first place, just a flow that either ran or didn't.
The same gap shows up in the assignment logic downstream. Lead routing rules that stop making sense six months into a project are usually a symptom of the same root cause: a sync built to move data once, in a demo, under conditions nobody wrote down and nobody re-tested as the org's validation rules and assignment rules kept changing underneath it.
The sign off question that tells you the truth
The next time someone asks whether a sync project is done, don't ask if it works. Ask them to describe, out loud, what happens to the next record Salesforce rejects, and watch how long it takes to get an answer that isn't a shrug.
If that answer takes longer to produce than the fifteen seconds it took to describe how the connector maps its fields, that gap is the actual finding. Write the missing half down as its own line item, put a name against the 2am page, and only then close the ticket. A connector that moves data is maybe a third of the job. The other two thirds are what this piece has been about, and neither one shows up until the system on the other end starts saying no.
