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.
Ancrer une étape IA dans les documents de l’espace de travail (metadata.retrieval)
La direction inverse : une action workflow qui exécute un agent — un agent intégré
@system/* ou un workflow de pack/canvas (inline ou frère) — peut être
ancrée dans un ou plusieurs documents téléversés plus tôt dans le flow, de sorte que l’agent raisonne sur des entrées réelles 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: its completed document action's page, its file_upload
// action's ingested documents, and/or its workflow (agent) action's
// assessment page are injected in full.
inputs: [{ fromTask: "upload-source", mode: "full" }],
},
},
})| Champ | Signification |
|---|---|
retrieval.inputs[] | { fromTask, mode }. Charge le(s) document(s) produit(s) à fromTask (un slug de tâche) : la page écrite par l'action document terminée de la tâche, les pages dérivées des téléversements de son action file_upload, et/ou la page d'évaluation écrite par son action workflow (agent) — résolution déterministe depuis la tâche elle-même, avec une recherche lexicale dans la KB en repli pour les tâches créées à l'exécution. Pointer fromTask vers une étape agent antérieure est la façon dont un agent s'ancre sur la sortie d'un autre agent (p. ex. une étape de consolidation sur plusieurs étapes consultatives) — l'étape agent amont doit déclarer outputSurface: "workflow" (les surfaces sont déclarées par l'auteur, jamais implicites), sinon aucune page d'évaluation n'existe pour l'étape aval. mode: "full" (par défaut) demande le document entier ; "summary" une forme condensée. |
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 l'évaluation sur l'étape agent elle-même ET comme page plafonnée par habilitation dans la KB d'instance (contentType, pageTitle) : une réponse au format verdict (JSON {verdict, confidence, rationale, …}) rend la mise en page verdict ; toute autre réponse (prose, autres schémas JSON) rend le texte propre de l'agent comme corps de page. 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. Les surfaces ne sont jamais implicites — une étape agent sans outputSurface n'écrit aucune page d'évaluation. |
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 workflow portant un agent nécessitant un ancrage — les agents intégrés @system/* reçoivent automatiquement le contexte assemblé comme message utilisateur, tandis que les workflows de pack/canvas doivent en plus référencer <start.processFlowContext> dans un bloc pour le recevoir (voir Recevoir le contexte du process flow — sans cette référence, le contexte assemblé est perdu).
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 ligne 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 pack
<pack>.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.