Skip to main content

Add a reference workflow and manage child updates

Reuse a released process and review how its changes reach parent workflows.

Written by Alex Merkin

Prepare a reusable child workflow and a practice parent workflow. The parent contains the reference; the child is the referenced process. Before changing the child, check which other workflows use it. Finish by checking entry into the child and continuation in the parent, not just the reference's presence in the tree.

A reference step points to another workflow so that a shared process can be maintained separately. The workflow containing the reference is the parent; the reused workflow is the child.

Prepare the child

Create and test the child workflow, including its starting step, fields, variables, and route structure. Release it before selecting it in a parent: the reference selector uses released workflows.

Give the child a name that describes the reusable process, such as Final inspection, rather than a parent-specific instruction.

Add the reference

  1. Open the parent workflow.

  2. Click Add Reference in the workflow pane.

  3. Open the reference's Basic Info tab.

  4. Search for and select the intended released workflow.

  5. Assign a chapter if appropriate.

  6. Connect the preceding step to the reference and the reference to the next parent step.

A reference has Basic Info, Routing, and Logic tabs. Edit the child's actual instructions in the child workflow; the parent reference is not a copied set of editable child steps.

Check variables and references

More menu showing workflow-wide actions

The More menu groups workflow-wide actions. The capture shows a read-only example; availability can differ with the selected version and permissions.

Open More → Workflow References to inspect the relationships.

The parent and child must have compatible variable settings where required. Publishing can report missing variables or mismatches. Use the offered management action when applicable, or fix the child where the error says the mismatch belongs.

Matching names alone do not establish compatible types and settings.

Test the complete path

Preview the parent from its root and check entry into and return from the child process. Verify fields and values used across the boundary.

Then use a controlled real test session to inspect the version and saved record. A child preview alone cannot verify its interaction with a particular parent.

Release a child change

After editing and testing the child, publish its new version. Review the parent-republish stage and select the parents that should pick up the change.

Inspect each result. The child can release successfully even when a parent has an error. Do not assume every parent or existing session updates immediately.

If a parent should retain its current behavior, follow your version policy and verify the exact version resolved in its execution context.


Did this answer your question?