Creating Workflows
Creating complex multi-step workflows
Building workflows
Workflows represent chaining multiple blocks together. Imagine calling multiple tasks in a row, doing conditional logic, extracting data to a CSV, etc. All of these ideas will be supported within our workflows feature
All of our workflows are defined in YAML format, and allow chaining multiple components together to generate some defined output
Today, we’re building the workflows for most of our customers as we iterate on the specification. This is a cumbersome experience — rest assured that we are improving our web application that will offer a significantly enhanced user experience for this process.
Request - Create Workflow (YAML)
POST api.skyvern.com/api/v1/workflows
Use this API to create a workflow. The response of this API is a workflow_permanent_id
, which can be used to run workflows below
Workflow Parameters
Workflow parameters are specific parameters you’re going to be passing into the workflows to allow execution
Blocks
Blocks are the building block (pun intended) of Skyvern’s workflows. Each block is one discrete task you want to occur. Multiple blocks may be chained together, with outputs from one block being fed as inputs to the next block.
Building blocks supported today:
- TaskBlock: The magic block. Skyvern navigates through the websites to take actions and/or extract information.
- ForLoopBlock
- CodeBlock
- TextPromptBlock
- DownloadToS3Block
- UploadToS3Block
- SendEmailBlock
- FileParserBlock
To read about specific blocks, check out the block documentation
Managing Credentials and Sensitive Information
This is something the Skyvern team will need to set you up with today. If you’re interested, please book a call with Suchintan
Common concepts
continue_on_failure
continue_on_failure
flag indicates whether a failed block execution should block subsequent blocks or not
error_code_mapping
Maps errors to specific error codes so you can have deterministic outputs
persist_browser_session
The persist_browser_session
flag indicates whether the browser session should be retained between different workflow runs. When enabled, it uses the same user_data_dir
for each run and updates it at the end of each run. This is useful for maintaining the browser state, such as login sessions and cookies, across multiple runs of the same workflow, leading to more efficient and seamless execution.
Note: This flag is set at the workflow level, not the block level, meaning it applies to the entire workflow’s session persistence rather than individual blocks.
output_parameter_key
(autogenerated)
Specifies the output parameter of a specific block so it can be re-used in a subsequent block
Its format is always: {label}_output
ie the output parameter for a block like this (which can be referenced in subsequent blocks) would be: login_output