Update flow metadata only
Update the unversioned metadata of an existing flow
Path parameters
The ID of the flow to update
Headers
If-Match header according to http/1.1 spec section 14.24
Request body
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.
Response
The updated flow metadata
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.