Triggers

Each automation has exactly one trigger. Triggers expose a flow output plus typed data outputs from the event. Many triggers support optional filters so you can narrow which events start a run.

Messages

Members

Channels, threads & roles

Reactions, voice & invites

Tickets

Commands & manual runs

Command interaction responses

The Ephemeral reply setting on Command Executed controls whether the original slash-command response is private. Assistance defers that response before the graph runs, so its visibility is fixed at the trigger and cannot be changed later by Reply to Interaction or an edit.

Use the interaction-response nodes when a command needs to reply, send a follow-up, or change one of those responses. Both invocation styles fill the trigger's Interaction output, so one graph serves them:

The interaction's Kind field is command for a slash run and message for a prefix run, so a graph can branch when the difference matters. Interaction ID and Expires At are slash-only and stay empty for a prefix run.

Pass IDs, objects, and collections to a Manual Trigger

Manual Trigger parameters are typed. A parameter's ID is the key callers use in inputs; its label is only for people reading the graph. Give parameters stable, descriptive IDs such as destination, reviewers, or context, then wire each output socket to the node that consumes it.

The Run Automation action used in templates and commands can set only types with a literal editor, such as text, numbers, booleans, colors, durations, and times. It cannot construct Discord entities, arrays, dictionaries, or other object values. Use the REST API when a manual run needs one of those values.

1. Add a Manual Trigger and declare a parameter with the required type — for example, destination as Channel, reviewers as Array, or context as Variables.
2. Wire the parameter output to a compatible downstream input. For an array, wire it to For Each or another array node; for a channel, wire it to an action such as Send Template.
3. Publish the automation.
4. Call POST /guilds/{guild}/automations/{automationId}/runs with a server API key that has the guild.automations:execute scope. See API keys for authentication.

The request body is an inputs object keyed by parameter ID. For ID-addressable types — User, Member, Role, Channel, Category, custom Emoji, Ticket, Ticket Panel, Library File, and Library Folder — pass the ID string directly. Assistance constructs the value used by the graph, so your integration does not need a preliminary lookup request.

Use a full snapshot only when you already have one or when the value cannot be identified by one ID. Full snapshots remain supported for compatibility.

curl -X POST "https://api.assistance.sh/v1/guilds/acme/automations/AUTOMATION_ID/runs" \
  -H "Authorization: Bearer gt_…" \
  -H "Content-Type: application/json" \
  --data '{
    "inputs": {
      "destination": "123456789012345678",
      "reviewers": {
        "elementType": "user",
        "items": ["234567890123456789"]
      },
      "context": {
        "release": "2026.8.0",
        "source": "deployment"
      }
    }
  }'

Common value shapes

An ID is enough for actions that operate on the resource. If your graph needs descriptive fields such as a channel name, a role color, or a user's display name, connect the ID-backed value to the matching Fetch node first.

Choosing a trigger

• React to chat → Message Created or Reaction Added
• Welcome new members → Member Joined
• Moderation → Member Banned, Member Timed Out, or Role Added
• Channel / role lifecycle → Channel Created, Role Updated, etc.
• Ticket lifecycle → Ticket Created, Claimed, or Closed
• Command workflows, including slash replies when needed → Command Executed
• Button-driven flows → Manual Trigger wired from a Continuation Action

Related