Neptune DXP Documentation
Neptune DXP - Open Edition · 25.0 MTS

How data moves through a process flow

A process flow passes data from step to step as it runs. Every value has an origin, where it is produced, and a destination, where a later step reads it. The clearest way to see how this works is to follow the data in the order you meet it while building a process flow, from the inputs you declare first to the output a later step reads.

Start with the data the flow works with

The first thing you set up is the data the process flow works with. On the Interface tab of the Process Flow Designer, you declare its inputs. This is the interface data: the data the flow starts with, and a store that belongs to the whole run. Every step can read it from start to end, and each run has its own independent copy. See Define the interface.

Interface data is filled in when the process flow starts, by whatever triggers it, which passes the starting values in an interfaceData object in the run payload. A trigger is usually one of two kinds: an app, where a person starts the flow by acting, such as selecting a button on a form, or a server script, where the flow runs as part of a recurring or automated job. You set the trigger up once the flow is built, so it is covered later in Trigger a process flow from an app or a script.

Read the starting data in the first step

When you add the first node, it has no step before it, so the only data it can read is the interface data the flow started with. How you read it depends on the node.

In a node’s fields, such as an email subject or a decision operand, you read a value with a binding. The Inputs panel on the node lists the values you can read, and you drag one onto the field instead of typing it. Interface data uses the binding prefix InterfaceData, for example {InterfaceData>/customer/name}. For the full syntax, see Binding syntax reference.

In a Run Script node, you read the same data in code with p9.processFlow.getData(). This call works only in a script that runs inside a process flow, and returns an object with three parts:

metadata

Identifiers for the current run, such as the workflow, execution, and activity.

globals

The interface data and other Global Inputs on the node. You read a value as globals.<property>.

outputs

The outputs of earlier steps, covered further down.

To insert the call rather than write it by hand, right-click the script in the Script Editor, select Code Snippets, and under functions > p9 > processFlow choose getData. Adapt it to read the values your script needs.

In short

Interface data is the run’s shared store, and it goes by three names depending on where you work with it: the binding prefix InterfaceData in a node’s fields, the property interfaceData in the run payload that starts the flow, and globals in a script. All three are the same data.

For example, a flow that reviews a job application starts with the applicant as interface data, such as { applicant: { firstName: "Liam", yearsOfExperience: 9 } }. Whatever starts the flow sends this as interfaceData, a script reads the applicant from globals.applicant, and a field inserts the name with {InterfaceData>/applicant/firstName}.

Produce output from a step

When a step runs, it produces its own data, called task output. A Run Script node produces a value by assigning it to result, wrapped in a data property:

result = { data: { approved: true } }

The data wrapper defines what the node exposes. To make those values available to a later step, select Generate Outputs on the node, which reads the shape of the result and lists each property. The getData snippet already includes this result pattern, so one snippet covers both reading and producing. For an example of a node that exposes its output this way, see Add a script and expose its output.

Task output belongs to the step that produced it, and any later step can read it, not only the step immediately after.

Read a step’s output further on

A later step reads an earlier step’s output the same two ways as the starting data.

In a node’s fields, the binding prefix is Outputs, for example {Outputs>/<activity>/<property>}, dragged from the Inputs panel as before. In a script, you read it from the outputs part of p9.processFlow.getData(), as outputs.<activityId>.<property>. The outputs of later nodes are not available, because those nodes have not run yet.

In short

Task output belongs to the step that produced it, and any later step can read it. You read it as the binding {Outputs>/<activity>/<property>} in a node’s field, or as outputs.<activityId>.<property> in a script.

For example, a step that scores the application returns { score: 90 } as its output. A later decision reads that score to pick the applicant’s path, and a message can include it with a binding such as {Outputs>/scoreStep/score}.

Two movements that work differently

Most data follows the pattern above. Two cases do not.

A Decision node produces no output of its own. The output that reached the decision is relayed unchanged to the node on the path the decision selects. See Branching, parallel paths, and looping.

A process flow can also start another process flow. A script does this with p9.processFlow.run, passing the second flow its starting values as interface data. Use the run snippet from the same Code Snippets location, and adapt it. See Trigger a process flow from an app or a script.

In short

A Decision node produces no output of its own and passes on the output it received. To start another process flow, call p9.processFlow.run and pass its starting values as interface data.

Related topics