Inline Actions

You can embed subprocesses directly inside Workflows with inline actions. An inline action looks like a group of actions nested inside a block. Inline actions can be a series of actions unique to that Workflow, or another Workflow on your team.

screen readers look here

How inline actions work

There are two types of inline actions, iterators and conditional blocks.

  • Iterators are a block of actions that repeat multiple times, like sending an email for each row of a table. Check the following video for an overview of iterators:

  • Conditional blocks are a sequence of actions fixed into a group, so they鈥檙e more portable and easier to organize.

How to add inline actions

To create an iterator, add the Tables: Start Workflow for each row or Excel: Start process for each row action. See Use iterators to repeat actions multiple times to learn more.

To create a conditional block, add the Workflow: Start another Workflow action. See Organize processes with conditional blocks to learn more.

After adding these actions, you have the choice to Build inline or to Use Workflow by name, ID, or field. When you build inline, you鈥檙e adding a series of steps directly to the Workflow. When you Use Workflow by name, ID, or field, you鈥檙e embedding an existing Workflow from your team inline.

screen readers look here

What鈥檚 the difference between build inline and use Workflow by name, ID, or field?

You can create new inline actions and add your own steps to them, or reference an existing Workflow in a conditional block, and mirror its steps within your process.

screen readers look here

Build inline

This option gives you the power to configure the block, but without needing to manage a separate Workflow鈥攅verything is managed inline.

If you build inline, the subprocess inherits all default field permissions or retroactive field permission changes because it is managed by the parent Workflow.

Use Workflow by name, ID, or field

If you have a Workflow that鈥檚 already built and ready to start, you can reference it by name, ID, or field. This will be a good option for Workflow鈥檚 owned by another team member, or when processes are managed independently to take advantage of versioning, or so specific permissioning can be configured.

If you reference a Workflow by name, ID, or field, you are referencing a separate, published Workflow on your team. Edits to the inline actions affect the actual Workflow process you鈥檝e embedded.

  • Users with view permissions on a Workflow can add that Workflow, but cannot make changes to it. They will be able to use the steps as part of their process, set up conditions and dependencies, and see outputs, but cannot change the steps themselves.
  • Users with edit permissions on a Workflow can add that Workflow, and make changes to the process inline.

馃挕Tip: The published version of the Workflow is always used when added inline.

How to send values from an inline action back to the parent Workflow

All field values in inline actions are available in the parent Workflow.

  • When a iterator completes, it outputs a Successful Runs Data Table ID field. Every column in this table is a field from the subprocess. All data is accessible in this table.
screen readers look here
  • When a conditional block completes, it outputs fields as normal. Each field is accessible directly by the field reference name.

Get help with a problem or question

If something鈥檚 not working as expected, or you鈥檙e looking for suggestions, check through the options below.

Can I put an inline action inside another inline action?

You can nest as many inline actions as you wish. After the third level of nested actions, the actions are automatically collapsed and cannot be edited inline. To edit inline actions that is nested more than 3 levels, select it to open it in a full view.

screen readers look here
When configuring an inline action, how to I reference data from other actions?

All field values in inline actions are available in the parent Workflow.

  • When a iterator completes, it outputs a Successful Runs Data Table ID field. Every column in this table is a field from the subprocess. All data is accessible in this table.
screen readers look here
  • When a conditional block completes, it outputs fields as normal. Each field is accessible directly by the field reference name.
screen readers look here