#Automation workflows

A Space currently has two automation surfaces:

• Automations: a rule that starts one Agent or Crew with a set of instructions. See Automations.
• Automation workflows: a canvas of triggers and action nodes. They can call third-party apps through connectors, and they can call a Anakin Agent or Crew.

This page describes automation workflows only.

#How they differ from Automations

Do not treat the two surfaces as the same product. The schedule, task-status, comment, and webhook triggers on the Automations page are not the canvas builder.

#Where to open them

Open the Space automation module. The top tabs include workflows, run history, Connectors, and Variables. Variables hold shared values for workflows and are not the same as Agent or Runtime startup environment variables. Tab names, empty states, and template categories follow the product UI.

#Editor layout

When no node is selected, the right settings panel is hidden and the canvas fills the page; selecting a node opens the panel again. Workflow-level controls sit in the page top bar: the save and publish state, Run, Publish, and the ⋯ menu (auto layout, variables, lock, export, duplicate, delete). Hovering a node turns its right-edge output dot into a + for adding the next node and shows a ⋯ menu of node actions such as run, disable, replace, lock, duplicate, and delete. Node cards follow the Dify style — one rounded rectangle with connection points on the left and right edges — and the canvas Agent block is now named Custom Agent.

#Connectors

Third-party credentials are created and managed under Connectors. Workflow nodes select an existing connection instead of entering secrets on the node. From the desktop app, authorization can start in the product and finish in the system browser before returning to the app.

The toolbar shows Lark, not Feishu. Lark connections are created on the connectors page; nodes only select an existing connection and no longer choose an API domain. Lark is the international edition of Feishu; the connector authorizes a Lark account so workflow nodes can act on Lark messages and documents.

Slack OAuth2, custom apps, and Bot Token setup are documented in Connect Slack in an automation workflow. This page does not repeat that setup.

#Run an Agent or Crew

A workflow can hand work to an Agent or Crew that is already configured in Anakin.

The action lives under the AI & Agents integration and is named Anakin Agent (formerly Run Agent, which still works as a search alias). After you add it, fill in only two fields:

• Executor: one dropdown for an Agent or a Crew. These are not two separate actions.
• What to do: text that can reference data from earlier steps.

The workflow waits for that run to finish before it continues.

The Anakin Agent node does not create a Task in this release. The run appears in that Agent's execution history and can be traced back to the workflow that started it.

Agent settings include a separate switch for being called by a workflow. It is on by default and is not the same switch as being assigned Tasks. If you turn it off, the Agent still appears in the selector but cannot be chosen.

Who you can select matches Task assignment: archived, out-of-Space, and another person's Personal records do not appear. A Crew is not extra-checked against its leader's workflow switch — assigning the Crew can still reach a leader who turned that switch off.

Workflow-triggered Agent sessions are unattended sessions: they show no permission-approval cards, cannot ask a person questions, and ignore the Agent's approval-level settings; a model that still tries to ask fails fast instead of waiting. See Automations — unattended sessions.

#Assign or call on a task

Beside the Anakin Agent node, the Tasks connector has two operations that hand the triggering Task to an Agent or Crew. Both pause the workflow until the Agent or Crew finishes, and both record the run so it can be traced back to the workflow:

• Assign task to Agent or Crew makes the selected Agent or Crew the Task's executor: the Task is delegated to it.
• Call Agent or Crew into a new chat opens a new conversation on the Task with the selected Agent or Crew and sends the prompt as that conversation's first message. The Task keeps its assignee and executor — nobody is reassigned.

Use the call operation when an Agent or Crew should do a stretch of work on the Task but ownership should stay as it is — for example, when the Task belongs to a person and the Agent only assists. Because the workflow waits for each operation to finish, placing two of them one after another runs them in order: the second conversation opens only after the first Agent or Crew has finished.

The executor lists differ between the two operations. Assignment requires the Agent to allow being assigned Tasks; calling does not, so its list can offer more Agents. Agents you can call still need the workflow switch from the Anakin Agent node on, and archived Agents cannot be called.

#Task field changes

Use the Task field changed trigger in the Tasks connector to start a workflow when a selected Task field actually changes. The current Issue fields include title, description, priority, assignee, start date, due date, estimate, Sprint, Task type, Parent task, and Project. Available custom fields can also be selected. Configure the trigger with:

• Task type (optional): leave it empty to match every task type, or select one to limit the trigger to that type.
• Field (required): choose one of the available built-in or custom fields. Custom-field options show their field type and can be narrowed by the selected task type.
• When you choose priority, you can also specify the new target priority. Leave it unset to match any priority change.

The trigger output includes the Task and a fieldChange value containing the field name, previous value, and new value. If one update changes several fields, only the selected field is exposed as fieldChange. A workflow does not start when there is no real change or when a different field changed. Task status changes use a separate trigger. Existing automation configurations are unaffected; use the workflow run history to investigate a problem.

#Evaluate content with the Classifier block

The Classifier block is a first-party AI block — in the add-node picker it sits with the other built-in AI blocks, after Pi, not under the third-party connectors. It sends every authored question about the same content to a provider that implements the System One schema (Jev, clef-flash, or a compatible endpoint) in one HTTP call, so a batch of questions costs one request instead of one block per question.

Fill in:

• Provider connection: Base URL, API Key, and (advanced, optional) Model — leave the model empty to use the provider's default. Calls are billed as prepaid credits per run; a failed run is not retried, and each run is charged.

• Text or JSON to classify: the content to evaluate, usually a reference to the workflow state produced by earlier steps.

• Questions: a repeatable list of question rows, each with a name, a type, free-text instructions, and a criteria editor that follows the type:

  • choice — pick one option; author the option labels with optional descriptions;
  • noul — answer yes or no; optionally describe what yes and no mean;
  • score — rate against an ordered rubric of 2 to 10 levels.

  Question names may use letters, digits, -, and _, must be non-empty, and must be unique within the block. A JSON toggle on the form edits the raw questions object for criteria the typed editors cannot express.

The block outputs one answers object keyed by question name — later steps reference an answer as answers.<name>.choice, answers.<name>.noul, or answers.<name>.score — plus per-answer confidence and probabilities, token usage, and credits used. Question-definition errors (duplicate or invalid names, a score rubric outside 2–10 levels, an empty list) are flagged before the run sends any request; provider errors fail the block with the provider's own error.

#Schedule trigger

A schedule can be set to the minute. The timezone defaults to the timezone of the current computer.

#Slack actions

Slack appears once in the toolbar, without Preview in the name. Slack events can start a workflow: choose a Slack event and an existing connection to receive mentions, messages, or reactions. Slack can still be used as an action. Built-in app and custom bot credentials are managed as connectors; nodes only select an existing connection. See Connect Slack in an automation workflow.

#Common questions

#Does an automation workflow create a Task?

Anakin Agent does not create a Task. The run is recorded on the Agent, not in the task list.

#If I turn off workflow calls for an Agent, can a Crew still reach it?

That Agent cannot be selected on its own. If the executor is a Crew, the Crew is not extra-checked against its leader's workflow switch.

#Can a Slack event start a workflow?

Yes. Choose Slack as a trigger and pick the event. Slack can also still be used as an action.