Workflows

A workflow is automation the product runs for you: a trigger, a graph of steps, and runs that advance as events arrive. Drafting and publishing are separate, so what traffic executes is always a version somebody deliberately shipped.

• Triggers are a manual fire or a cohort signal, so the 'who' is a cohort rather than a hand-written condition.
• Steps cover actions, delays, branches and guarded jumps; a graph the engine would refuse is named before publish.
• Every run keeps its reason: a wait names its signal, a failure carries its error.

How it works

A definition holds a draft graph and its published versions. The draft is edited freely and saved as it changes; publishing validates the graph and makes that version the one runs execute, so an edit in progress can never leak into traffic. A run advances node by node: actions do work, delays hold, branches choose a case or the otherwise, and a waiting node parks the run until its named signal arrives, from the product or by hand. Runs, their steps and their errors are all kept, which is what the console's runs tab and the Home screen's Needs you list read.

Where to reach it

Example

curl "https://api.prodantix.com/graphql" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "mutation ($p: String!, $d: String!) { fireWorkflow(projectId: $p, definitionId: $d) { runId } }",
    "variables": { "p": "'$PROJECT_ID'", "d": "'$DEFINITION_ID'" }
  }'