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
Parameter | Type | Required? | Sample Value | Description |
---|---|---|---|---|
title | String | yes | Calculate a product price diff % | A title for a workflow |
description | String | yes | Compare two products’ price diff % on alibaba vs newlabelwholesale | A description for a workflow |
Workflow Parameters
Workflow parameters are specific parameters you’re going to be passing into the workflows to allow execution
Parameter | Type | Required? | Sample Value | Description |
---|---|---|---|---|
key | String | yes | alibaba_url | unique key corresponding to a specific parameter |
parameter_type | Enum | yes | workflow | The type of parameter for the workflow. Meant to indicate whether this parameter is being passed in via the run workflow endpoint (workflow), or whether a parameter is the output of a different workflow step (output). Can be workflow , context, aws_secret, or output |
workflow_parameter_type | Enum | no? | string | The actual type of the parameter, meant to be used for type-safety reasons. Supported types: STRING = “string” INTEGER = “integer” FLOAT = “float” BOOLEAN = “boolean” JSON = “json” FILE_URL = “file_url” |
description | string | yes | Alibaba product URL for checking the price of the product | Description of the parameter |
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.
Parameter | Type | Required? | Sample Value | Description |
---|---|---|---|---|
block_type | Enum | yes | Task | Signifying the type of block this is in the workflow |
label | String | yes | get_alibaba_price | The unique identifier for this block within this workflow |
parameter_keys | Array | yes | parameter_keys: - alibaba_price - NLW_price | The list of parameters this block depends on for execution |
output_parameter_key | string | yes | output_parameter_key: price_diff_percentage | The optional output of the block, so that it may be used by other blocks |
{{ block specific parameters }} | ?? | yes | Other parameters, specific to the block_type specified above. These are covered below |
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