Prepare Salesforce connections before import

Before you export from Flow Migrator

Review the Analyze screen for Salesforce actions and confirm they show under the Salesforce connector family. If Salesforce actions still appear as Other, re-run the analysis after the latest converter update or check whether the source action uses a custom Xtension pattern outside the supported trigger, record, or file families.

Use Required Settings and Optional Settings as normal, then export only after the SharePoint, email, naming, and unsupported-action settings are final. Salesforce connection binding happens during solution import in Power Platform.

Create or choose the Salesforce connection reference

1. Open the target Power Platform environment.
2. Create or open the solution where the migrated flow will live.
3. Create a Salesforce connection or confirm an existing connection is available.
4. Add a Salesforce connection reference to the solution if the import wizard does not create one automatically.
5. During import, map the generated Salesforce connection reference to the intended customer Salesforce connection.
6. For Salesforce trigger flows, open the trigger after import and confirm the selected object/table and polling cadence.

Check Salesforce access

• The Salesforce connection user should have API access.
• The user should be able to read, create, or update the objects used by the workflow, such as Contact, Account, User, Case, Lead, Task, or custom objects.
• Field-level security should allow reading or writing every field selected by the generated Get record, Get records, Create record, or Update record actions.
• Record sharing rules should allow access to records used during UAT test runs.
• For Salesforce Files actions, confirm the user can create ContentVersion rows and ContentDocumentLink rows and can link files to the target record type.
• If the workflow uses custom objects, confirm the object API names and field API names match the source workflow.

First test after import

1. Open the generated flow and confirm each Salesforce action has a valid object selected.
2. For Salesforce-triggered flows, create or update a controlled test record in the selected Salesforce object.
3. For action-only flows, run a controlled test with a known Salesforce record ID, query input, field payload, or sample file.
4. Check the Salesforce action outputs and compare them to the expected Nintex values, including created IDs, updated field values, ContentDocumentId, and linked-file visibility where relevant.
5. Review downstream steps that use Salesforce outputs, especially conditions, email bodies, SharePoint logging, and document generation.
6. Document any query or field changes needed before production cutover.

Common causes of Salesforce test failures

• The connection user can sign in but does not have API access.
• A custom object or field exists in the customer's Salesforce org but not in the test org.
• A selected field is hidden by field-level security.
• A query filter uses a value or relationship path that needs SOQL-style review.
• A create or update action is missing a required field, record type, picklist value, or field-level write permission.
• A file action sends content that is not in the shape Salesforce expects for VersionData, or the file exceeds the org connector limit.
• The original Nintex workflow expected only one record, but the Salesforce Get records action returns a collection.