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 retrieve/query 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 the objects used by the workflow, such as Contact, Account, User, or custom objects.
• Field-level security should allow reading every field selected by the generated Get record or Get records actions.
• Record sharing rules should allow access to records used during UAT test runs.
• If the workflow queries 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 or query input.
4. Check the Salesforce action outputs and compare them to the expected Nintex values.
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.
• The original Nintex workflow expected only one record, but the Salesforce Get records action returns a collection.