Recover Flow
Used to undelete a flow
Path parameters
The ID of the flow to recover
Response
The recovered flow with the given ID
Unique identifier
The ID of the user who created this test
Time the test was last updated in epoch milliseconds
The ID of the user who last updated this test
Time the test was created in epoch milliseconds
Serialized graph describing the test's version history. Managed by mabl API only.
Mapping of version tags to version numbers that the tag is currently applied to
The latest numeric version of this test
(deprecated) The ID of the organization that this journey belongs to
Workspace Id
the type of flow
Indicates whether this can be used by multiple tests
The display name of the flow. Required (non-blank) for reusable flows. When absent on older reusable data, the API serves the description value here; non-reusable flows are never given a name they did not have.
Usage notes and considerations for the flow. Historically this field held the flow's display name; that role has moved to name. To rename a flow, write name — writing this field edits the description only. When a flow has no description, the API serves the flow's name here for backwards compatibility.
mapping of tags to version numbers the tag is currently applied to
Version of the import tool used to import this flow
The mobile platform associated with this object
When enabled, mabl will not capture screenshots, network logs, DOM snapshots, or other test artifacts in order to report the most accurate flow execution time
Shares the browser state this flow produces with the rest of a cloud plan run.
Tests that reach the flow before any state has been stored each run it and store their own result. The tests in a plan stage start together, so that is the common case; a test that starts once state already exists for the same application and credentials begins from that stored state instead.
To sign in once per plan run, put a test that runs this flow in an earlier plan stage, against the same application URL and with the same credentials. Stages run in order, so the tests of later stages all start from the state that test stored.
A marked flow still runs every time. It is not skipped, so it must decide for itself whether there is anything left to do — a login flow, for example, should wrap its sign-in steps in a condition that only holds when the login page is actually showing. A marked flow that unconditionally repeats its work will do so on a browser that already carries the session.
The stored state lasts only for the plan run. Has no effect on local CLI runs.
Indicates whether this was the latest variant when retrieved
The generation number of this variant
The generation number of the variant that was edited to create this variant (if applicable)
The generation number of the variant that was merged with the previous version to create this variant (if applicable)
Name of the source branch whose version was merged to create this variant (if applicable)
Branch name the test was created on
Description of the change between this variant and the previous variant
The version of the desktop app used to create this version.
The flow's script
Description of what the script does
Step descriptions and notes keyed by the step index
the selectors from mablscript
URLs that should be visited for a visual page checker test
API steps for API only flow (stored in postman collection format)
Steps in the new json format that replaces mablscript
The version of the desktop app used to create this version.
the URL used when creating the flow
the id of the agent session that authored this flow version, if any
Time the variant was last updated
ID of the user who last updated the variant
Cloud safe ID representation (e.g. GCP/email/Kubernetes safe)
Object ID for the parent type. Set by system.