Summary: Processing a batch of documents or feedback often involves repeated uploads, duplicated workflows, and manual result merging. ZGI's iteration node applies the same subflow to each list item. Consistent fields, original record IDs, and explicit error-handling rules make the results easier to reconcile.
Organizing customer feedback usually repeats a small set of actions: read the message, extract the request, assign a category, and record the result. Once that process works for one item, the next task is to apply it across a batch while keeping every result connected to its input.
The iteration node in ZGI Workflow reads a list, runs a configured subflow for each item, and collects the outputs. Teams can maintain extraction rules and output formats in one place, reducing the work of submitting items individually, copying nodes, and merging responses.
This pattern suits work that can be split into largely independent items: summarizing documents, categorizing support feedback, or enriching product descriptions. Comparisons and consolidation across records can happen after the per-item processing stage.
Concept illustration: prepare a list, process each item through the same subflow, then collect results with their original identifiers.
Make one item work before processing the batch
Suppose an operations team needs to extract an issue category, product, urgency level, and short summary from customer feedback. Start with a single message. Check whether those fields support the next step, such as assigning the issue to a team, before placing the processing steps inside the iteration node.
If one run produces prose and another produces a table, a larger batch will create more cleanup work. Agree on field names, decide how missing information should be represented, and carry the original record ID into the output.
In ZGI, the iteration configuration identifies both the input list and the subflow output to collect. The first determines which items enter the process. The second determines what the batch returns. Selecting an intermediate explanation instead of the intended result can leave downstream steps without the business fields they need.
Keep each result connected to its input
Before processing, organize the inputs into a consistent structure: record ID, original content, source channel, and the small amount of context the task requires. Preserve the ID in the output so later steps can reconnect the result to the original record.
A message saying “Export fails on mobile” provides enough detail for an issue category and a short description. A message saying only “It doesn't work” may need a flag for missing information. Leave that uncertainty visible rather than inventing a product version or a cause that the customer never supplied.
Identifiers also help when results are missing or filtered. A batch can contain failed items, empty outputs, or discarded results, so the number of output rows may differ from the number of inputs. Matching by record ID makes those cases easier to reconcile than joining the lists by position alone.
Choose what happens when an item fails
ZGI's iteration node offers several error-handling modes. Depending on the workflow's completeness requirements, an error can stop processing or allow other items to continue, with an empty output retained or the failed output omitted.
| Error-handling choice | What the next step needs to account for |
|---|---|
| Stop on error | Resolve the failure before arranging further processing |
| Continue with an empty output | Identify empty results and arrange follow-up processing |
| Continue and omit failed outputs | Reconcile missing record IDs so omissions remain visible |
For feedback classification, the team may be able to use successful results while reviewing failed items separately. Workflows involving payments, approvals, or writes to business systems need validation and submission steps appropriate to those consequences. Choose the error policy around the business requirement.
Reconcile the batch before handing it off
When processing ends, compare the original record IDs with the successful, incomplete, and failed results. Check identifiers as well as totals: a duplicate result can otherwise hide a missing one.
If the next step writes to a database, design duplicate detection around the record identifier. Before processing failed items again, confirm which records were already committed. This belongs in the downstream workflow design; rerunning the batch without that check can create duplicate business records.
Start with a small batch in ZGI and check the input structure, per-item rules, output fields, and error paths. When a category definition changes, update the shared subflow and validate representative examples. The same configured process can then handle the next batch of similar material.
GitHub: https://github.com/zgiai/zgi
Gitee: https://gitee.com/zgiai/zgi
Top comments (0)