How to Enrich Workflow Data with Knowledge Base Queries
Use Knowledge Base queries mid-workflow to add context from your documents to any process.
What This Integration Does
Most workflows have a moment where they need information that isn't on the input record. An order-processing flow needs to know shipping restrictions for the product category. A claim-handling flow needs the policy wording that applies to a particular customer tier. A code-deploy flow needs the runbook entry for a particular service. Rather than hand-coding all of that into the workflow, a mid-flow Knowledge query pulls the relevant text from your indexed documents and injects it as a variable everything downstream can use.
The pattern is small and reusable. Any workflow can drop a Knowledge node at the point of need, compose a query with handlebars references to earlier steps, and treat the response like any other variable. Because the Knowledge node returns both raw matched chunks and a synthesized summary, you can wire it into either an AI Agent prompt (for natural-language reasoning) or a Condition node (for deterministic gating).
Prerequisites
- A populated Knowledge collection containing the reference material you want to draw on (policies, product specs, runbooks, etc.).
- A host workflow with at least one earlier step that produces the variables your query will reference (an order, a request payload, a customer record).
Step 1: Identify the Enrichment Point
Open the workflow that needs enrichment. Find the step immediately before the decision or action that needs context - typically that's after a record is fetched and before a Condition, Human, or AI Agent step.
Step 2: Knowledge Node - Compose the Query
Insert a Knowledge node in query mode. Reference earlier-step variables directly in the query string so each run picks up the right context:
{
"query": "What are the shipping restrictions for {{ order.product_category }} to {{ order.destination_country }}?",
"topK": 5,
"minScore": 0.7
}
The node returns an array of matched chunks (each with its source document name and similarity score) plus an optional AI-synthesized summary. Save it as kbContext or similar.
Step 3: Choose How to Use the Result
You have two main consumption patterns:
- AI Agent reasoning - pass
kbContext.resultsinto a downstream AI Agent prompt so the model can reason over the retrieved policy with the request in hand. - Deterministic gating - inspect
kbContext.summarywith a Condition or a regexmatchstep to extract a specific rule (e.g. a dollar threshold) and branch on it.
Step 4: Add a Fallback for Empty Retrievals
Insert a Condition node that checks kbContext.results.length > 0. On the false branch route the workflow either to a safe default (e.g. "treat as restricted, require human review") or to a Human node where someone can supply the missing context. Letting the workflow proceed with empty context is almost always worse than asking.
Step 5: Feed the Context into the Decision Step
Whatever the next step is - an AI Agent prompt, a Human approval, a transform that builds a customer-facing message - reference the retrieved context inline:
You are reviewing an order for {{ order.id }}.
Relevant policy excerpts:
{{ kbContext.results }}
Decide whether the order can be fulfilled as-is. If a policy
requires manual review, say so and quote the relevant excerpt.
Step 6: Log the Retrieval for Audit
For regulated or auditable workflows, write the query, the matched sourceId list, and the chosen branch to a mongodb or mysql audit table. When someone asks six months later "why did we approve that?" you can replay the exact policy text that informed the decision.
Tips
- Keep the query targeted - one specific question retrieves better than a kitchen-sink query that tries to cover three concerns at once. Use two Knowledge nodes if you need two answers.
- Use filters when you have them - if your collection has tags like
policy-typeorregion, pass them in the query so retrieval scopes correctly. - Cache hot lookups - if the same product category gets queried hundreds of times an hour, stash the result in mongodb for a few minutes with the category as the key.
Common Pitfalls
- Treating the summary as authoritative - the synthesized summary is a convenience; the matched chunks are the source of truth. For compliance-grade decisions, branch on the chunk text, not the summary.
- Embedding stale data into a long-running run - if the workflow pauses for a day at a Human step, the cached
kbContextfrom yesterday may have been superseded. Re-query after the human responds when freshness matters. - Low
minScore- settingminScoreto 0.3 lets garbage matches through. Stay above 0.65 unless you have a specific reason.
Testing
Take three real records that previously triggered manual escalation. Run the workflow with the Knowledge step inserted but everything downstream disabled. Inspect kbContext for each: did it retrieve the policy you would have quoted by hand? Only after all three look right should you wire the downstream decision step back in and let the enrichment go live.