Workflow Builder¶
Workflows provide a structured framework for defining conditional logic that enables dynamic collection of data on mobile devices.
Explorations¶
Explorations are a way to organize workflows. Simply put, they are a place to group related investigations or "explorations". They have a Title, and can be deleted at any time.
Warning
Deleting an exploration will stop and delete any workflow it contains.
Note
When creating an Exploration, an Exploration Report will be automatically created. It will collate all the outputs, from all the workflows, that are part of an Exploration.
Workflows¶
A workflow represents a graph that consists of match nodes and action nodes. The mobile SDK continually processes incoming logs and aims to advance any active workflows. As logs are received, they are compared against the ongoing match conditions for each workflow. If a match is found, the relevant action is triggered, and the workflow progresses to its subsequent state. In the case of a terminal node, the workflow returns to its initial state.
From the perspective of a single workflow, this implies that it outlines a sequence of 'steps' that logs must follow to execute the intended actions. A workflow can only have one starting match condition, but it can then branch out to evaluate many conditions and execute many actions. Every terminal match condition should have attached at least one action for a workflow to be considered valid.
Workflow Lifecycle¶
As workflows are first sent to the clients, they are in an inactive state, waiting for the client to process a log that matches any of workflow's initial state conditions (i.e., any of the match conditions that connect to the start node). Once an initial match is found, the workflow becomes active within the branch of the workflow that matched. If multiple branches match the same event, multiple clones of the workflow will be concurrently active.
While the workflow is active, the SDK continuously processes logs to see if it can progress any of the active workflows and also checks if the initial conditions for a workflow are met. The SDK first considers any progress that can be made based on the log that was just received, and progresses the workflow if possible. If no progress has been made but the initial conditions are met, the workflow is reset and then progressed based on the log that matched the initial conditions.
Workflows continue to progress until they reach a terminal state (i.e., no further matching can be done), at which point they will be reset and wait for the initial conditions to be met again.
Workflows are also reset as part of the session lifecycle. When a session ends, all active workflows are reset.
Sharing and URL Slugs¶
To share a workflow, you can simply copy and paste the full URL. The workflow URL is created using slugs, which are formed by combining the workflow's title with a unique ID. A slug is the part at the end of a URL that makes it easy to identify a specific page on a website. If you edit the title, the URL slug is automatically updated to match the change. Importantly, both the old and new URLs will still work after the update.
Workflow Loops¶
Workflow loops are a powerful feature that allows expressing actions that should be repeatedly executed based on the log data. A terminal match node (e.g. one that does not otherwise link to a subsequent match node) can loop back to a previous match node on the path from the start node.
In the example above, the workflow continues to look for a single low battery event, then proceeds to emit a counter metric every time it sees a memory pressure event.
Workflows with a loop often have branches with no terminal match node, which means they run until the workflow ends by other means, see Workflow Lifecycle.
Deployment¶
A workflow must be deployed in order for it to be delivered to all connected mobile clients.
Warning
Only the workflow author can edit, deploy, or stop workflows.
Workflow Expiry (TTL)¶
Workflows have a default expiration policy (Time To Live) to ensure unused configurations do not remain deployed indefinitely. By default, a workflow expires after 30 days of no usage. Usage is defined as any time a user views data from the workflow, such as rendering a chart in an Exploration Report or on the Workflow page.
Configuration is primarily used to adjust this time period to suit specific needs. You can shorten or lengthen the duration, or explicitly disable the TTL entirely if the workflow must remain permanently active regardless of usage.
Note
Adding an alert to a workflow automatically disables the TTL, so you do not need to worry about expiration for workflows used for alerting.