Choose the trigger
Define the event that should start a run and the required fields. A new task needs a stable identity and enough source context to distinguish it from a repeated event.
Workflows
Make the next step a repeatable one.
Connect triggers, classification, conditions and actions in a workflow your team can inspect.
ACDFMC+1
Illustrative workspace · interactive demonstration
Start from a real event
Define the event and fields that initiate a run.
ENG-284Linked context
Inspect each decision
Review routing rules and the evidence used by each node.
Review the range
Keep actions bounded
Use approval conditions before changing important work.
Ready for reviewHuman approval
A practical workflow
Make the decision path visible before it runs.
A repeatable workflow needs a clear starting event, inspectable conditions and a bounded action at the end.
Configure the decision
Select a node to inspect its settings. Change the classification threshold in the demonstration and check how the condition communicates the rule to a reviewer.
Review the action boundary
Decide which proposals can proceed and which require approval. Use the pause control to stop the illustrative workflow while discussing changes to its rules.
A connected working example
Connect the rule to a focused agent.
A triage workflow can use a narrow agent to propose a category, then pass that result through a team-owned condition. The workflow makes the route explicit instead of allowing an open-ended instruction to determine every next step.
Give each action a failure path. A missing owner, rejected permission or repeated event should lead to a visible status and a reviewable next step rather than an unexplained retry.
ACDFMC+1
Illustrative workspace · interactive demonstration
Inside the approach
How the model works.
Workflow rules determine which actions are eligible. Model-assisted nodes propose classifications within those rules. Permissions, approval steps and retry behavior must be configured for a production workflow.
Methodology and evaluation01Trigger
02Condition
03Reviewed action
Before you move forward
Plan the unsuccessful run as carefully as the happy path.
| Review | What to look for |
|---|---|
| Trigger identity | Keep a stable event identifier so repeats can be recognized. |
| Conditions | Document thresholds, allowed values and fallback routes. Review model output within these boundaries. |
| Permissions | Evaluate the operation against the calling user’s actual access. |
| Retries | Bound repeated attempts and use idempotency where an action creates or updates work. |
Questions & answers
A few useful answers.
What can I change in the canvas?
Select the classification node to inspect the settings and edit its confidence value. Pause and resume the example to explore the visible workflow state.
Does the demo execute external actions?
No. The canvas demonstrates configuration and review using fictional records. Supported production triggers and actions are confirmed during setup.
Where should approval happen?
Put it before an action changes important ownership, scope or commitments. The service performing a real action must also verify permissions.
Ship what you promised.
Bring the plan, the work and the next decision together.