Skip to end of metadata
Go to start of metadata


A workflow is a collection of operations that is used as a tool to help segregate different parts of the project. By grouping operations together in a workflow, you may find it more convenient to organize process flows in a logical manner.

For example, one workflow might include a group of operations that retrieves a product object from Magento and writes the result to temporary storage, then reads from temporary storage and writes to a database, and records any errors to the operation log. Another workflow in the same project might be used to create a similar flow for the Magento sales order object.

This page covers creating, renaming, reordering, and designing workflows.

Creating a Workflow

In a new project, the first workflow is already created and open on the design canvas by default:

To create additional workflows, click the new workflow icon  along the top of the canvas to create new workflow tabs. As you create new workflows, a blank canvas opens, ready for you to design each workflow:

Workflow Actions Menu

After a workflow is created, menu actions for that workflow are accessible from the project pane. In the Workflows tab of the project pane, hover over a workflow name and click the actions menu icon  to open the actions menu.

Each of these menu actions is available:

  • Deploy: Deploys the workflow and any components it is dependent on (see Workflow Deployment).
  • Configurable Deploy: Opens the deployment screen, where you can select project components to deploy (see Workflow Deployment).
  • Rename: Positions the cursor on the workflow name in the project pane for you to make edits (see Renaming a Workflow below).
  • View Dependencies: Changes the view in the project pane to display any other parts of the project that the specific workflow is dependent on (see Viewing Dependencies under Workflow Dependencies and Deletion).
  • View Logs: Opens the operation log screen, which includes logs for any operations contained in the workflow that have been deployed and executed, as well as any operations linked from the workflow that have been deployed and executed (see Operation Logs).
  • Delete: Permanently deletes the workflow. Note that any project components used within the workflow, including operations, are not deleted by this action (see Deleting under Workflow Dependencies and Deletion).

Renaming a Workflow

By default, workflows are created with the name New Workflow. Workflows can be renamed from the project pane or from along the top of the design canvas.

Project Pane

In the Workflows tab of the project pane, hover over a workflow name, then click the actions menu icon  to open a menu of actions for that workflow. From the menu, select Rename:

This positions the cursor on the workflow name in the project pane for you to make any edits as necessary:

Design Canvas

Along the top of the design canvas, double-click the workflow tab. This positions the cursor on the workflow name in the workflow tab for you to make any edits as necessary:

Reordering Workflows

To reorder workflows, in the Workflows tab of the project pane, drag a workflow name to another location in the project tree:

This action has a cascading effect of renumbering the workflows "below" it in the tree and the operations contained within each workflow.

Designing a Workflow

Workflows are designed by adding design canvas elements to the design canvas. These include operations, notifications, operation action lines that connect linked operations and notifications, and any other element that is visually displayed on the canvas.

Other project components may not visually appear on the design canvas but can be used in support of operations. These components, such as activities, scripts, project variables, schedules, and file schemas, are reusable across operations and workflows.

As you add operations to a workflow, the layout renders automatically on the design canvas. Each operation is numbered sequentially and automatically organized on the design canvas, vertically stacking below the last operation on the design canvas. The numeric sequence of operations within a workflow is included within the operation title and adjusts automatically if you reorder operations. Likewise, the workflow order and numbering adjusts if workflows are reordered.

Regardless of the order of operations, each operation is at the same hierarchical level. The concept of "parent" and "child" operations applies only to operations that are chained with operation actions. (That is, if the execution of one operation leads to the execution of another operation, the first operation is said to be the parent and the second operation its child.) This relationship is visually indicated by the presence of lines connecting these operations within or outside the workflow.

It is not required for operations within a workflow to be chained with operation actions. You can, for example, create several operations in the same workflow that are not connected by operation actions at all. In this case, the execution of any of these operations does not lead to the execution of the other operations in the workflow, as they are not connected. Instead, you can choose to execute these operations individually, or connect them to operations in another workflow using operation actions.

Example 1

The example workflow below, called "1.0 Magento Products to Postgres," contains three operations: "1.0 Query Magento Products," "1.1 Upsert Postgres Products," and "1.2 Write Product Failure Info to Log." The operation actions connecting these operations are configured such that, if successful, operation 1.0 kicks off operation 1.1; if operation 1.0 fails, operation 1.2 is kicked off. If operation 1.1 is kicked off and is successful, the chain execution is complete; if operation 1.1 is kicked off and fails, operation 1.2 is kicked off.

Example 2

If the operations in the same workflow used in Example 1 were reordered, the same result would be produced. In this case, even though "1.2 Query Magento Products" appears as the last operation in the workflow, as long as it is executed first, the other operations in the chain are kicked off accordingly as a result of the configured operation actions.

Example 3

If the operations in the same workflow used in Examples 1 and 2 had their operation actions removed, this would break the chain of operations. You could execute operations 1.0, 1.1, or 1.2 individually, but the execution of any of these would not lead to the execution of any of the others.

On This Page

Last updated:  Nov 18, 2020

  • No labels