Actions

An action is one thing a node does when a participant arrives. A node runs its actions once, in the order written, and each may carry a condition that gates that action alone, so one node can give everyone a sequence and raise a task for some of them.

An action is an object whose type names it, with its settings beside type:

{ "type": "createUserSequence", "sequenceId": "@sequences/SLEEP_CHECK", "persistent": true,
  "condition": { "source": "tags.ENROLLED", "operator": "exists" } }

Give every action an id unique within its node; it keeps two actions of the same type apart.

The actions

Each is the API operation of the same name, run as the system on the participant, so an action is named <verb><Resource>: create assigns, update changes an assignment, delete unassigns. An action takes the fields of its API operation, except the ids the platform fills in and what the table names instead. An update changes only the fields it gives. An update's status is any of the resource's statuses. An update changes only what this journey assigned and is still open: never another journey's, never staff's. updateUserJourney is the exception, and moves the participant's run of any journey, this one included.

type	What it does
createUserSequence	Assigns a sequence to the participant, with surfaceId, position, schedule, autoOpen and the flags persistent, dismissable, closable, revisable, unscheduledSubmission. What it leaves out comes from the sequence's defaults. The only action that puts something on the home screen. In place of sequenceId it can assign by tag (below).
updateUserSequence	Changes the participant's assignment of a sequence: its status (pausing, completing or archiving it), its surface, position, schedule or flags.
createUserJourney, updateUserJourney	Starts another journey for the participant (one they are already enrolled in is left where it is), or moves their enrolment in one to a status.
createUserAtom, updateUserAtom	Assigns an atom to the participant, or changes their assignment of one: its status or revisable.
createUserTag, deleteUserTag	Assigns or unassigns a tag. Assigning one they have changes nothing.
createUserGroup, deleteUserGroup	Assigns or unassigns a group.
updateUser	Assigns them a cohort, replacing any they were in, or unassigns theirs. The cohort is the only field of a person a journey sets.
updateUserExtra, deleteUserExtra	Stores one extra's value, in the shape that extra holds, or clears it.
createUserRelationship, updateUserRelationship, deleteUserRelationship	Assigns a member of staff to the participant in a relationship type, changes who it is, or unassigns it.
createUserTask, updateUserTask	Raises a task of a task type about the participant, or changes the open tasks of that type it raised: their name, description, priority, status, due date or assignees. On a create, anything left out comes from the task type. The due date is durationDays, days from when the node runs. assignees names relationship types, and the task goes to the participant's assignees of those types; on an update it replaces them.
createChatMessage	Posts a message, optionally with an atom or sequence to open, in the participant's chat with the journey.
createUserPushNotification	Sends a push notification with title and body; both need words.
createUserEmailMessage	Sends an email with subject and html.
createUserSmsMessage, updateUserSmsMessage	Sends a text, only to a participant with a mobile number who has agreed to be texted, or withdraws the texts it queued that have not gone yet.

Every send leaves a record of its status, never its words: queued, sent, failed or skipped, with why.

createUserEmailMessage and createUserSmsMessage take recipients: the participant, and relationship kinds, each reaching the participant's assignees of that kind or, without one, the kind's default assignees. A message to staff names nobody; it links to the participant's page in the portal. A kind that reaches nobody sends nothing, and the journey warns before it is published.

Assigning sequences by tag

createUserSequence can assign the sequences carrying a tag instead of naming one. In the builder, set Assign by to Tag.

{ "type": "createUserSequence", "tagId": "@tags/ANXIETY_MAIN", "count": 1,
  "strategy": "random", "skipAssigned": true }

• count (1 to 100) is how many it assigns. When fewer sequences carry the tag, it assigns those there are; it never takes from another tag.
• strategy picks among them: code, alphabetically by code, or random, a fresh draw each time the node is entered.
• skipAssigned leaves out every sequence the participant was ever assigned, by any journey or by staff, finished or not, before the count is taken. Off, the same sequence can be assigned again.
• Only the tenancy's own published sequences qualify, by the tags on their published version.
• Each sequence it picks is assigned as if the action had named it, with the same surface, flags and schedule. With autoOpen, each opens in turn.
• Nothing is shown in a set order unless the actions give one: each action's position places what it assigns in a surface sorted by position (below). Where two actions on a node can pick the same sequence, the first claims it, and the later one looks past it only with skipAssigned.

Placing what a journey assigns

A surface whose sort is Manual lists its sequences by each assignment's position, lowest first, and shows its page size before See more. An assign step's position sets where what it assigns goes, and an update step's moves it. Left out, it is 0. A coach sets the same position when assigning or editing a sequence in the portal.

{ "type": "createUserSequence", "tagId": "@tags/BULLYING_MAIN", "count": 1,
  "surfaceId": "@surfaces/ARTICLES", "position": 1 }

What to know

• Messages fill their {{ }} tokens when they are sent (Referencing a participant's data). A chat message may quote the participant; a push, an email or a text leaves the app, so it may name only the time, and a journey naming anything else in one can't be published.
• Quiet hours: a createUserPushNotification that fires inside the tenant's quiet hours is dropped (what it announced is waiting on the home screen); a chat message is held until the window closes. See Notifications.
• An action's condition reads the answer that brought the participant to the node as sequenceResponses.<sequence>.latest.
• A failing action is recorded and skipped and never stops the pass. When an expected task or message doesn't appear, look at the action.
• What reaches anyone else is the server's: tasks, chat messages, emails, texts, pushes and the journeys a chain starts happen when the server runs the input. The apps predict the rest offline, so a sequence a node assigns shows at once.