Databases & connectors

How Salesforce actions are converted

Flow Migrator supports common Nintex Automation Cloud Salesforce trigger and action patterns. Record-created and record-modified starts map to Salesforce polling triggers; retrieve, query, create, and update record actions map to native Salesforce connector actions; and Salesforce file patterns are converted through ContentVersion and ContentDocumentLink records for UAT validation.

8 min readUpdated Jun 6, 2026SalesforceCRMpremium connector
Quick answer
In shortSee how Flow Migrator maps Nintex Automation Cloud Salesforce triggers, record actions, and file actions to Power Automate Salesforce connector patterns.
Most likely causeFlow Migrator recognizes Nintex Automation Cloud Salesforce start events and Xtension actions for record-created starts, record-modified starts, retrieving records, querying records, creating records, updating records, storing files, associating files to records, and adding file collections to records. These patterns are treated as supported instead of generic Other or Unsupported items.
What to do nextConfirm the connector family first, then test the target connection before you rely on the exported flow.

Supported Salesforce trigger and action families

Flow Migrator recognizes Nintex Automation Cloud Salesforce start events and Xtension actions for record-created starts, record-modified starts, retrieving records, querying records, creating records, updating records, storing files, associating files to records, and adding file collections to records. These patterns are treated as supported instead of generic Other or Unsupported items.

The generated package uses the native Power Automate Salesforce connector where possible. File actions use Salesforce Files objects such as ContentVersion and ContentDocumentLink so the customer can bind the Salesforce connection reference during import and validate final object, field, file, and record access in the target environment.

  • Salesforce record-created starts map to Salesforce - When a record is created.
  • Salesforce record-modified starts map to Salesforce - When a record is modified.
  • Nintex retrieve_record maps to Salesforce - Get record.
  • Nintex query_records_v_2 maps to Salesforce - Get records.
  • Nintex create_record maps to Salesforce - Create record.
  • Nintex update_record maps to Salesforce - Update record (V3).
  • Nintex store_file maps to ContentVersion creation and reads back ContentDocumentId for downstream linking.
  • Nintex associate_file_to_record maps to ContentDocumentLink creation.
  • Nintex add_attachments_to_record loops over the detected file collection and creates ContentVersion records with FirstPublishLocationId.
  • Detected object API names, field payloads, record ID expressions, query limits, filters, and file-linking values are carried forward on a best-effort basis.

What to validate after import

Salesforce actions are supported, but Salesforce security and metadata still matter. A converted flow can import correctly and still fail at runtime if the connection user cannot see the object, field, record, or relationship used by the original Nintex action.

Treat the first import as a UAT artifact. Confirm the Salesforce connection reference, object API names, field-level security, record IDs, required fields, filter syntax, file permissions, and returned result shape before production use.

  1. Map or create the Salesforce connection reference during solution import.
  2. Open the generated Salesforce actions and verify the object type.
  3. Confirm selected fields exist and are readable by the connection user.
  4. Confirm record ID expressions and filter expressions resolve to real values during a test run.
  5. For create and update actions, confirm required fields, record type IDs, picklist values, and blank/null behavior.
  6. For file actions, confirm ContentVersion, ContentDocumentLink, file-size, and visibility behavior in the customer Salesforce org.
  7. Review downstream steps that consume Salesforce outputs, especially email recipients, SharePoint updates, file association, and document-generation inputs.

When a Salesforce action may still need review

Some Salesforce operations are more complex than a straightforward native connector action. Relationship fields, nested conditions, custom formula dependencies, required record type logic, large result sets, and customer-specific query conventions may require manual validation or a SOQL/custom-API fallback.

Flow Migrator should still preserve a clear review note when it cannot safely express a Salesforce pattern as a native connector or Salesforce Files action. That keeps the generated package honest instead of silently dropping CRM behavior.

  • Complex filters that cannot be represented cleanly as connector filter expressions.
  • Relationship queries or fields that require SOQL validation.
  • Queries that rely on customer-specific custom objects or managed-package fields.
  • Downstream logic that assumes a collection shape different from the Power Automate Salesforce connector output.
  • File-content expressions that need base64 validation before Salesforce accepts VersionData.
  • Record-linking semantics where ShareType, Visibility, or FirstPublishLocationId must follow customer org policy.

Licensing and connection notes

Salesforce is treated as a premium connector family in Flow Migrator guidance. Before a pilot, confirm the target Power Platform environment can use the Salesforce connector and that the Salesforce account has API access and permission to the objects used by the workflow.

For MSP or enterprise pilots, use a dedicated Salesforce connection reference in the Power Platform solution rather than hard-coding a developer's personal connection into a production import.

Related articles

Keep reading the next most relevant guides for this workflow pattern.