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 a Nintex Table field with the Workflow instance data, then querying it in Apps to retrieve tasks or outcomes

Use cases

Hiring: A hiring manager creates a job posting in an Apps hiring dashboard and submits it for HR approval. The workflow routes the posting to the appropriate HR managers and, once approved, sends it to the recruiting service and publishes it on the job portal. Apps receives the workflow instance ID immediately so the manager can view the approval status. When processing is complete, the workflow returns the approval outcome, created job-posting ID, and recruiting-portal URL. Apps can then refresh the dashboard, show the current status, and take the manager directly to the live posting or the next required action.

Regulatory and compliance approvals: A compliance analyst submits a policy exception, regulated document, or product change for review in an Apps compliance workspace. The workflow routes the submission to the required legal, risk, and compliance approvers based on jurisdiction, policy type, or risk level. Apps receives the workflow instance ID and approval-task IDs so the analyst can track the review without leaving the workspace. On completion, the workflow returns the decision, effective date, reviewer comments, and the approved document or exception record ID. Apps can update the submission to Approved, Rework required, or Rejected; surface required remediation steps; and provide a link to the authoritative record for audit readiness.

Safety workflows: A site supervisor reports a hazard, near miss, or safety observation from an Apps field-inspection dashboard. The workflow assesses severity, notifies the appropriate safety team, and creates any required corrective-action tasks. Apps receives the incident or observation ID and workflow instance ID right away, allowing the supervisor to see that the report was captured and to monitor triage. When the workflow completes, it returns the severity classification, assigned safety owner, corrective-action IDs, and any required follow-up date. Apps can refresh the case view, show the responsible team and next steps, and link the reporter to the corrective actions or closure record.

Incident request and case management: An employee submits an IT, facilities, HR, or customer-support request through an Apps self-service portal. The workflow validates the request, determines the service category and priority, creates a case, and routes it to the appropriate queue. Apps receives the case ID and workflow instance ID immediately so it can confirm submission and display a case-status view. The workflow can return the assigned queue or owner, SLA target, escalation status, and resolution details. Apps can then navigate the requester to the new case, refresh status as ownership changes, and present the correct next action—such as supplying more information, approving a request, or confirming resolution.

In each case, the app needs workflow data in real time to present the logical next steps to the user.

Example flow

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.

When a workflow is triggered from Apps, it can:

• Return the Workflow instance ID to Apps, ideally as an output variable for the Apps "run workflow" action

• Alert Apps when processing is complete

• Return output variables to Apps

  • For example, return a new record ID so Apps can show its details and enable follow-on interactions.

  • For example, return an approval task ID so Apps can surface the approval process.

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.