How Nintex Tables are handled during migration

What is now supported

Flow Migrator recognizes Nintex Automation Cloud table actions for querying rows, creating rows, and updating rows. Instead of dropping those actions or marking them as unsupported, the generated flow preserves the table ID, filters, sort/paging inputs, field payloads, row ID expressions, and original Nintex output variables in an importable HTTP/API handoff.

That handoff is intentionally explicit. It gives the migration team a working place to bind the customer-approved Nintex Tables API endpoint, replace it with a Power Automate custom connector, or redirect the operation to a replacement data store.

• Query rows becomes a Nintex Tables HTTP/API handoff that preserves filters, selected columns, paging, and output shape.
• Create row becomes a handoff that preserves table identity and field payload.
• Update row becomes a handoff that preserves table identity, row ID, and field payload.
• The generated steps remain importable, but placeholder tokens and endpoints must be replaced before production.

Why this is still a data-store decision

Nintex Tables are not just workflow actions. They are a source data store with rows, columns, ownership, security, and reporting implications. Power Automate can work with many data stores, but it does not provide a universal Nintex Tables replacement that preserves all semantics automatically.

Supported handoff means the workflow shape can be exported and reviewed in Power Automate. It does not mean the customer has chosen the long-term system of record.

Recommended target choices

• Keep Nintex Tables temporarily through the approved Nintex Tables API or a customer custom connector when short-term migration continuity matters most.
• Small lookup or configuration tables: SharePoint Lists.
• Business data with relationships, security, or app usage: Dataverse.
• Reporting-heavy or operational data: SQL Server or Azure SQL.
• Data that belongs to an external system: API or custom connector.
• Temporary workflow-only values: variables or static configuration.

Questions to ask before remediation

1. How many Nintex Tables exist and which workflows use each table?
2. Which workflows query, create, update, or delete table rows?
3. How many rows and columns are in each table?
4. Is the data configuration, operational business data, or temporary workflow state?
5. Who owns the data and who should be able to edit it?
6. Does the replacement need audit history, reporting, or relational structure?
7. Will the first release use the generated HTTP/API handoff, a custom connector, or a migrated target such as SharePoint, Dataverse, or SQL?