Skip to main content
Blocks (formerly called actions) are the building components of Workflows. Each block handles a specific task, and chaining them together lets you run a sequence of operations that can reference contextual data from your workspace. Cortex offers a searchable library of blocks that can be added to your Workflows. See How is a Workflow structured for more information. To configure blocks through the API or in Workflow YAML, see the Workflow block configuration reference for each block’s fields and an example. Blocks are organized into the following categories:
  • Core blocks - Perform actions such as requiring a manual approval on a step within a Workflow.
  • Cortex blocks - Perform Cortex-based actions, such as getting Scorecard scores for an entity.
  • Integration blocks - Perform third-party integration actions such as creating a new GitHub repository or creating a new incident in ServiceNow.

​
Prerequisites

  1. You must have the Edit Workflows permission.
  2. An existing Workflow. If you haven’t yet created a Workflow, refer to Creating a Workflow and Configuring Workflow settings.
Every block in a Workflow must have a unique slug.

​
Configuring a Workflow block (basic)

  1. Click the + icon. The Search for blocks window opens.
  2. Search for and select the block you want to add to the Workflow.
  3. In the right pane, configure the block. Note that configuration options differ depending on the block.
  4. Click Save.
  5. Repeat Steps 1 - 4 as necessary.

​
Configuring a core block

Expand the tiles below for instructions on configuring each type of block.
A Branch allows you to set up to five conditional paths for a Workflow.
See an example demonstrating how to use a Branch block in Referencing Workflow states in a block.
Configuring a branch
  1. In the Search for blocks window, search for Branch, then click Insert.
  2. In the side panel, do the following:
    1. Block name - Optionally, change the name of the block. The name auto-populates based on the block name.
    2. Slug - Optionally, change the slug. The slug auto-populates based on the block name and is made up of letters, digits, and hyphens.
    3. Click Add path.
      1. Name - Enter a name for the conditional path.
      2. Slug - Optionally, change the slug. The slug auto-populates based on the block name and is made up of letters, digits, and hyphens.
      3. Path expression - Enter the path expression (compatible with CEL syntax). The path expression does not accept dashed values; if you reference a block’s slug that contains a dash, wrap the slug in quotes and square brackets.
        1. For example, if you want to reference a block with the slug slug-example, the expression would begin with actions["slug-example"].
        2. Autocomplete provides correctly formatted options based on the blocks defined in your Workflow.
      4. Click Save.
    4. Click Add fallback path.
      1. Name - Enter a name for the fallback path.
      2. Slug - Optionally, change the slug. The slug auto-populates based on the block name and is made up of letters, digits, and hyphens.
      3. Click Save.
  3. Optionally, add additional paths (up to 5).
  4. Click Save.
To add additional blocks that occur after the paths within your branch, click + below the Branch box in the Workflow editor.
How paths workThe paths defined run sequentially. The first path that returns true will execute, even if subsequent paths would also return true. The Workflow will then continue performing blocks in that path. You can also set a fallback path that will run if all other paths fail.Primary and nested branches function the same way.Nested branchesTo nest a branch, you must have a conditional path defined.
  1. In the Workflow visual, click the + that is branched off the original branch. The Search for blocks window opens.
  2. Search for Branch, then click Insert.
  3. Follow steps 2 - 4 above in Configuring a branch.
There are no limits on how many branches you can nest.
A Data transformation performs data transformations using jq. Except for the block name and slug, the only field required is the jq expression.
Use cases: Manipulate or format data between steps. For example, transform user input before sending it to an API or before using it in another Workflow block.Workflow examples: See an example demonstrating how to use a Data transformation block in Referencing Workflow states in a block.
Configure a data transformationTo configure a data transformation:
  1. Click Data transformation from the list of blocks.
  2. Enter a name.
    • The slug field will automatically pre-populate based on the name you enter.
  3. Enter a jq expression. This field can pass any sort of jq expression, as long as the variables and context are referenced differently.
    • Although you would typically use {} to template the context of your Workflow, in this field you’ll need to reference such values as jq query values.
  4. Click Save.
