Contextual KB across steps
A downloadable demo pack — a process flow whose workflow step writes a note into the running instance's own knowledge base with <start.processFlow.knowledgeBaseId>, and a later step reads it back. Download, install, start an instance, run the two steps.
Every process-flow instance owns its own per-instance knowledge base. The Contextual Knowledge Base pack is the smallest thing that proves a workflow step can address that KB — without a hard-coded id, which is impossible anyway because the instance KB id is generated per run.
The template has one stage with two workflow actions:
- Write a note to the run KB — a Knowledge block (Add Data) writes a note into
<start.processFlow.knowledgeBaseId>. - Read it back from the run KB — a Knowledge block (Search) over the same
<start.processFlow.knowledgeBaseId>finds the note the first step wrote — in the same run, with no coordination of ids between the two steps.
That handle, <start.processFlow.knowledgeBaseId>, resolves at run time to whichever instance KB the run belongs to. Download the pack, install it, start an instance, and run the two steps.
What the pack provisions
| What | Detail |
|---|---|
| "Contextual Knowledge Base Demo" process flow | One stage, two workflow actions (write, read). Each references an inline canvas workflow shipped in template.workflows[]. |
Two inline workflows (kb-write, kb-read) | Each is starter → Knowledge. The Knowledge block's knowledge-base field is the literal string <start.processFlow.knowledgeBaseId>. |
| A placeholder ontology | A pack must ship at least one content kind the bundler understands; this one carries a single unused object type. The demo's substance is the process flow, not the ontology. |
The instance KB is a Memex knowledge base. Add Data (the create_document operation) is the one write operation both KB engines support, so the write step works against it — Memex ingests the text as a page. Ingestion is asynchronous: the page is queryable a moment after the write step reports done, so run the read step a beat later, not in the same instant.
Download
The pack is a downloadable .scrydon-pack.tar.gz bundle — it is not preshipped with the platform.
- contextual-knowledge-base.scrydon-pack.tar.gz — latest.
- scrydon-pack-contextual-knowledge-base-1.0.1.scrydon-pack.tar.gz — version-pinned.
Install & run
.tar.gz onto the drop zone, tick the unsigned-pack acknowledgement, and click Upload. The Contextual Knowledge Base Demo process flow is made available org-wide.<start.processFlow.knowledgeBaseId>.The Search operation synthesizes an answer with the org's default language model, so the read step needs an LLM integration configured. Even without one, the step's results output still contains the retrieved page, so you can see the write→read chain regardless.
How the reference is authored
The KB field on the Knowledge block is a picker in the canvas UI, but in this pack the workflows are SDK-authored, so the field is simply the string <start.processFlow.knowledgeBaseId> — there is no Advanced-mode step to perform. This is what the inline workflow looks like:
// template.workflows[].definition.blocks["block-kb-write"]
{
type: "knowledge",
subBlocks: {
operation: { id: "operation", type: "dropdown", value: "create_document" },
knowledgeBaseId: { id: "knowledgeBaseId", type: "knowledge-base-selector", value: "<start.processFlow.knowledgeBaseId>" },
name: { id: "name", type: "short-input", value: "Run note - <start.processFlow.instanceName>" },
content: { id: "content", type: "long-input", value: "…" },
},
}The read workflow is identical except operation: "search" with a query instead of name/content. The runner injects a processFlow run-context object onto the start block when the action runs under a process flow, and the interpreter resolves <start.processFlow.knowledgeBaseId> against it. The same <start.processFlow.*> object also exposes instanceName, startedAt, template.*, and entity.* — the write step's document name uses <start.processFlow.instanceName>.
On the canvas (building a workflow by hand rather than in a pack) the same value goes in the Knowledge block's Advanced → Knowledge Base (reference) field, because the basic picker can't take a typed reference. See Knowledge block → Choosing the knowledge base.
Why the reference, not a literal id? The instance KB id is generated per run, so it cannot be known at authoring time; a workspace KB id would be environment-specific and break when the pack moves between tenants. <start.processFlow.knowledgeBaseId> resolves at run time to this instance's KB, so one authored workflow behaves correctly everywhere.
Only under a process flow. Run one of these workflows standalone (from the canvas or the workflows API) and there is no processFlow start field — <start.processFlow.knowledgeBaseId> resolves to nothing and the Knowledge step finds no KB (fail-closed). Use this handle only in workflows authored to run as process-flow workflow actions.
Related
- Knowledge block — operations, and the Advanced Knowledge Base (reference) field for the canvas.
- Embedded Workflows — the inline
template.workflows[]mechanism, the full<start.processFlow.*>reference table, and the receiving-context push channel. - Authoring: Process Flows — stages, tasks, actions, and grounding an AI step in governed knowledge.