Process Flows
Créer des Process Flows avec le SDK — étapes, tâches, personas, modèles d'actions et déclencheurs vocaux — et les distribuer sous forme de packs
Cet artefact est distribué dans un Pack. Pour le cycle de vie partagé — installation, pack build, upload — voir Packs & SDK d'authoring.
Un Process Flow est un workflow structuré et reproductible avec des étapes, des tâches et des personas — lancements de projets, audits, onboarding, revues de due-diligence. Vous le créez une fois comme Process Flow avec ce SDK et le distribuez dans un .scrydon-pack.tar.gz ; la plateforme l'instancie à chaque exécution comme un Process Flow.
Le SDK et le pack sont le seul chemin d'authoring. Les Process Flows sont définis en code avec ce SDK et installés via le téléversement Settings → Packs de la plateforme. Il n'y a pas d'éditeur in-app. Une fois un pack installé, les administrateurs d'espace de travail ajoutent le modèle à un environnement depuis la Marketplace, le rendant instanciable dans les Process Flows.
Les bundles de process flow sont des données pures. Le bundle est du JSON — aucun code exécutable ne figure jamais dans l'archive. La logique personnalisée est référencée par ID contre des workflows système ou organisationnels.
Scrydon Pack Bundles. Les process flows sont distribués sous forme d'archives .scrydon-pack.tar.gz qui regroupent le flow avec son ontologie (et, dans les prochaines versions, les seeds KB et les block packs). Le pack s'importe atomiquement — installation de l'ontologie, rebind slug → class ID tenant, matérialisation du process flow, le tout en une seule transaction. Construisez avec bunx @scrydon/sdk-authoring pack build ; inspectez avec bunx @scrydon/sdk-authoring pack inspect. Voir la spec et packages/sdk-authoring/src/packs/examples/ai-boardroom/ pour un exemple fonctionnel.
Installation
bun add -d @scrydon/sdk-authoring zodnpm install --save-dev @scrydon/sdk-authoring zodimport {
defineProcessFlow,
defineStage,
defineTask,
defineAction,
definePersona,
defineVoiceTrigger,
} from '@scrydon/sdk-authoring/process-flows'Anatomie d'un modèle
| Élément | Rôle |
|---|---|
| Package | Identité du bundle : id, name, version |
| Template | Le flow lui-même — vue par défaut, configuration d'exécution, métadonnées |
| Persona | Rôles auxquels une tâche peut être assignée (one, many ou system) |
| Stage | Une phase ordonnée. Les transitions sont manual, automatic ou approval |
| Task Template | Éléments de travail à l'intérieur des étapes. Portent des actions, des dépendances, des attributs par défaut |
| Action Template | Ce que la tâche demande à l'utilisateur de faire — checklist, document, approval, workflow, entity_link, file_upload, distribution, voice_trigger |
| Voice Trigger | Bloc d'enrichissement vocal optionnel délimité à un chemin |
Un exemple complet
import {
defineProcessFlow,
defineStage,
defineTask,
defineAction,
definePersona,
} from '@scrydon/sdk-authoring/process-flows'
export default defineProcessFlow({
manifestVersion: 1,
package: {
id: 'acme.kickoff',
name: 'Acme Customer Kickoff',
version: '1.0.0',
},
template: {
slug: 'acme-kickoff',
name: 'Customer Kickoff',
description: 'Standard onboarding flow for new enterprise customers',
version: '1.0.0',
defaultView: 'tracker',
executionConfig: {
stageFlow: 'sequential',
taskFlow: 'parallel',
allowRuntimeTaskCreation: true,
},
metadata: {
icon: 'rocket',
color: '#2563eb',
tags: ['onboarding', 'sales'],
},
personas: [
definePersona({ slug: 'csm', displayName: 'Customer Success Manager', cardinality: 'one' }),
definePersona({ slug: 'champion', displayName: 'Customer Champion', cardinality: 'one' }),
definePersona({ slug: 'system', displayName: 'System', cardinality: 'system' }),
],
stages: [
defineStage({
slug: 'discovery',
name: 'Discovery',
transitionMode: 'manual',
estimatedDuration: { value: 5, unit: 'days' },
}),
defineStage({
slug: 'rollout',
name: 'Rollout',
transitionMode: 'approval',
}),
],
taskTemplates: [
defineTask({
slug: 'collect-stakeholders',
stageSlug: 'discovery',
name: 'Collect stakeholders',
defaultAssignedRoleSlug: 'csm',
actions: [
defineAction({
name: 'Stakeholder list',
actionType: 'document',
isRequired: true,
metadata: { persona: 'csm' },
}),
],
}),
defineTask({
slug: 'kickoff-call',
stageSlug: 'discovery',
name: 'Kickoff call',
dependsOnTaskSlugs: ['collect-stakeholders'],
actions: [
defineAction({
name: 'Record kickoff call',
actionType: 'voice_trigger',
isRequired: true,
metadata: { triggerPath: '/kickoff/' },
}),
defineAction({
name: 'Capture summary to KB',
actionType: 'workflow',
isRequired: false,
workflowId: 'system.summarize-meeting',
metadata: { promoteToCorpus: 'summary' },
}),
],
}),
defineTask({
slug: 'rollout-plan',
stageSlug: 'rollout',
name: 'Approve rollout plan',
dependsOnTaskSlugs: ['kickoff-call'],
actions: [
defineAction({
name: 'Approve plan',
actionType: 'approval',
isRequired: true,
metadata: { persona: 'champion' },
}),
],
}),
],
voiceTriggers: [],
},
})Types d'actions
| Type d'action | Utiliser pour |
|---|---|
checklist | Une tâche simple que l'utilisateur marque comme terminée |
document | Un document que l'utilisateur doit produire ou joindre |
approval | Une porte d'approbation — assignée à un persona, bloque les tâches en aval jusqu'à l'accord |
workflow | Référencer un workflow exécutable — soit par workflowId (un workflow système ou org déjà existant dans le tenant) soit par workflowSlug (un workflow distribué dans le même Pack — voir Workflows). Les deux sont mutuellement exclusifs |
entity_link | Lier la tâche à une instance d'objet typé via l'ontologie |
file_upload | Un dépôt de fichier — les octets sont ingérés dans la KB de l'instance |
distribution | Envoyer vers un canal (email, slack, teams) ; supporte le quorum, fire-and-forget, all-acknowledged |
voice_trigger | Capturer de l'audio contre un chemin — le STT s'exécute et la transcription alimente la KB |
Voir Types d'actions pour une analyse approfondie par type avec des exemples prêts à copier-coller, des notes sur l'UX à l'exécution, et les champs de métadonnées que chaque type lit.
Lier un process à un domaine org-KB (knowledge.promotionTarget)
Un process flow peut déclarer que sa base de connaissances d'espace de travail doit alimenter un domaine spécifique de base de connaissances organisationnelle. Ajoutez knowledge.promotionTarget au manifeste du modèle :
import { defineProcessFlow } from "@scrydon/sdk-authoring/process-flows";
export default defineProcessFlow({
manifestVersion: 1,
package: { id: "acme.project-review", name: "Project Review", version: "1.0.0" },
template: {
slug: "project-review",
// ...stages, taskTemplates, personas...
// Declare the org-KB domain this process instance's KB feeds into.
knowledge: {
promotionTarget: {
partitionSlug: "learnings", // The governed org-KB domain slug.
objectTypeSlug: "ProjectLearning", // The Learning object type in the ontology.
},
},
},
})Quand agentic crée une instance de process, la base de connaissances d'espace de travail créée automatiquement naît liée au domaine déclaré. Aucune configuration in-app n'est nécessaire.
Si knowledge.promotionTarget est omis, la KB de l'espace de travail est créée sans lien et ne se promeut jamais automatiquement.
Déclencher la condensation des apprentissages à l'approbation
Pour finaliser automatiquement la KB de l'espace de travail quand une étape se termine, ajoutez promoteToOrgKb: true à une action approval finale :
defineAction({
name: "Sign off on project review",
actionType: "approval",
isRequired: true,
metadata: {
persona: "knowledge-lead",
promoteToOrgKb: true, // Triggers the learnings condense on approval completion.
},
})À la complétion de l'étape contenant cette tâche, la plateforme condense automatiquement la KB de l'espace de travail lié en enregistrements d'apprentissage typés et les met en file d'attente dans le domaine org-KB déclaré. L'approbation EST la porte de finalisation — aucune action « promouvoir » séparée n'est nécessaire.
promoteToOrgKb est valide uniquement sur actionType: "approval". Le définir sur d'autres types d'action n'a aucun effet.
Un administrateur d'espace de travail peut également déclencher la condensation à tout moment en utilisant le bouton Promouvoir les apprentissages dans la vue KB de l'espace de travail, sans attendre qu'un process se finalise.
Voir Promotion de contenu pour le fonctionnement de la condensation, le client broker à deux niveaux, et la colonne système references.
Ancrer une étape IA dans des connaissances gouvernées (metadata.retrieval)
La direction inverse : une action workflow qui exécute un agent @system/* peut être
ancrée dans (a) un ou plusieurs documents téléversés plus tôt dans le flow et (b) un
domaine org-KB gouverné — de sorte que l'agent raisonne sur des entrées réelles et des
connaissances organisationnelles antérieures plutôt que sur le nom de la tâche seul. Déclarez-le avec
metadata.retrieval sur l'action :
defineAction({
name: "AI Qualification Assessment",
actionType: "workflow",
isRequired: false,
executionMode: "automatic", // run when the stage is entered
workflowId: "@system/agent-project-qualifier",
metadata: {
aiAgent: "project-qualifier",
// Where the agent result lands, by target ACTION TYPE (see below):
// an assessment on this workflow step itself, and an advisory banner
// on the flow's human approval action.
outputSurface: [
{
kind: "workflow",
contentType: "project_qualification_assessment",
pageTitle: "AI Qualification Assessment",
},
{
kind: "approval",
targetTaskSlug: "go-no-go-decision",
advisorySource: "ai-qualification",
},
],
retrieval: {
// The document(s) the agent must judge. `fromTask` is the slug of an
// earlier task whose upload you want; `mode: "full"` requests the whole
// document (loaded as completely as the KB exposes).
inputs: [{ fromTask: "upload-source", mode: "full" }],
// The governed domain to consult. `partition` is REQUIRED — an object
// type can live in several domains, so retrieval never fans out across
// partitions for a governance-sensitive read.
orgKb: {
partition: "learnings",
objectType: "ProjectLearning",
limit: 8,
domainClassification: "internal",
},
},
},
})| Champ | Signification |
|---|---|
retrieval.inputs[] | { fromTask, mode }. Charge le(s) document(s) téléversé(s) à fromTask (un slug de tâche). mode: "full" (par défaut) demande le document entier — aujourd'hui le runtime injecte la copie la plus complète exposée par la KB (extraits riches) ; "summary" une forme condensée. |
retrieval.orgKb | { partition, objectType, limit, domainClassification }. Consulte un domaine gouverné. partition et objectType sont requis ; limit est par défaut 8 ; domainClassification est par défaut internal et n'est utilisé que pour le high-water-mark des pages de référence générées quand des lignes gouvernées ont informé le résultat. |
outputSurface | Optionnel. Une sélection ou un tableau. Le kind de chaque sélection est le type d'action cible sur lequel le résultat atterrit, plus la configuration par surface. kind: "workflow" écrit une évaluation en référence seule sur l'étape agent elle-même (contentType, pageTitle) ; kind: "approval" fusionne un conseil d'une ligne sur l'action d'approbation de la tâche nommée par targetTaskSlug (advisorySource étiquette sa provenance). Les autres types d'action sont réservés pour les futures surfaces. |
La récupération gouvernée respecte le niveau d'habilitation — et la page ne le dilue jamais. La lecture org-KB s'exécute au niveau d'habilitation et aux marquages de l'utilisateur assigné à l'étape (le détenteur de son defaultAssignedRoleSlug), appliqués côté serveur — l'agent ne voit que les lignes que cet utilisateur peut lire, et un domaine vide/interdit ne produit aucune ligne. Toute surface que l'agent écrit dans l'espace de travail cite les connaissances antérieures par titre uniquement ; il ne copie jamais les valeurs de champs gouvernés dans un espace de travail qui ne peut pas appliquer les marquages de la source.
Aujourd'hui workflow (évaluation sur l'étape) et approval (conseil sur une action d'approbation cible) sont les surfaces de sortie implémentées. La spécification retrieval elle-même est générique et fonctionne pour toute étape d'agent @system/* nécessitant un ancrage.
Validation du DAG de tâches
Les tâches peuvent déclarer :
dependsOnTaskSlugs— d'autres tâches qui doivent d'abord se terminerunlockAfterTaskSlug+unlockDelay— une porte douce qui s'ouvre N jours/semaines après la fin d'un prédécesseur
Le CLI inspect exécute la détection de cycle DFS (BLANC/GRIS/NOIR) et échoue fermement sur tout cycle. Codes d'erreur stables :
| Code | Signification |
|---|---|
task_cycle | Une arête de dépendance participe à un cycle |
unknown_dep_slug | dependsOnTaskSlugs référence un slug de tâche inconnu |
stage_unknown | taskTemplates[].stageSlug ne correspond à aucune étape |
Construire, inspecter, téléverser
bunx @scrydon/sdk-authoring pack validate src/pack.tsbunx @scrydon/sdk-authoring pack build src/pack.ts --outDir dist
# → dist/<package.id>-<package.version>.scrydon-pack.tar.gzbunx @scrydon/sdk-authoring pack inspect dist/acme-kickoff-1.0.0.scrydon-pack.tar.gzConnectez-vous en tant qu'administrateur de l'organisation et ouvrez Settings → Packs dans l'application plateforme. Cliquez sur Téléverser un pack et déposez votre .scrydon-pack.tar.gz. Quand le pack contient un workflow, la boîte de dialogue vous demandera de choisir un environnement d'espace de travail — les définitions de workflow s'installent dans cet environnement. Le contenu ontologie et process-flow s'installe au niveau organisation quel que soit le sélecteur.
Le flux de téléversement de la plateforme est le point d'entrée canonique pour tous les types de contenu de pack depuis l'ADR 2026-05-21 Unified pack upload surface.
Après l'installation du pack, un administrateur d'espace de travail ouvre Marketplace dans la barre latérale agentic et clique sur Ajouter sur la carte Process Flow pour le rendre disponible dans cet environnement. Une fois ajouté, tout membre de l'espace de travail peut démarrer un nouveau Process Flow à partir de celui-ci. Voir Marketplace.
Pour l'automatisation, la route agentic sous-jacente accepte toujours les téléversements. Passez workspaceEnvironmentId uniquement si le pack contient du contenu workflow ; sinon c'est optionnel.
curl -X POST "$AGENTIC_URL/api/packs/import?organizationId=$ORG_ID&workspaceEnvironmentId=$ENV_ID" \
-H "Cookie: $SESSION_COOKIE" \
-F "file=@dist/acme-kickoff-1.0.0.scrydon-pack.tar.gz"Structure du bundle
<bundle>.scrydon-pack.tar.gz
├── pack.json # top-level pack manifest (PackBundleManifestSchema)
├── ontology/
│ └── manifest.json # OntologyManifestSchema — may be empty for flow-only packs
├── workflow-<slug>/ # optional — zero or more workflow subdirs
│ └── manifest.json # WorkflowManifestSchema
└── process-flow/
├── manifest.json # ProcessFlowManifestSchema
├── assets/ # optional — JSON / image assets referenced by the flow
│ ├── icon.svg
│ └── preview.png
└── meta/ # optional — non-functional metadata (e.g. sbom.cdx.json)Chaque sous-répertoire fait l'aller-retour comme un artefact autonome valide. Extensions d'assets autorisées : .json, .svg, .png, .jpg, .jpeg, .gif, .md. Les liens symboliques, liens durs, chemins absolus et traversées de chemin (..) sont rejetés par l'inspecteur.
Quand un pack contient des workflows, l'importateur les exécute dans leur propre phase avant l'installation du process-flow — de cette façon, chaque workflowSlug sur un modèle d'action se résout en un workflowId matérialisé avant que le process flow atterrisse dans la base de données. Voir Workflows pour le contrat de rebind de slug.
Limites de sécurité
L'inspecteur runtime lit l'archive en mode streaming (analyseur tar.list uniquement — n'extrait jamais sur disque) et applique des limites strictes :
| Limite | Seuil | Code d'échec |
|---|---|---|
| Archive compressée | 5 Mo | archive_too_large |
| Total non compressé | 10 Mo | total_size_exceeded |
| Taille par fichier | 5 Mo | file_too_large |
| Nombre de fichiers | 200 | too_many_files |
| Lien symbolique / lien dur | n/a | symlink_rejected |
| Chemin absolu | n/a | absolute_path_rejected |
| Traversée de chemin | n/a | path_traversal_rejected |
| Répertoire de niveau supérieur non autorisé | n/a | disallowed_path |
| Extension non autorisée | n/a | disallowed_extension |
La route /import retourne 413 pour les violations de taille et 400 pour les violations de structure ou de graphe.
Pourquoi pas de code exécutable
Les process flows sont déclaratifs. La logique personnalisée est référencée — par workflowId (un workflow déjà présent dans le tenant) ou par workflowSlug (un workflow distribué avec le modèle dans le même Pack) — pas bundlée. Même quand un Pack distribue des workflows dans des sous-répertoires workflow-<slug>/, la représentation sur disque est du JSON pur ; le catalogue de blocs runtime réside dans la plateforme. Cela rend la surface déterministe, reproductible et téléversable par des auteurs non-ingénieurs.
Où aller ensuite
Types d'actions
Référence par type — une page par actionType avec des exemples, des champs de métadonnées et l'UX runtime.
Marketplace
Après l'installation d'un pack, les administrateurs d'espace de travail ajoutent des Process Flows à un environnement et déploient des Workflows depuis la Marketplace.
Exemples
Téléchargez des archives de process-flow prêtes à l'emploi — Revue trimestrielle ISO, Revue annuelle ISO.
Ontologies
Les process flows produisent des instances typées contre l'ontologie — créez d'abord le système de types.
Workflows
Distribuez des actions actionType: workflow et les workflows qu'elles référencent dans le même Pack via workflowSlug.
Intégrations
Les workflows référencés par actionType: workflow sont construits à partir de blocs — dont beaucoup proviennent d'intégrations.