The HTTP request makes and records a request to a given URL, allowing you to integrate with external APIs or internal systems.For use cases requiring asynchronous operations (e.g. provisioning cloud resources or CI/CD pipelines), use the Asynchronous HTTP request block.
See an example demonstrating how to use an HTTP block in Scaffolding a new service with custom data based on user input.
Configuring an HTTP request
  1. Search for and select the HTTP request block.
  2. In the side panel, configure the block metadata:
    1. Block name - Optionally, change the name of the block. The name auto-populates based on the block name.
    2. Slug - Optionally, change the slug. The slug auto-populates based on the block name and is made up of letters, digits, and hyphens.
    3. Integration - Select a configured integration from the dropdown to authenticate the request instead of manually building headers. See Authenticating HTTP requests with an integration for the list of supported integrations.
      • The picker only lists integrations already configured for your tenant.
      • An admin must turn on the integration for HTTP blocks before the block can run. If the integration is turned off, or the block uses an HTTP method or endpoint that an admin hasn’t allowed, the block shows a warning banner. You can still save the Workflow, but the block fails when it runs. See Controlling which integrations HTTP blocks can use.
      • If the integration has more than one configuration, an alias picker appears so you can choose which one to use.
      • If a previously selected integration is no longer configured, Cortex keeps the existing value so the block stays editable, and shows a warning that the integration is missing.
      • To go back to manually configuring the full URL and headers, clear the Integration field. This also resets the alias picker.
    4. HTTP method - Select one of the following options from the dropdown: DELETE, GET, PATCH, POST, or PUT (required).
    5. URL - Enter a static URL or use a template to reference other blocks (required). If you selected an integration above, enter the URL as a relative path. Cortex automatically prepends the integration’s base URL to your request.
      • When you use an integration, the path can’t leave the integration’s base URL. Cortex rejects paths that contain . or .. segments, //, backslashes, or their URL-encoded forms (such as %2e, %2F, %5C, or %25).
      • If you use {{actions.url.outputs.result}}, for example, you can set the URL to the output of a JQ action. In this example:
        • .actions indicates a reference to a Workflow block
        • .url is the slug for the referenced Workflow block
        • .outputs is the location of the actual output of the JQ expression
        • .result is the result field where the output is stored
      • Because Mustache performs HTML escaping by default, special characters referenced in a value with two curly braces ({{}}) will be converted to their associated HTML encoding. For example, {{=}} becomes =. To reference a non-escaped value, use three curly braces ({{{=}}}).
    6. Headers - Click Add header to select one of the options provided, or enter your own.
      • Include an Authorization header and use a personal access token, unless you’re authenticating with a configured integration.
      • When using a secret with a header, prefix the secret with context. .
    7. Payload - This field only appears if you are using an HTTP request that sends a payload. The payload that you supply can also be templated and can reference an entity that the Workflow is being run with. Some additional steps are required to properly template raw JSON in the payload field:
      • Single primitive values work as expected. To add JSON objects or arrays, create a Data transformation block that accesses the relevant JSON and pipes it into the tojson built-in.
        • For example, .context.initiatedBy | tojson enables a user to add the full initiatedBy object () into an HTTP request payload. When templating this value, three curly braces are needed in order to reference a non-escaped value. In this example, if the Data transformation block has the slug transform-to-json, then the payload would include {{{actions.transform-to-json.outputs.result}}}.
  3. Click Save.
If using special characters when templating, make sure to include three curly braces to reference a non-HTML-escaped value.
The Asynchronous HTTP request makes and records a request to a given URL. This block pauses execution until a callback API is invoked or a timeout occurs, enabling long-running Workflows.
You can pass the callback URL to the external service by using the template variable {{callbackUrl}}. This can be passed as part of the URL, in a header, or in the payload.For example, when passing the variable in a URL, it would look like the following format: https://example.com/?url={{callbackUrl}}.Always use exactly two curly braces for {{callbackUrl}}. Cortex replaces this exact text when the block runs, so {{{callbackUrl}}} produces a broken URL.
Configuring an Asynchronous HTTP request
  1. Search for and select the Asynchronous HTTP request block.
  2. In the side panel, configure the block metadata:
    1. Block name - Optionally, change the name of the block. The name auto-populates based on the block name.
    2. Slug - Optionally, change the slug. The slug auto-populates based on the block name and is made up of letters, digits, and hyphens.
    3. Integration - Select a configured integration from the dropdown to authenticate the request instead of manually building headers. See Authenticating HTTP requests with an integration for the list of supported integrations.
      • The picker only lists integrations already configured for your tenant.
      • An admin must turn on the integration for HTTP blocks before the block can run. If the integration is turned off, or the block uses an HTTP method or endpoint that an admin hasn’t allowed, the block shows a warning banner. You can still save the Workflow, but the block fails when it runs. See Controlling which integrations HTTP blocks can use.
      • If the integration has more than one configuration, an alias picker appears so you can choose which one to use.
      • If a previously selected integration is no longer configured, Cortex keeps the existing value so the block stays editable, and shows a warning that the integration is missing.
      • To go back to manually configuring the full URL and headers, clear the Integration field. This also resets the alias picker.
    4. HTTP method - Select one of the following options from the dropdown: DELETE, GET, PATCH, POST, or PUT (required).
    5. URL - Enter a static URL or use a template to reference other blocks (required). If you selected an integration above, enter the URL as a relative path. Cortex automatically prepends the integration’s base URL to your request.
      • When you use an integration, the path can’t leave the integration’s base URL. Cortex rejects paths that contain . or .. segments, //, backslashes, or their URL-encoded forms (such as %2e, %2F, %5C, or %25).
      • If you use {{actions.url.outputs.result}}, for example, you can set the URL to the output of a JQ action. In this example:
        • .actions indicates a reference to a Workflow block
        • .url is the slug for the referenced Workflow block
        • .outputs is the location of the actual output of the JQ expression
        • .result is the result field where the output is stored
      • Because Mustache performs HTML escaping by default, special characters referenced in a value with two curly braces ({{}}) will be converted to their associated HTML encoding. For example, {{=}} becomes =. To reference a non-escaped value, use three curly braces ({{{=}}}).
    6. Headers - Click Add header to select one of the options provided, or enter your own.
      • Include an Authorization header and use a personal access token, unless you’re authenticating with a configured integration.
      • When using a secret with a header, prefix the secret with context. .
    7. Payload - This field only appears if you are using an HTTP request that sends a payload. The payload that you supply can also be templated and can reference an entity that the Workflow is being run with. Some additional steps are required to properly template raw JSON in the payload field:
      • Single primitive values work as expected. To add JSON objects or arrays, create a Data transformation block that accesses the relevant JSON and pipes it into the tojson built-in.
        • For example, .context.initiatedBy | tojson enables a user to add the full initiatedBy object () into an HTTP request payload. When templating this value, three curly braces are needed in order to reference a non-escaped value. In this example, if the Data transformation block has the slug transform-to-json, then the payload would include {{{actions.transform-to-json.outputs.result}}}.
    8. Timeout - Configure a timeout for this action. The maximum is 30 days and the minimum is 1 minute.
      • After a timeout, the block fails with the status timed_out. If you have notifications enabled, you’ll receive a notification if you initiate a Workflow and it times out.
  3. Click Save.
