Workflows intégrés

Un modèle de process flow peut livrer des définitions de workflow complètes en ligne via un tableau template.workflows[]. Du point de vue de l'auteur, un workflow en ligne se comporte exactement comme un workflow d'extension frère (référencé par workflowSlug) — la différence est qu'il est privé au process flow et n'apparaît nulle part ailleurs.

Quand utiliser des workflows en ligne ou des workflows d'extension frères

Utilisez des workflows en ligne lorsque la logique est étroitement liée à ce flow et que vous ne voulez pas qu'elle apparaisse comme un workflow autonome du canevas que les utilisateurs pourraient modifier ou exécuter par accident. Utilisez des workflows d'extension frères lorsque la logique est réutilisable ou lorsque vous souhaitez que les administrateurs d'espace de travail puissent la voir et la gérer de manière indépendante.

Déclarer des workflows en ligne

Ajoutez un tableau workflows à l'objet template. Chaque entrée est une définition de workflow complète avec un 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 extension workflow.
            workflowSlug: 'summarize-findings',
          }),
        ],
      }),
    ],
    personas: [],
    voiceTriggers: [],
  },
})

Référencer un workflow en ligne depuis une action

Utilisez workflowSlug sur une action workflow — exactement le même champ que pour un workflow d'extension frère. La plateforme résout le slug à la création de l'instance ; vous n'avez pas besoin de connaître l'id interne du workflow.

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

workflowSlug et workflowId sont mutuellement exclusifs. Utilisez workflowSlug lorsque le workflow est livré avec cette extension (en ligne ou en tant que sous-répertoire frère) ; utilisez workflowId uniquement pour un workflow qui existe déjà dans le tenant indépendamment de cette extension.

Recevoir le contexte du process flow (<start.processFlowContext>)

Lorsqu'une action workflow s'exécute, la plateforme rassemble le contexte de l'étape — le résumé de la phase, tous les documents d'entrée déclarés dans metadata.retrieval.inputs et la transcription de réunion la plus récente — et transmet le texte assemblé à l'entrée du bloc start du workflow sous la clé processFlowContext.

La transmission est explicite, pas automatique. Un bloc ne reçoit le contexte que s'il y fait référence :

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

Si aucun bloc du workflow ne référence <start.processFlowContext>, le contexte rassemblé est abandonné en silence et l'agent s'exécute uniquement avec les messages rédigés par l'auteur — produisant typiquement des réponses comme « Je n'ai pas accès aux documents ». Le panneau Prompt & Context de l'étape avertit lorsqu'un workflow ne consomme jamais le contexte, et indique par catégorie si quelque chose a réellement été résolu.

Adresser la base de connaissances courante (<start.processFlow.knowledgeBaseId>)

Chaque instance de process flow possède sa propre base de connaissances par instance — l'endroit que ses étapes partagent déjà pour le canal de diffusion de contexte en lecture décrit ci-dessus. Une étape qui doit lire ou écrire dans cette base de connaissances (par exemple, un bloc knowledge qui crée un document que des étapes ultérieures consulteront) ne peut pas en coder l'id en dur : l'id de la base de connaissances de l'instance est généré à chaque exécution et est inconnu au moment de l'authoring.

C'est pourquoi, à côté de processFlowContext, le runner injecte un objet structuré processFlow dans le bloc start chaque fois qu'un workflow s'exécute sous un process flow. Adressez la base de connaissances de l'instance en cours avec <start.processFlow.knowledgeBaseId> :

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

La charge utile processFlow complète qu'un auteur peut référencer :

Consultez Base de connaissances contextuelle entre étapes pour une extension de démonstration téléchargeable que vous pouvez installer et exécuter — une étape workflow écrit une note dans la base de connaissances de l'instance, une étape ultérieure la relit, toutes deux via <start.processFlow.knowledgeBaseId>.

Versionnement et isolation des instances

Chaque instance de process flow obtient sa propre copie figée de chaque workflow en ligne, matérialisée à partir de la version de l'extension installée au moment de la création de l'instance.

• Mettre à jour l'extension et la réinstaller n'affecte que les instances créées après la mise à jour.
• Les instances en cours conservent leur définition de workflow d'origine inchangée.
• Il n'existe aucun moyen de « mettre à niveau » le workflow à l'intérieur d'une instance en cours d'exécution.

Cela rend les workflows en ligne sûrs pour les flows de longue durée : une revue de due diligence de plusieurs mois ne sera pas perturbée par une mise à jour de l'extension qui modifie la logique de synthèse.