Workflows

Workflows are the engine behind your apps. They get, send, transform, and combine data — enabling apps to display live M3 information, submit forms, send notifications, and run scheduled data refreshes.

Workflows are built in the Vince Platform Workflow Builder, not inside App Builder itself. Once a workflow exists and has been run, you can add it as a resource.

What workflows enable in apps

Capability	Example
Data retrieval from M3	Fetch open orders for a supplier and display them in a list
Form submission	Save a new record or trigger an M3 transaction when a user clicks Submit
Multi-source combination	Join M3 data with a table to enrich records before displaying them
Notifications	Send an email or Teams message when a user completes an action
Scheduled data refreshes	Keep a dashboard current without user interaction

The 1-run requirement

App Builder needs to know what a workflow accepts as input and what it returns. For most workflows it learns this from the workflow's execution history, so the workflow has to have run before App Builder can use it.

Workflows from the M3 Workflow Builder

Workflows created with the M3 Workflow Builder (including Simple M3 Workflow in App Builder) already describe their inputs and outputs. They can be used in App Builder straight away, without running them first.

For all other workflows, before adding the workflow as a resource:

Run the workflow at least once in Vince Platform with realistic inputs.
Open the workflow execution logs and verify the final step's output — confirm that the fields you want the app to use actually exist.
Only then add the workflow as a resource in App Builder.

caution

If you skip this step, App Builder may not use the workflow at all, or may reference fields that do not exist. This leads to runtime errors in the published app.

The same rule applies after changes — if you modify a workflow's output, re-run it at least once before re-prompting the app.

Adding a workflow as a resource

Open the Resources panel in App Builder.
Click Add resource and select your workflow.
Assign a descriptive alias — for example, orders_workflow or goods_receipt_lookup.
Verify the input and output structure is what you expect before prompting.

Create a Simple M3 Workflow from App Builder

If your app needs to read or write one Infor M3 transaction, you can create the workflow without leaving the editor.

In the app editor, open Resources and go to the Workflows tab.
Click New Workflow, then Simple M3 Workflow. The M3 Workflow Builder opens in a dialog.
Select the Connection, the Program and the Transaction (both can be searched), and review the fields.
Enter a Workflow Name and click Create.

The new workflow appears in the resources list, ready to use. This is the same builder as in the administration area; see M3 Workflow Builder for what it generates and how to test it.

If a workflow with that name already exists, you see "Workflow name already in use. Please select a unique name." Choose another name, or click Use existing to use the workflow that already has that name instead of creating a new one.

New Workflow is available when you work on a draft version and have write permission on workflows. Published versions can't be changed; see Publishing.

The new workflow can be used in the app straight away; it doesn't need to be run first.

Designing workflows that work well in apps

The final step of a workflow determines what App Builder can bind to the app. A few practices make this smoother:

Practice	Why
Use descriptive field names in the final step	`supplier_name` is more useful to the AI than `nm`
Return an array of objects	Better for lists and grids than parallel arrays or nested structures
Keep workflows focused on one purpose	A workflow that does one thing is easier to alias clearly and re-use
Separate fetch from write	Use one workflow to display data and a different one to save or trigger actions

Updating workflows

When you change a workflow — adding fields, renaming outputs, or restructuring the response — the app does not update automatically. After the change:

Run the updated workflow at least once.
Verify the new output in the execution logs.
Open the app in App Builder, start a new build session, and tell the AI what changed.
Save and republish.

See Prompting — When resources change for example re-prompting instructions.

Long-running workflows

Some workflows take a while, for example one that reads a lot of data from M3 or sends many records. An app can run a workflow in one of two ways:

	Normal (default)	In the background
How it works	The app asks and waits for the answer	The app starts the workflow and is told when it has finished
Waiting time	The app gives up after about 35 seconds and shows a timeout error	The app waits up to 5 minutes
Good for	Quick lookups and saves	Reports, big lookups, bulk updates, anything that can take minutes

With the background way the screen stays usable while the workflow runs, so you can show a progress message and let the user keep working. When the workflow finishes, the app receives its result, the data returned by the workflow's final step, and shows it. If the workflow fails, or takes longer than 5 minutes, the app gets an error instead and should show a clear message.

A builder does not write any code for this. Say in the prompt that the workflow can take a long time and what the app should show while it runs, when it succeeds and when it fails.

Example prompt

When the user clicks "Create stock report", run the workflow resource 'stock_report_workflow' in the background, passing the selected warehouse. This workflow can take a few minutes. While it runs, show a message "Creating report, this can take a few minutes" with a spinner, disable the button, and let the user keep browsing the rest of the app. When it finishes, show the result in a table with item number, description and quantity. If it fails or takes longer than 5 minutes, show a clear error message and a Try again button.

tip

If a normal workflow call times out in the app even though the workflow itself works in Workflow Builder, ask App Builder to run that workflow in the background instead.

If a workflow regularly needs more than 5 minutes, split it into smaller workflows, or have it write its result to a table that the app reads later.

Common app patterns using workflows

Parameterised search — accept a user input, pass it to M3, return matching records
Record creation form — collect user input and write it to M3 or a table via workflow
Notification trigger — run a workflow when a user clicks a button to send an email or alert
Scheduled data refresh — keep a dashboard current using a workflow on a timed trigger
Multi-source view — combine M3 data with table data in a single workflow output

What workflows enable in apps​

The 1-run requirement​

Adding a workflow as a resource​

Create a Simple M3 Workflow from App Builder​

Designing workflows that work well in apps​

Updating workflows​

Long-running workflows​

Example prompt​

Common app patterns using workflows​

Further reading​