If using special characters when templating, make sure to include three curly braces to reference a non-HTML-escaped value. The exception is {{callbackUrl}}, which must always use two curly braces.
Handling the callbackOnce the Asynchronous HTTP request block runs, Cortex sends the configured request and pauses the Workflow. To resume execution, the external system must call the callback URL provided by Cortex and follow the required schema.The callback request must:
  • Use the POST method
  • Include a valid Cortex API key in the Authorization header (Bearer <token>)
  • Match the expected request body shape. Below is an example:
Set status to one of the following values:
  • SUCCESS - The external work finished. The block completes and the Workflow continues.
  • FAILURE - The external work failed. The block fails.
  • UPDATE - The external work is still in progress. The block keeps waiting for another callback, and Cortex records the message and response as progress.
See the full Cortex API reference for callback details.
If the callback is missing required fields, improperly formatted, or lacks authentication, Cortex will not accept it, and the Workflow will remain paused or fail.
Use a JavaScript block to insert custom code or add looping and other logic to your Workflows.The JavaScript runtime supports the ES2020 specification and has an implementation of Fetch API, allowing you to make HTTP requests directly in the script rather than needing to add an additional HTTP request block to your Workflow.
See an example demonstrating how to use a JavaScript block: Looping in a JavaScript block and returning a specified output
To test your block’s code locally, you can use Cortex’s JavaScript harness.Configuring a JavaScript block
  1. In the Search for blocks window, search for JavaScript, then click Insert.
  2. In the side panel, do the following:
    1. Block name - Optionally, change the name of the block. The name auto-populates based on the block name.
    2. Slug - Optionally, change the slug. The slug auto-populates based on the block name and is made up of letters, digits, and hyphens.
    3. JavaScript - Enter the script you want to run. The script must end with a return statement. The value from the return statement is exposed via outputs.result.
      • For example, in the script return {"a": 1, "b": 2}, the result can be referenced from subsequent blocks as actions.<SLUG>.outputs.result, and the value of a as actions.<SLUG>.outputs.result.a.
      • You can reference previous blocks and run context by accessing actions and context. For example, actions["jq"].outputs.result.
      • Learn more about referencing blocks and Workflow states here.
  3. Click Save.
If you want the block to fail, you can use the throw statement. For example:
A manual approval pauses the Workflow to get approval from a member of a given Team. Like with user inputs, the Workflow proceeds to the next block once it has been approved.Configuring a manual approval
  1. In the Search for blocks window, search for Manual approval, then click Insert.
  2. In the side panel, do the following:
    1. Block name - Optionally, change the name of the block. The name auto-populates based on the block name.
    2. Slug - Optionally, change the slug. The slug auto-populates based on the block name and is made up of letters, digits, and hyphens.
    3. From the Teams allowed to approve dropdown, select one or more teams who are allowed to approve the request from this block. Any member of a given team can approve the block.
      • To resolve the approving team dynamically instead of picking a fixed team, click the icon next to the field (Use value from previous step). The field switches to a text box where you can enter the path to a value from earlier in the Workflow. Start typing to see available paths, then select one, for example actions.user-input.outputs.team-name. Cortex resolves this path each time the Workflow runs, so the block can route approval to a different team depending on the inputs or entity involved in that run.
      • Enter the path on its own, without template syntax. Use actions.action-slug.outputs.field-name, not {{actions.action-slug.outputs.field-name}}.
      • Click the icon again to switch back to selecting a fixed team.
    4. Context for approvers - Optionally, enter a message to be displayed to approvers to help them make a decision. This message supports Mustache templating.
    5. Timeout - Optionally, enter the callback timeout. This value can be from one (1) minute to 30 days. The default value is 30 days.
  3. Click Save.
