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.

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.