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 plus icon  along the top of the canvas to create new workflow tabs. As you create new workflows, a blank canvas will open ready for you to design each workflow:

Accessing Menu Actions

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: This deploys the workflow and any components it is dependent on (see Workflow Deployment).
  • Configurable Deploy: This opens the deployment screen, where you can select project components to deploy (see Workflow Deployment).
  • Rename: This positions the cursor on the workflow name in the project pane for you to make edits (see Renaming a Workflow below).
  • View Dependencies: This 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: This 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: This is used to permanently delete the workflow and any operations within the workflow. Note that other project components used as steps in the operation or in support of the operation will not be deleted by this action (see Deleting under Workflow Dependencies and Deletion).
  • Add to group: This opens a prompt to create a new custom group or to add the workflow to an existing group. Custom groups are an organizational tool to help organize a project (see Component Groups).

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 will 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 will kick off operation 1.1; if operation 1.0 fails, operation 1.2 will be 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 will be 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 will be 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:  Jun 11, 2020

  • No labels