Pending approvalWhen a manual approval block is triggered, users that belong to teams designated as approvers will see Pending approvals at the top of their Workflows page.This section displays any blocks that are pending your approval. If manual approval actions exist within a Workflow, but do not require your approval, they will not appear here, even if you are designated to approve a different block in the same Workflow.You can open any Workflow in the pending approval list to Approve or Reject the block.Once all of your approval requests have been approved or rejected, this tab will disappear from the Workflows page.
The Run workflow block calls another Workflow from inside the current one, letting you chain Workflows together. You can pass values into the child Workflow’s variables, and you can have the block wait for the child Workflow to finish so later blocks can use its result.
The embedded Workflow and the parent Workflow have a strict parent‑child relationship to prevent accidental Workflow looping.
To configure a Run Workflow block:
  1. In the Search for blocks window, search for Run workflow from the list of blocks.
  2. Under Block name, enter a name. The slug field auto‑populates based on the name.
  3. From the Workflow drop‑down menu, select the Workflow to run.
  4. Optionally, from the Entity drop‑down menu, select an entity to run the target Workflow against. If the target Workflow is entity‑scoped and no entity is provided, it pauses for input at runtime.
  5. Optionally, toggle on Wait for completion to pause this block until the child Workflow run finishes. See Waiting for the child Workflow below.
    • When the toggle is on, you can set a Timeout from 1 minute to 30 days. When the timeout expires, the child Workflow run is cancelled. Without a timeout, the block waits until the child run finishes.
  6. Under Inputs, optionally enter a value for each of the child Workflow’s variables. See Passing inputs to the child Workflow below.
  7. Click Save.
Passing inputs to the child WorkflowThe Inputs section lists one field for each variable declared in the child Workflow’s settings. It only appears when the selected Workflow has variables.
  • Enter a fixed value, or a template that references earlier blocks or the run context, such as {{actions.form.outputs.appId}}.
  • The child Workflow reads each value as {{variables.<variable-slug>}}, the same way it reads a variable set through initialContext when the Workflow is run via the API.
  • Values keep the variable’s type. For example, 5 entered for a Number variable is passed as a number, and 123 entered for a String variable stays text.
  • Leave a field empty to use the variable’s default value.
  • If you select a different Workflow, the inputs are cleared.
Cortex checks inputs when you save the block. An input the child Workflow doesn’t declare, or a value of the wrong type, prevents the save. If the child Workflow’s variables change later, the parent Workflow can’t run until the inputs match again. Inputs the child no longer declares appear as read-only fields. Click the Remove icon next to each one, then save the block.
Waiting for the child WorkflowBy default, the block starts the child Workflow and the parent Workflow continues right away. The block’s only output is the child’s run ID, actions.<block-slug>.outputs.runId.When Wait for completion is on, the parent Workflow pauses at this block until the child run ends. While it waits, the parent’s run details show the child Workflow run. When the child finishes, later blocks can reference the following outputs:
  • actions.<block-slug>.outputs.runId - The child Workflow’s run ID.
  • actions.<block-slug>.outputs.status - The final status of the child Workflow run.
  • actions.<block-slug>.outputs.runResponse - The child Workflow’s run response.
  • actions.<block-slug>.outputs.variables - The child Workflow’s variables when the run ended, keyed by the child’s variable slugs. For example, actions.<block-slug>.outputs.variables.approved.
Autocomplete in later blocks suggests these paths using the child Workflow’s own variable names.Keep in mind:
  • If the child run fails, times out, or is cancelled, the Run Workflow block fails.
  • If the parent run ends before the child finishes (for example, it’s cancelled or rejected, or another block fails or times out), Cortex cancels the child run. This keeps approvals in the child Workflow from staying open.
Use case: Reuse one shared approval Workflow across many parent Workflows. Each parent passes its own details into the child’s variables, waits for the child to finish, then uses actions.<block-slug>.outputs.variables in a Branch block to decide what happens next.
The Scaffolder uses a Cortex Scaffolder template to perform a given function. You must have the Execute Scaffolder permission to configure a Scaffolder block.See the docs to learn about registering a Scaffolder template.
Use cases: Standardize and bootstrap service creationWorkflow example: See an example demonstrating how to use a Scaffolder block in Scaffolding a new service with custom data based on user input.
To configure a Scaffolder:
  1. Click Scaffolder from the list of blocks.
  2. Enter a name.
    • The slug field will automatically pre-populate based on the name you enter.
  3. Under Scaffolder template, select a template from the dropdown.
    • This dropdown pulls in all templates available from the Scaffolder page.
  4. Configure the remaining fields. The fields differ depending on the template’s specifications and available Git providers. The option to create a repo also may or may not be visible, depending on whether the template requires a pull request.
  5. Click Save.
If using the Scaffolder to create a new repo and the desired repo already exists, Cortex will surface an error and prevent the flow from continuing.
Define Scaffolder template overridesYou can also define Scaffolder template overrides for a block — these will override template fields with output variables from a previous Workflow step, or from the context of the Workflow.To add an override:
  1. In the bottom of the block configuration, click Add variable.
  2. In the override variable modal, click the Variable dropdown to select the Scaffolder template fields to override. Note that the options in this dropdown will be pulled from fields in the Scaffolder template you selected in the first step. workflows 12
  3. Under Path, enter the path to the actual value we want in the Workflow.
    • For example, if you wanted to override the Project name variable for a Scaffolder with the tag of the entity you’re running, the path would be context.entity.tag — that will obtain and supply the value.
  4. If you want to override the options that are available to a user running the Workflow, toggle on Is value override.
    • For example, if you wanted to restrict the project name to some set of values based on a particular HTTP fetch, you would toggle this setting on.
    • When toggled on, the value being grabbed in lieu of project_name is the value of the variable. When toggled off, the value grabbed would be the option provided for that variable, i.e. the project name.
