Embedded Workflows

A process-flow template can ship full workflow definitions inline via a template.workflows[] array. An inline workflow behaves identically to a sibling pack workflow (referenced by workflowSlug) from the author's perspective — the difference is that it is private to the process flow and never appears anywhere else.

When to use inline vs. sibling pack workflows

Use inline workflows when the logic is tightly coupled to this flow and you do not want it to appear as a standalone canvas workflow that users could accidentally edit or run. Use sibling pack workflows when the logic is reusable or when you want workspace admins to see and manage it independently.

Declaring inline workflows

Add a workflows array to the template object. Each entry is a full workflow definition with a slug:

import { defineProcessFlow, defineStage, defineTask, defineAction } from '@scrydon/sdk-authoring/process-flows'

export default defineProcessFlow({
  manifestVersion: 1,
  package: { id: 'acme.due-diligence', name: 'Acme Due Diligence', version: '1.0.0' },
  template: {
    slug: 'due-diligence',
    name: 'Due Diligence Review',
    version: '1.0.0',

    // Inline workflow definitions — private to this process flow.
    workflows: [
      {
        slug: 'summarize-findings',
        name: 'Summarize Findings',
        description: 'Condenses uploaded documents into a structured summary.',
        version: '1.0.0',
        definition: {
          /* blocks, edges, loops, parallels */
        },
      },
    ],

    stages: [
      { slug: 'review', name: 'Review', transitionMode: 'manual' },
    ],
    taskTemplates: [
      defineTask({
        slug: 'document-review',
        stageSlug: 'review',
        name: 'Document Review',
        actions: [
          defineAction({
            name: 'Upload findings document',
            actionType: 'file_upload',
            isRequired: true,
          }),
          defineAction({
            name: 'Summarize findings',
            actionType: 'workflow',
            isRequired: false,
            // Reference the inline workflow by its slug — identical to
            // referencing a sibling pack workflow.
            workflowSlug: 'summarize-findings',
          }),
        ],
      }),
    ],
    personas: [],
    voiceTriggers: [],
  },
})

Referencing an inline workflow from an action

Use workflowSlug on a workflow action — exactly the same field you would use for a sibling pack workflow. The platform resolves the slug at instance creation; you do not need to know the internal workflow id.

defineAction({
  name: 'Summarize findings',
  actionType: 'workflow',
  isRequired: false,
  workflowSlug: 'summarize-findings', // matches template.workflows[].slug
})

workflowSlug and workflowId are mutually exclusive. Use workflowSlug when the workflow ships with this pack (inline or as a sibling subdir); use workflowId only for a workflow that already exists in the tenant independent of this pack.

Receiving process-flow context (<start.processFlowContext>)

When a workflow action runs, the platform gathers the step's context — the stage summary, any input documents declared in metadata.retrieval.inputs, and the most recent meeting transcript — and delivers the assembled text to the workflow's start block input under the key processFlowContext.

Delivery is explicit, not automatic. A block only receives the context if it references it:

{
  "role": "user",
  "content": "Assess the submitted agenda items.\n\n---\nContext:\n<start.processFlowContext>"
}

If no block in the workflow references <start.processFlowContext>, the gathered context is silently dropped and the agent runs on its authored messages alone — typically producing answers like "I don't have access to the documents". The step's Prompt & Context panel warns when a workflow never consumes the context, and shows per-category whether anything was actually resolved.

Addressing the current knowledge base (<start.processFlow.knowledgeBaseId>)

Every process-flow instance has its own per-instance knowledge base — the place its steps already share for the read-context push channel above. A step that needs to read from or write to that KB (for example, a knowledge block that creates a document later steps will consult) cannot hard-code its id: the instance KB id is generated per run and is unknown at authoring time.

So, alongside processFlowContext, the runner injects a structured processFlow object onto the start block whenever a workflow runs under a process flow. Address the running instance's KB with <start.processFlow.knowledgeBaseId>:

{
  "operation": "create_document",
  "knowledgeBaseId": "<start.processFlow.knowledgeBaseId>",
  "name": "Bid qualification summary",
  "content": "<start.processFlowContext>"
}

The full processFlow payload an author can reference:

See Contextual KB across steps for a downloadable demo pack you can install and run — a workflow step writes a note to the instance KB, a later step reads it back, both via <start.processFlow.knowledgeBaseId>.

Versioning and instance isolation

Each process-flow instance gets its own frozen copy of every inline workflow, materialized from the pack version that was installed at the time the instance was created.

• Updating the pack and reinstalling it only affects instances created after the update.
• In-flight instances keep their original workflow definition unchanged.
• There is no way to "upgrade" the workflow inside a running instance.

This makes inline workflows safe for long-lived flows: a months-long due-diligence review will not be disrupted by a pack update that changes the summarization logic.