How Nintex for SharePoint bulk updates, collections, and web services are converted
Several Nintex for SharePoint workflows use older on-prem actions that do not look like modern Power Automate connector steps. Flow Migrator now recognizes the recurring .nwf adapters for bulk list updates, collection operations, web service calls, and action-set containers and maps them into importable Power Automate patterns.
What changed
The converter now recognizes several Nintex for SharePoint .nwf adapters that previously appeared as unsupported or overly generic review steps. These are reusable action families, not workflow-specific fixes.
The supported mappings are designed to produce an importable flow while keeping the source intent visible for UAT. Bulk filters, SOAP endpoints, authentication, and collection index behavior should still be reviewed after import.
- Update multiple items maps to SharePoint Get items plus Apply to each plus Update item.
- Collection operation maps common get, count, add, remove, clear, join, and deduplicate patterns to Power Automate array and variable operations.
- Call web service maps to an HTTP POST action with the detected URL, SOAP body, headers, and output variable where available.
- Action set and sequence containers are preserved as Scopes so grouped child actions remain together.
Update multiple items
Nintex for SharePoint Update multiple items can update several list items from a CAML query. Power Automate does not have the same single action, so Flow Migrator emits a filtered SharePoint Get items action, loops over the matching rows, and updates each item with SharePoint Update item.
When the .nwf export exposes field references, those source field mappings are carried into the generated Update item step instead of creating a Title-only placeholder.
- Target list name is preserved when detected from the source query.
- Common CAML equality and inequality filters are converted into OData-style Get items filters.
- Detected field mappings are applied inside the looped Update item action.
- Required Settings remains the source of truth for the target SharePoint site URL.
Collection operation
Nintex collection actions are converted to Power Automate array operations where the source action exposes the collection variable, index, value, and output variable. Get item from collection becomes an array-index expression plus an optional Set variable step.
Other common collection actions use native Power Automate variable or expression patterns, such as length() for count, union(collection, collection) for deduplicate, join() for join, and Append to array variable for add.
Call web service
Nintex for SharePoint Call web service and web request actions are mapped to Power Automate HTTP actions. The converter preserves the method, URI, headers, SOAP body, basic authentication values when detected, and response variable capture where possible.
This is structurally supported, but environment connectivity is still a deployment decision. Internal SOAP endpoints may need an on-premises data gateway, API Management facade, custom connector, VPN path, or a replacement cloud API before production use.
- Validate the target endpoint and DNS reachability from Power Automate.
- Replace legacy credentials with the approved target authentication model.
- Confirm the response body shape before downstream Query XML or variable extraction steps run.
- Expect HTTP to require premium licensing unless replaced with a standard connector or SharePoint-specific HTTP action.
How this affects compatibility status
These actions should no longer appear as unsupported when the parser can identify the underlying .nwf adapter. They may still show as partial or review-required when the source XML does not expose enough filter, endpoint, or field metadata to create a safe native mapping.
Use the compatibility matrix for the official action-family status, then use Analyze to inspect the concrete notes generated for the uploaded workflow.

