---
{
  "id": "platform.trigger.targets-and-delivery",
  "topic": "trigger",
  "title": "Trigger targets and delivery",
  "locale": "en",
  "version": "2026-08-31.1",
  "summary": "A Trigger can wake an Agent, post exactly one message to an accessible H2A conversation, or start an active owner Workflow.",
  "content": "Trigger persists three target types: `agent_wakeup`, `conversation_message`, and `workflow_run`. The wakeup-only Agent action defaults an omitted `targetAgentId` to the current Agent. An explicit target must have the same owner; the handler will reject a different owner. Conversation and Workflow targets use the owner REST/UI surface. Every target keeps an Agent as its quota and routing anchor. Knowledge grants no access to Agents, conversations, Workflows, or source resources.\n\nFor `agent_wakeup`, `systemMessage` is the task instruction queued for the target Agent. For `conversation_message`, it is the message posted into the selected H2A thread when a fire occurs; the fire-event ID is also the message ID, so retries cannot create a second post. The optional “respond with Agent” setting then queues the platform Agent to answer in that same thread. Permission and Agent membership are checked again at dispatch, and each conversation accepts at most 50 Trigger messages in a rolling 24-hour window. `systemMessage` remains capped at 4,000 characters and redacted from action telemetry.\n\n`workflow_run` starts the selected active owner Workflow without waiting for Agent connectivity. The fire-event ID is the Workflow run idempotency key, and the fire's chain depth is preserved through Workflow Agent steps. A paused, deleted, rate-limited, or otherwise unavailable Workflow records `workflow_unavailable`. Workflow-target fires are terminal after run creation and deliberately keep `deliveredAt` empty because they have no Trigger result callback.\n\n`dedupeKey`, the 10-second duplicate window, and the 5-second debounce window can suppress or merge event bursts; they do not promise exactly-once Agent execution. Delivery may be queued, skipped, delayed, or failed because permission changed, a target disappeared, quota was reached, or the chain-depth guard stopped a loop. Inspect the fire event and its stable status reason rather than guessing.\n",
  "aliases": [
    "targetAgentId",
    "trigger task",
    "systemMessage",
    "same owner Agent",
    "event delivery",
    "debounce",
    "conversation message",
    "workflow run",
    "respond with Agent"
  ],
  "tags": [
    "trigger",
    "delivery",
    "target"
  ],
  "relatedActions": [
    "arinova.trigger.create_trigger",
    "arinova.trigger.update_trigger",
    "arinova.trigger.get_trigger"
  ],
  "relatedActionPrefixes": [],
  "url": "https://docs.arinova.ai/en/kb/trigger/targets-and-delivery/"
}
---

Trigger persists three target types: `agent_wakeup`, `conversation_message`, and `workflow_run`. The wakeup-only Agent action defaults an omitted `targetAgentId` to the current Agent. An explicit target must have the same owner; the handler will reject a different owner. Conversation and Workflow targets use the owner REST/UI surface. Every target keeps an Agent as its quota and routing anchor. Knowledge grants no access to Agents, conversations, Workflows, or source resources.

For `agent_wakeup`, `systemMessage` is the task instruction queued for the target Agent. For `conversation_message`, it is the message posted into the selected H2A thread when a fire occurs; the fire-event ID is also the message ID, so retries cannot create a second post. The optional “respond with Agent” setting then queues the platform Agent to answer in that same thread. Permission and Agent membership are checked again at dispatch, and each conversation accepts at most 50 Trigger messages in a rolling 24-hour window. `systemMessage` remains capped at 4,000 characters and redacted from action telemetry.

`workflow_run` starts the selected active owner Workflow without waiting for Agent connectivity. The fire-event ID is the Workflow run idempotency key, and the fire's chain depth is preserved through Workflow Agent steps. A paused, deleted, rate-limited, or otherwise unavailable Workflow records `workflow_unavailable`. Workflow-target fires are terminal after run creation and deliberately keep `deliveredAt` empty because they have no Trigger result callback.

`dedupeKey`, the 10-second duplicate window, and the 5-second debounce window can suppress or merge event bursts; they do not promise exactly-once Agent execution. Delivery may be queued, skipped, delayed, or failed because permission changed, a target disappeared, quota was reached, or the chain-depth guard stopped a loop. Inspect the fire event and its stable status reason rather than guessing.