If you've built custom processors in Chain.io, you've probably hit a wall: your pre-processor can read and transform incoming data, and your post-processor can shape what goes out — but they couldn't talk to each other. Data gathered in one stage disappeared before the next one ran.
That changes today.
What's new
Chain.io flows now support executionContext — a shared object that persists values set in a pre-processor so they're available in the post-processor of the same execution. No external storage, no workarounds, no middleware. Set a value early in the flow, use it later.
This is a simple change that unlocks a lot of power.
The problem this solves
Supply chain integrations are rarely one-step operations. A freight forwarder receives a booking, and the data they need to send downstream — a customer reference, an order total, a timestamp — might only be available in the inbound file. By the time the post-processor runs against the mapped output, that context is gone.
Until now, the workaround was to encode extra values into the file body itself, build custom lookup logic, or handle it outside Chain.io entirely. All of those approaches add complexity, brittleness, and maintenance overhead.
How it works
The new executionContext object is available in both your pre-processor and post-processor scripts. Values you assign in the pre-processor persist through the mapping stage and are ready to read in the post-processor.
Pre-processor: store values from the inbound file
const storeValues = (file) => {
const orders = JSON.parse(file.body)
const orderNumber = orders.orderNumber
executionContext[orderNumber] = {
orderReference: orders.reference,
orderCount: orders.length,
totalValue: orders.reduce((sum, order) => sum + (order.value || 0), 0),
processedAt: new Date().toISOString()
}
}
for (const sourceFile of sourceFiles) {
storeValues(sourceFile)
}
returnSuccess(sourceFiles)
Post-processor: retrieve those values and use them
const handleFile = (file) => {
const orders = JSON.parse(file.body)
const orderNumber = orders.orderNumber
const { orderReference, orderCount, totalValue, processedAt } =
executionContext[orderNumber]
userLog(
`Processed ${orderCount} order(s) ${orderNumber} ` +
`with a total value of ${totalValue} at ${processedAt}`
)
return { ...file, file_name: `${orderReference}_processed.json` }
}
const updatedFiles = destinationFiles.map(handleFile).filter(x => x)
if (updatedFiles.length === 0) {
returnSkipped([])
} else {
returnSuccess(updatedFiles)
}
That's it. No configuration changes. No new dependencies. If you're already writing custom processors, executionContext is available now.
What you can build with this
Here are a few patterns we expect customers to use right away:
- Dynamic file naming. Pull a reference number or customer code from the inbound file, then use it to name the outbound file in the post-processor — exactly like the example above.
- Conditional routing. Read a field from the source data in the pre-processor (like shipment mode or destination country), then use it in the post-processor to decide whether to skip, modify, or log the output.
- Aggregation and validation. Count records or sum values during pre-processing, then validate those totals against the mapped output before it leaves Chain.io.
- Audit enrichment. Capture timestamps, source file metadata, or original field values before mapping, and attach them to the outbound payload for downstream audit trails.
Get started
Full working examples are available in our custom-processor-examples repo on GitHub. If you're new to custom processors, check out our documentation or reach out to your Chain.io contact — we're happy to walk you through it.
This feature is available now on all Chain.io Portal instances.