Running a workflow with a Scaffolder stepWhen you run a workflow with a Scaffolder block, the Scaffolder will prompt you for user input. Some fields, such as Commit message and Pull request title, only appear if your Scaffolder step creates a Pull Request rather than a repository.After the inputs are provided, the Scaffolder will run. When the run is complete, you will see a link to the newly-created repository and the entity in Cortex.
Note: For GitLab, Azure DevOps, and Bitbucket, the branch name entered when running this block must match the default branch of the target repository in your Git provider.
The User input block pauses the Workflow and prompts the user for specific inputs. Once inputs are entered, the Workflow proceeds to the next block.
Use cases: Collect new developer details (name, email, GitHub username) during onboarding, or gather IAM policy requirements before creating a policy in AWS.Workflow example: Onboard a new developer > Collect user information in User input block > Subsequent actions use this data to create accounts and send notifications.See examples demonstrating how to use a User Input block in Looping in a JavaScript block and returning specified output and Scaffolding a new service with custom data based on user input.
Note that users with the Edit Workflows permission are inherently able to obtain secret values using complex data transformation on secrets or echoing services.
To configure a user input block:
  1. In the Workflow, click the User input block.
  2. In the User input side panel, do the following:
    1. Under Block name, enter a name for the block.
    2. The Slug field automatically pre-populates based on the block name.
    3. Click Add user input.
  3. In the Add input side panel, do the following:
    • Under Name, enter a name for the input field (required).
    • The Key field automatically pre-populates based on the name (required). This must be unique across fields in a given user input block.
    • Under Description, enter a description of the input field.
      • You can use templating to reference previous block outputs in the description. For example, if a previous step creates a Pull Request and outputs the URL of the PR, you might want to reference it in the description of a subsequent user input step using a template: Confirm that you have merged the Pull Request created here: {{ actions.<block-slug>.outputs.response.gitURL }}
    • From the Type drop-down menu, select an input type:
      • Date - Date in YYYY-MM-DD format. If you select this option, configure the fields that appear:
        • Date format - Select Date or Date and time
        • Default value - Enter the default date value
      • Number - A numerical value. If you select this option, configure the fields that appear:
        • Number format - Select Integer or Decimal
        • Minimum value - Set the minimum number value
        • Maximum value - Set the maximum number value
      • Paragraph - Multi-line, freeform text
      • Secret - Capture a secret value
      • Select - Manually configured or predefined data selection. If you select this option, configure the fields that appear:
        • Data source - Select one of the following:
          • Cortex entity - Filter which entities users can select. If you don’t set filters, all entities are available. You can set filters under the Filtering options section. Optionally, toggle on the following:
            • Allow multiple - If enabled, multiple selections are accepted.
            • Limit to workflow runner’s entities - If enabled, the user running the Workflow will only see their owned entities as options during this user input step.
              • To only show teams the user belongs to, enable this toggle and select team from the Entity type drop-down menu.
          • Cortex user - Filter by teams and users to set the available options. Without filters, all Cortex users and teams are available. You can set filters under the Filtering options section. Optionally, toggle on the following:
            • Allow multiple - If enabled, multiple selections are accepted.
          • Manual - Manually define each option for the input. You can select any of these defined options as the default value. Optionally, toggle on Allow multiple to allow multiple selections.
            • Click Add option to add values and labels. If a label is not defined, the value is used as the label.
          • Slack channels - Choose to include or exclude one or more Slack channels from the available options. The default values include all Slack channels registered in Cortex. Optionally, toggle on Allow multiple to allow multiple selections.
            • Select the channels you want to include from the Slack channels drop-down menu.
      • Text - Short, freeform text
      • Toggle - Boolean value
      • Nested form - Users can enter data multiple times for the inputs you configure. If you select this option, configure the fields that appear. See Additional steps for the ‘Nested form’ type below for more information.
        • Data type - Select one of the following:
          • Object (default) - Each item is a structured record made up of the sub-fields you define below. Use this when every entry needs more than one property, such as a list of database instances that each have a name and a size.
          • Single value - Each item is a single value of one type. Use this to collect a simple list, such as admin emails, allowed IP addresses, or port numbers. When you select Single value, configure the Value type that appears:
            • Text - A single line of text
            • Paragraph - Multi-line, freeform text
            • Number - A numeric value. Choose Integer (whole numbers) or Decimal (allows decimals), and optionally set a minimum and maximum value.
            • Toggle - A true or false value
            • Date - A date in YYYY-MM-DD format
        • Set the number of elements - Toggle on to to let the user add or remove entries when running the Workflow. Set a minimum and maximum count; the minimum also serves as the default number of elements.
  4. Depending on the input type you selected in the previous step, you may need to configure the following:
    1. Under Placeholder, enter text to display when a field is empty.
    2. Under Default value, enter a value that automatically populates the field.
    3. Under Validation regex, set validation options for the input field. If you chose the secret type, enter the secret value needed to run this action.
    4. Under Path to override value, enter the previous block output path to override the value of a given input.
      • For example, if the key is name, entering actions.name-action.outputs.name in the previous block output path field will use the output from a previous step as the name.
    5. Optionally, toggle on Is override value editable. If enabled, users can edit the override value before continuing to execute the Workflow.
  5. Click Add input. After clicking Add input, you’re directed back to the User input side panel.
  6. Optionally, toggle on Validation logic. See Adding validation logic below for more information.
  7. Click Save.
