Custom Actions

Custom Actions allow you to create reusable actions tailored to your specific needs by combining existing actions into a single unit. This simplifies workflow creation and promotes consistency across workflows.

Creating a New Custom Action

Note: The ‘If’, ‘If else’, ‘For Each’, ‘Variable’, ‘Wait’, ‘Note’, and ‘End Run’ actions cannot be customized.

Navigate to Settings

On the right-hand side of the step, click the Save as new custom action option.

Configure the Custom Action

Enter the following parameters:

A Custom Action name
Select a Vendor or create a new one
Enter a description
In Advanced Settings, you can edit the YAML format

Save and Reuse

Note: A custom action label will appear next to it, indicating that it is a custom action.

Click ‘Create’ to save your custom action. It will now appear under the selected vendor in the action library and will be available to all users in your workspace.

Editing a Custom Action

Any updates to this custom action will automatically affect every workflow where it is used.

In the left-hand side action panel, click the and select the ‘Edit custom action’.

Make the necessary changes and click the ‘Update’ button to apply the changes.

Using Custom Actions

Add a custom action to a step the same way as creating a regular step:

Drag and drop: To use a custom action, drag and drop the Action onto the canvas from the Action panel. At the top of the panel you can see the flow control actions and beneath them a list of external service providers. To see the available Actions, open a service.
Inline adding: Click on the box in the middle of the canvas. Search for the custom action in the search bar and select it.

Configuring Custom Action Inputs

When you create a Custom Action, you can configure or edit its YAML in the Advanced Settings YAML editor. Inputs determine which values users can provide when they add the Custom Action to a workflow. This allows you to make the Custom Action reusable while controlling which parts of its configuration can be changed.

Custom Action Input Types

When configuring a Custom Action, you can define the type of input users can provide. Select the input type based on the kind of value the parameter expects.

Parameter / Input Type	Description	Example
`string`	Single-line text input	URL, region, working directory, package name
`textarea`	Multi-line text input	Text or longer content
`bool`	Boolean value displayed as a checkbox	Enable/disable SSL verification
`dropdown`	Select one value from a predefined list	HTTP method, Python version
`dynamic_dropdown`	Dropdown populated dynamically using an autofill fetcher	GCP project
`code:python`	Python code editor	Python script
`code:bash`	Bash code editor	Bash script
`code:json`	JSON code editor	HTTP request body
`code:map`	Map/key-value code editor	HTTP headers, cookies
`name`	Defines the internal name of the parameter	`url`, `project`, `working_directory`
`display_name`	Defines the name displayed to users	`URL`, `Project`, `Working Directory`
`description`	Provides a description or instructions for the parameter	`The URL to communicate with.`
`required`	Determines whether the parameter is mandatory	`true` / `false`
`default_value`	Sets a default value for the parameter	`3.8.16`, `true`
`placeholder`	Provides guidance or an example in the input field	`Enter text to print...`
`options`	Defines the available values for a dropdown	`GET`, `POST`, `PUT`, `DELETE`
`autofill`	Defines how a dynamic dropdown is populated	`gcp.SearchProjects`
`group_type`	Determines whether the parameter appears under Basic or Advanced settings	`basic` / `advanced`
`var_picker_sections`	Makes specific Variable Picker sections available for the parameter	`files`
`icon_name`	Defines the icon associated with the parameter	`files`

Custom Action YAML example

action_to_run: http.getV2
connection_optional: false
parameters:
    - name: project
      display_name: Project
      description: Project ID for this request.
      required: true
      type: dynamic_dropdown
      group_type: basic
      autofill:
        fetcher: gcp.SearchProjects
    - name: region
      display_name: Region
      description: Name of the region scoping this request.
      required: true
      type: string
      group_type: basic
    - name: targetHttpsProxy
      display_name: Target Https Proxy
      description: Name of the TargetHttpsProxy resource to return.
      required: true
      type: string
      group_type: basic
action_to_run_param_values:
    retryOnRateLimit: "true"
    url: https://compute.googleapis.com/compute/v1/projects/{{params["project"]}}/regions/{{params["region"]}}/targetHttpsProxies/{{params["targetHttpsProxy"]}}?alt=json

Best Practices

When defining Custom Action inputs and parameters:

Expose only the values that users need to configure.
Use the input type that best matches the value the underlying custom action expects.
Use descriptive display names.
Choose an input type that matches the expected value.
Use required inputs only when they are necessary.
Use predefined options when the accepted values are known.
Provide defaults when there is a safe and useful default.
Add descriptions or placeholders when the expected input is not obvious.
Avoid exposing internal implementation details that users do not need to configure.
Test the Custom Action with both static and dynamic values before making it available to other users.

Workflow Basics

Triggers

Actions

Builder Copilot

Connections

Variables

Files

Templates

Publishing Workflows

Error Handling and Debugging

Workflow Management

Packs

Creating a New Custom Action

Editing a Custom Action

Using Custom Actions

Configuring Custom Action Inputs

Custom Action Input Types

​Creating a New Custom Action

​Editing a Custom Action

​Using Custom Actions

​Configuring Custom Action Inputs

​Custom Action Input Types

Creating a New Custom Action

Editing a Custom Action

Using Custom Actions

Configuring Custom Action Inputs

Custom Action Input Types