Designing and publishing pipelines

​

Prerequisites

You need workflows.manage for authoring and publication. Add workflows.test to maintain and run test cases. Prepare representative input metadata and files in a test environment.

​

Build a workflow

Open Workflows, choose Create, and select the input data type and a name. Open the workflow editor and build the Main flow with steps matching that data type. Select a step to configure its inputs and outputs. Connect steps in the processing order and configure conditional branches where the result determines the next step. The Exception flow is a separate diagram for failure handling. Review both flows before publication: an exception step that contacts another system can have side effects just like a main-flow step. Use the editor’s available step catalogue for your installed version. ContentFlow expressions use C# scripting; the Python Script Engine is a separate extension system with different contracts.

​

Work through one incoming contract

Use a test input containing a contract file and two properties: a customer reference and an agreement date. Agree on the destination Contract document type and its keyword names before building the steps. Start with the smallest successful path. Add branching only when the input families need different behavior. The installed step catalogue supplies the exact step names and parameters for your version.

​

Drafts can be executable

Once a workflow has a published version, ordinary new processing uses that snapshot. Saving edits updates the draft without replacing the published snapshot.

​

Validate and test

Run Validate to inspect graph findings. Errors block publication; resolve them in the indicated step or connection. A structurally valid pipeline still needs representative execution testing. In the workflow’s Test Cases area, create a case with a name, item type, and properties. Upload a sample file when the pipeline consumes content. Save the workflow and case, run the case, and inspect its last-run state and logs. Test-case runs prefer the saved draft, so they can exercise unpublished changes. They are real executions: use a test environment and test destinations for steps that upload documents, send callbacks, or otherwise change another system. A completed run should be checked against the expected document type, keywords, content, and external result. Useful cases include valid input, missing mandatory metadata, an unknown mapping value, and a controlled integration failure. These expose different problems from graph validation.

​

Publish and restore

Publish validates and records a new numbered snapshot. If the editor has unsaved changes, its publish flow asks you to save them before continuing. Apply pending edits in a step panel first: unapplied panel edits are excluded, and the editor warns before publishing without them. Review the resulting status and version after publishing. Open Published versions to inspect prior versions. Restore copies a selected version into the draft; it does not immediately change the published version. Test the restored draft, then publish to make it the new live definition. Restoring a definition does not undo documents already uploaded or messages already sent. Reruns can also remain pinned to the version recorded for their original execution; publishing a fix is not proof that a retry will use that fix.

​

Export and import

The workflow list can download a definition as JSON and import a JSON definition. After importing into another environment, review referenced mappers, variables, target metadata, and integrations before using it. A definition export is not a complete environment backup.

​

Where to read next