Additional steps for the ‘Nested form’ typeA nested form lets users provide an arbitrary number of responses. Each response can either be a sub‑form with multiple fields (one or more inputs per row) or a single value (one string per row), depending on the Data type you choose. For example, a data warehouse form might collect a name and size for each database instance (Object), while an allow‑list form might collect a flat list of email addresses (String).Cortex supports up to 5 layers of nesting in Object nested forms using the Nested form input. String nested forms cannot be nested further, as each row is a leaf string.‘Nested form’ type output:
  • When the data type is Single value, the block output is a flat JSON array of the chosen type, referenced as actions.<slug>.outputs.<key> . For example, ["jenny", "luis"] for Text or [8080, 8443] for an Integer.
  • When the data type is Object, the output is an array of objects, for example [{ "name": "db-1", "size": 100 }, { "name": "db-2", "size": 200 }].
Adding validation logicDefine custom JavaScript validations on Workflow input fields to ensure users complete required fields and meet your standards. For example, you might validate that a new repository follows your naming conventions, or that the chosen name is unique.To add validation:
  1. In the User input side panel, toggle on Validation logic.
  2. Enter a JavaScript expression.
    • Call validator.addInputViolation to display an error on a specific input, and validator.addGlobalViolation to display an error at the top of the form.
      • If you call validator.addInputViolation with an invalid input key, an error displays at the top of the form.
Example JavaScript expressionThis expression requires the role value to be at least three characters and the selected date to be in the future. It displays input-specific errors for the user role and target date inputs, and a global error if any field is invalid:
The validation logic runs when you submit your response to the user input, flagging any issues immediately. With the example above, errors appear if the user role value is under three characters or the target date is not in the future.
This block allows you to set or update specific variables during a Workflow. The variables must be declared in the Workflow’s basic settings.To configure a Set variable(s) block:
  1. Click Set variable(s) from the list of blocks.
  2. Enter a slug for the block.
    • The slug field will automatically pre-populate based on the name you enter.
  3. In the Variable dropdown, select the variable you want to set/update.
  4. Define how you want to set the variable’s value. You can use a direct reference or use JavaScript.
  5. Optionally, set additional variables.
  6. Click Save.

​
Authenticating HTTP requests with an integration

In the HTTP request and Asynchronous HTTP request blocks, you can authenticate a request with an integration that’s already configured in your Cortex workspace. You don’t need to build an Authorization header yourself. Cortex uses the integration’s credentials and prepends its base URL to the relative path you enter in the URL field. The Integration dropdown only shows integrations that are configured in your workspace. Before a block can run with an integration, an admin must also turn that integration on for HTTP blocks. See Controlling which integrations HTTP blocks can use. You can authenticate HTTP requests with the following integrations:
The block authenticates with the integration’s API token, so it has the same permissions as that token. Check the token’s scopes before you let Workflow editors call an integration’s API. To limit what HTTP blocks can do with an integration, see Controlling which integrations HTTP blocks can use.

​
Controlling which integrations HTTP blocks can use

Admins control which integrations HTTP blocks can authenticate with, which actions they can take, and which API endpoints they can’t call. Cortex checks these settings each time an HTTP request or Asynchronous HTTP request block runs, before it fetches the integration’s credentials or sends the request. Prerequisites
  • You must have the Edit Settings permission.
  • The integration must be configured in your Cortex workspace.
Default settings
  • An integration that hasn’t been turned on is off, so new integrations start off.
  • Workspaces created before these settings were added have the following integrations turned on: Azure DevOps, Bitbucket, Cortex, GitHub, GitLab, Google Cloud, Harness, Jenkins, LaunchDarkly, PagerDuty, ServiceNow, and Slack. Turn on any other integration before you use it in an HTTP block.
  • When an integration is turned on, all actions are allowed and no endpoints are blocked.

​
Turning integrations on or off

  1. From the main sidebar, click your avatar in the bottom-left corner.
  2. Click Settings.
  3. From the Settings menu, expand Workflows, then select HTTP block.
    The 'HTTP block' tab in the settings sidebar.
    • The page lists every supported integration in alphabetical order. Integrations that aren’t installed in your workspace are locked. Click Install next to one to set it up.
    • To hide integrations you haven’t installed, select Show only installed.
  4. Use the toggle next to an integration to turn it on or off for HTTP blocks.
If a Workflow uses an integration that’s turned off, the block shows a banner in the Workflow editor, and the run fails with the message “<Integration> integration is disabled for HTTP blocks. Integrations can be enabled in settings.”

​
Limiting allowed actions

By default, HTTP blocks can send any HTTP method to an integration that’s turned on. To limit them, for example to read-only access:
  1. On the HTTP block settings page, click Configure next to an integration that’s turned on.
  2. In the side panel, under Allowed actions, toggle each action on or off:
    • Create - POST requests
    • Read - GET requests
    • Update - PUT and PATCH requests
    • Delete - DELETE requests
  3. Click Save.
