Flow actions
Flow actions let automation code work with tickets, assets, people, teams, knowledge, and access records. Import each family from its exact@flow/actions/<domain> path.
Flow checks the current execution identity, team permissions, and product access on every call. References such as { kind: "primary" }, { kind: "run_team" }, and { kind: "run_beneficiary" } keep organization, team, and person identifiers out of author code.
Each step can contain at most one Flow action or integration action. Keep data preparation in a separate local step when one privileged call depends on another.
Update a ticket and notify the requester
This example loads the primary ticket, updates it with a revision precondition, adds a team-only note, and sends a run-bound in-app update.expectedRevision when a ticket mutation depends on a value read earlier. Asset field and assignment updates require the revision returned by the read action.
Asset actions use organization-scoped assetKey and assetTypeKey values instead of internal IDs. Use run-relative references or email for people, and { kind: "run_team" } or a team key for management teams. Operator asset results expose assetKey; asset action results never expose internal UUIDs.
Available actions
Result lists are paged and bounded. Use the returned cursor unchanged, with the same filters and automation run, to request the next page. Cursors expire after 30 days. If a cursor expires, restart the list without it. Flow rejects hidden resources without confirming whether they exist.
Errors and testing
Flow actions return the same exact result envelope as integration actions. Checkresult.outcome immediately. A definitive business failure is returned as outcome: "failed"; a platform or indeterminate failure throws ActionSystemError with a support reference.
Automation updates
Usemessaging.sendNotification(input) from @flow/actions/messaging to send one update. Flow chooses the recipient’s enabled channels: in-app, browser toast, email, and the connected chat provider. Slack delivers a direct message; Microsoft Teams delivers a personal message. Add delivery: { channels: ["teams"] } to limit delivery to Teams. Add onNoEligibleChannel: "error" inside delivery if the automation must fail when none of the selected channels is configured and eligible for the recipient. Flow queues notifications during a temporary chat connection failure and retries delivery a limited number of times. The older deliveryMethod field still selects exactly one channel, subject to the recipient’s preferences.
Supported audiences come from the automation run: requester, opener, or an explicitly selected team_member. The API does not accept an arbitrary recipient. Chat delivery sends a private message to that person. Teams requires the recipient to have a verified Teams identity and an active personal Flow installation. Without a connected chat provider, Flow uses the eligible in-app, browser toast, and email channels. An accepted request can still fail later during provider delivery.
message accepts up to 8,192 UTF-8 bytes. Messages selected for Slack delivery must also fit within 2,900 characters. This limit also applies while the Slack connection is temporarily unavailable. Teams shows a preview with up to 256 characters in the title and 4,000 in the body. Flow retains the full notification content.
messaging.requestResponse remains a single-channel interaction. Its required deliveryMethod is "email" or "slack". If the recipient has disabled that channel for automation input requests, the action fails before the automation begins waiting for a reply.