Overview

When a Workflow is triggered from Nintex Apps, it should be possible for the workflow to return data back to the app, for example saying that it has run and perhaps sharing output variables.

A key use case is when Workflow creates a record in Nintex Tables and then returns the created record ID so Apps knows exactly what to query next.

Problem

Today, the Workflow component inside Apps is not able to send anything back to the app. This makes it difficult to chain common scenarios where Apps starts a workflow, waits for the outcome, and then uses returned values to continue the user experience.

Workarounds:

• "Polling" JS snippets

• Updating an Nintex Table field with the Workflow instance data to then query it in apps and get a list of tasks
  

Use cases

Workflows are triggered from apps and can

• Alert apps when they're done

• Create a Nintex Tables record and returns the new record ID to Apps.

• Create a task and return the task id to apps

• Return the Workflow instance id to apps (ideally as an output variable for the apps "run workflow" action)

• Workflow publishes an event payload that includes the created record ID or other output values.

Apps uses returned workflow outputs to query the correct row, refresh the UI, navigate to a detail view, or continue an action flow.

Desired outcome

Support a pattern where Apps can be notified when a workflow is completed. This could be via direct output parameters, a callback/promise-style response, or an event payload that Apps can consume.

Why it matters

This would remove brittle workarounds, simplify Apps + Workflow integration, and make it much easier to build end-to-end experiences that create data and immediately act on it.