The settings page shows the allowed actions for each integration as badges. If a block uses a method that isn’t allowed, the block shows a banner in the Workflow editor, and the run fails with a message such as “DELETE requests to Jira are not allowed for HTTP blocks. Allowed actions can be changed in settings.”

​
Blocking specific endpoints

Block a single endpoint when an action is fine in general but one call is hard to undo, such as deleting a Scorecard.
  1. On the HTTP block settings page, click Configure next to an integration that’s turned on.
  2. In the side panel, under Blocked endpoints, click Add rule.
  3. Do the following::
    • Select a method from the dropdown.
    • Enter the path to block, starting with /. Use a placeholder such as {tag} for a variable part of the path, for example /api/v1/scorecards/{tag}. The path can’t contain ? or ...
    • Optionally, select the Include sub-paths checkbox to also block every path under the one you entered.
    • Optionally, but highly recommended, explain why the endpoint is blocked. Cortex shows the reason when a run is blocked.
    • Click Add rule.
  4. Optionally, use Test a request to check whether a method and path would be blocked or allowed.
  5. Click Save.
Endpoint rules match the path relative to the integration’s base URL, so one rule covers both cloud and self-hosted instances (for example, GitHub and GitHub Enterprise). If a block with a fixed path matches a rule, it shows a banner in the Workflow editor. Cortex also checks paths built from templates when the block runs, and fails the run if the path matches a rule.

​
Configuring an integration block

Prerequisites
  1. Ensure the integration is installed in your Cortex workspace.
  2. Ensure the integration is configured with the correct permissions. Refer to Integrations for more information.
If an integration supports multiple configurations, you’ll be prompted to select the configuration alias to use with the block. The block authenticates using the selected configuration, so ensure that you select the configuration with the appropriate permissions.
Cortex provides prebuilt blocks to perform a variety of actions for the following integrations. Expand an integration below to view available blocks.
  • Attach role policy
  • Create EC2 security group
  • Create IAM group
  • Create IAM role
  • Create S3 bucket
  • Describe EC2 instances
  • List buckets
  • Put role policy
  • Run EC2 instances
  • Create a branch
  • Create branch policies
  • Create file
  • Create repository
  • Delete a branch
  • Delete branch policy
  • Delete file
  • Delete repository
  • Fetch latest commit ID
  • Get a branch
  • Get all branches
  • Get branch policy
  • Get file
  • Get pipeline
  • Get pipeline run details
  • Get repository
  • List branch policies
  • List pipeline runs
  • List pipelines
  • List repositories
  • Rename a branch
  • Run pipeline
  • Update branch policies
  • Update file
  • Create repository
  • Get file
  • Update branch protection
  • Add label to pull request
  • Add user to org
  • Add user to team
  • Create a branch
  • Create deployment
  • Create or update custom property values
  • Create or update a file
  • Create a pull request
  • Create a pull request comment
  • Create reference (or branch)
  • Create release
  • Create repository
  • Create team
  • Delete a branch
  • Delete branch protection rules
  • Delete file
  • Delete team
  • Find files
  • Get a branch
  • Get branch protection rules
  • Get commit
  • Get deployment
  • Get file
  • Get release by tag
  • Get team
  • Get team membership
  • List branches
  • List commits
  • List deployments
  • List organization members
  • List releases
  • List repositories
  • List team members
  • List teams
  • Merge a branch
  • Remove user from organization
  • Remove user from team
  • Rename a branch
  • Trigger workflow (see additional note below)
  • Update branch protection rules
  • Update repository
When using the Trigger workflow block:The block triggers a run of a GitHub Actions workflow in a given repository. The response output includes fields that identify the triggered run:
  • workflow_run_id - The ID of the GitHub Actions run that was triggered.
  • run_url - The GitHub API URL for the run.
  • html_url - The link to the run in the GitHub UI.
You can reference these fields from later blocks, for example {{actions.<block-slug>.outputs.response.workflow_run_id}}. This is useful for monitoring the triggered run, such as polling the GitHub API from a JavaScript block until the run completes before the Cortex Workflow continues.Some GitHub instances, such as older GitHub Enterprise Server versions, don’t return run details when a workflow is dispatched. In that case the block still succeeds, but response and its run detail fields are null.
  • Archive project
  • Create approval rule
  • Create branch protection
  • Create file
  • Create pipeline schedule
  • Create project
  • Create project access token
  • Create project variable
  • Create push rule
  • Delete approval rule
  • Delete branch protection
  • Delete file
  • Delete pipeline schedule
  • Delete project
  • Delete project variable
  • Delete push rule
  • Get approval configuration
  • Get approval rule
  • Get file
  • Get pipeline schedule
  • Get project
  • Get project variable Get protected branch
  • Get push rule
  • List approval rules
  • List pipeline schedules
  • List project access tokens
  • List project variables
  • List protected branches
  • Revoke project access token
  • Rotate project access token
  • Run pipeline
  • Unarchive project
  • Update approval configuration
  • Update approval rule
  • Update branch protection
  • Update file
  • Update pipeline schedule
  • Update project
  • Update project variable
  • Create project
  • Delete project
  • Get project
  • List projects
  • Update project
  • Execute pipeline
