Turn an order record into a traceable print request.

Define the small contract first

For the synthetic Northline Parts example, keep an order ID and row ID alongside product, batch, part number and pack quantity. The label can show 24 units while the print request asks for one copy. Define which system decides that another label is required.

Source offers	Start with	Keep explicit
A file export	File trigger and parsing/mapping, or an operator-reviewed batch.	File readiness, column names, invalid rows and repeated file handling.
A database view	Database polling or a query node.	Credentials, row identity, eligibility for processing and outcome reconciliation.
An HTTP event	A configured webhook trigger or direct print API.	Authentication, request identity and the difference between acceptance and delivery.

These are interface patterns. A particular ERP, WMS or MES needs a configured export, query or HTTP integration; its product name alone does not define the connection.

Recipe 1: review an order export

1. Choose the execution location

   Place a file trigger where the executor can read the export. Define when a file is complete before it becomes eligible for processing.

2. Parse and map the fields

   Map the source's product, lot and SKU into the label's product, batch and partNumber inputs. Preserve row identity alongside those values.

3. Route the cases you understand

   Send a row with a missing required batch to a business-review branch. Route valid rows to the intended logical printer. An invalid numeric conversion in a transform can fail the input batch; do not assume every error is isolated to one row.

4. Review the run and output record

   Inspect actual node counts and notices, then inspect the print outcome. A loop's completion barrier and a print node's queueing result are not physical delivery acknowledgements.

For a person reviewing files before submission, use the CSV and Excel batch guide. For the automation story, follow the ERP export example.

Recipe 2: bind database values as arguments

Use a saved credential reference and the database nodes' named placeholders. Keep SQL text fixed and pass runtime values through args. The current Flow 1.6 rules apply to trigger.database.poll, data.database.query and data.database.execute.

The following is a params excerpt for data.database.query with an incoming order item. It assumes a source view with the illustrated columns. Adapt that view and configure cred://erp-db and ctx.branchCode for your environment.

{
  "credential": "cred://erp-db",
  "query": "SELECT RowId, OrderId, Product, Batch, PartNumber, PackQuantity FROM PrintOrders WHERE BranchCode = :branch AND OrderId = :order_id",
  "args": {
    "branch": "ctx.branchCode",
    "order_id": "item.OrderId"
  },
  "dedupeKey": "RowId"
}

Each argument value is a plain CEL expression that resolves to a scalar. There is no interpolation wrapper around item.OrderId or ctx.branchCode. The connector binds the named values using the selected database's parameter syntax.

Runtime values, including context, must not be inserted into query or statement text. Database/server configuration belongs in the connection; an argument binds a value, not a SQL table or column name.

A polling source has no incoming item. Bind context or other supported source-scope expressions there instead. Query nodes in a running flow can use the incoming item, whose identity is combined with the result-row identity.

Decide what “processed” means

A stable row key helps the executor identify source work; it is not a global promise to suppress every future print of that business row. An intentional new manual start is new work. Define source eligibility and reconciliation with your business system.

If you write a status back to the source after queueing, name it for that milestone, such as “label requested”. Record a delivery status only after you have evidence for that status. A held database commit is a separate uncertain outcome from a held print; database held-work controls do not release printer jobs.

Recipe 3: receive an event or request a label

For a configured webhook trigger, the current route is POST /api/v1/flows/{flowId}/triggers/{triggerId}/webhook. Use the trigger's actual authentication and payload contract, then follow its run and resulting jobs. Choose the Center or local trigger placement to match the connectivity you need.

When your application already knows the label version, values and destination, use the direct print example or Runner dispatch. Preserve the idempotency header and returned identifiers with your order record. Network retry, a rejected request and an intentional reprint are different decisions.

Take the recipe to another site

Keep logical printer names and credential references in the automation. Set site context values and map printers on the deployment, group or service; service values override group values, which override deployment defaults. Publish an explicit version and inspect the applied state.

For Vienna packing and Brno dispatch, use the same workflow with each site's actual data access and printer mapping. Establish what remains local during an outage before relying on continuity.

Set up local execution → · Explore multiple locations → · Explore automation capabilities →