When using the Execute pipeline block:The block runs a Harness pipeline in a given organization and project. It requires an Organization identifier, a Project identifier, and a Pipeline identifier, and optionally accepts Runtime inputs as YAML and Notes describing the run.The block’s output includes:
  • execution_id - The identifier of the Harness pipeline execution that was started.
  • status - The execution status Harness reported at trigger time.
  • response - The full response object from Harness.
The block is synchronous, so it returns Harness’s acknowledgment of the run rather than the pipeline’s final result. The pipeline runs as the owner of the API key in the selected Harness configuration, not as the person who started the Workflow.For more detail, including guidance for internally hosted instances, see Using the integration for Harness.
  • Create incident
When using the Create incident block:The block creates a new incident in incident.io and maps it to the Cortex entity you specify. The incident’s custom fields come from that entity’s incident.io registrations. For more information, see Connecting entities to incident.io.The block accepts the following inputs:
  • Entity tag (required) - The tag of the Cortex entity to associate with the incident.
  • Name (required) - The name of the incident.
  • Summary (optional) - Additional information about the incident.
  • Severity (required) - The name of an incident.io severity, e.g. Minor.
  • Status (optional) - The name of an incident.io status. Leave it empty to use your incident.io default status.
  • Incident type (optional) - The name of an incident.io incident type. Leave it empty to use your incident.io default incident type.
  • Mode (optional) - The incident mode: Standard, Retrospective, Test, or Tutorial. Defaults to Standard.
Severity, status, and incident type are customized in each incident.io account, so Cortex can’t list their values in a dropdown. Enter each value as text. It must match a name that’s permitted in your incident.io configuration, but it isn’t case-sensitive. When the Workflow runs, Cortex validates these values against the incident.io configuration you selected. If a value isn’t valid, the block and the Workflow run fail, and no incident is created.To create incidents, your incident.io API key needs the Create incidents scope. See Configuring incident.io.
  • Run a build
  • Run a build with parameters
  • Create a feature flag
  • Delete a feature flag
  • Get feature flag
  • List feature flags
  • List projects
  • Toggle feature flags
  • Update a feature flag
  • Send message
  • Create escalation policy
  • Create incident
  • Create schedule
  • Create service
  • Create team
  • Delete escalation policy
  • Delete schedule
  • Delete service
  • Delete team
  • Get escalation policy
  • Get schedule
  • Get service
  • Get team
  • List escalation policies
  • List incidents
  • List schedules
  • List services
  • List teams
  • List users
  • Schedule override
  • Update escalation policy
  • Update schedule
  • Update service
  • Update team
  • Create incident
  • Create record
  • Delete incident
  • Delete record
  • Get incident
  • Get record
  • Get user by email
  • Get user information
  • List groups
  • List incident categories
  • List incident subcategories
  • List incidents
  • List records
  • List users
  • Update record
  • Get channel info
  • Get user by email
  • List channels
  • List members in channel
  • List users
  • Send message
When using a Slack block:
  1. Ensure the Cortex AI assistant is added to the appropriate Slack channel.
    • If the AI assistant isn’t in the channel, you’ll receive the following error: Cannot send message to Slack channel without invitation. To resolve the error, do one of the following:
      • Invite the AI assistant to the specific channel OR
      • Reinstall the Slack integration to get the latest scopes, which allows posting to public channels without the AI assistant needing to be a member
  2. Ensure the AI assistant has the correct permission(s) scoped:
    • If the channel is public and the install is up to date (has chat:write.public), the bot can post without being a member.
    • If the channel is private, the bot needs chat:write and must be invited to the channel.
To configure an integration block:
  1. Click the + icon. The Search for blocks window opens.
  2. Search for the block you want to add to the Workflow.
  3. Select a block to view its details, including any permissions required for it to run correctly.
  4. Click Configure. The block is inserted into your Workflow, and a configuration form appears in the side panel.
  5. In the side panel, configure the block metadata:
    • Block name - Optionally, change the name of the block. The name auto-populates based on the block name.
    • Slug - Optionally, change the slug. The slug auto-populates based on the block name and is made up of letters, digits, and hyphens.
    Metadata differs depending on the block. Any of these inputs can accept dynamic values using Mustache syntax ({{ ... }}). For fields that aren’t text-based, click the path icon on the right of the input to switch into templating mode.
     Mustache templating displayed when configuring a Workflow block.
  6. Click Save.

​
Duplicating a block

There may be an instance where you want to repeat a task within your Workflow. Follow the steps below to duplicate a block.
  1. Locate the block you want to duplicate.
  2. Click the Overflow icon on the right side of the block.
     The 'Overflow menu' icon on a block.
  3. Click Duplicate block. A copy of the block is placed in the Workflow.
  4. Optionally, hover over the block and use the grip icon to drag it to a new position in the Workflow.

​
Using request signing with Workflow blocks

Refer to the documentation for using request signing with Workflow blocks.

​
Referencing a Workflow state in a block

Refer to the documentation for referencing a Workflow state in a block. Next step: Running a Workflow
Last modified on October 19, 2026