Create and design a workflow in Jitterbit Integration Studio
Introduction
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 an application 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 endpoint's sales order object.
Workflows cannot be executed; only the operations within them can be executed. If a workflow is configured such that one operation leads to the chain execution of all other options in a workflow, you can effectively run all operations in the workflow.
You can also execute individual operations within workflows, which may lead to execution of operations in the same or other workflows. That is, if any operations are upstream of other operations in an operation chain, within or outside the workflow, the downstream operations will be kicked off accordingly. In this way, you can effectively run all operations within a project.
This page covers creating, renaming, reordering, and designing workflows.
Create a workflow
In a new project, the first workflow is already created and open on the design canvas by default. The new workflow shows an operation drop zone, which is a visual representation of where an operation can be placed:
To create additional workflows, click the new workflow icon along the top of the canvas to create new workflow tabs. When you create a new workflow, its default name is New Workflow. Subsequent new workflows with default names are appended with an incremented number in parentheses:
As you create new workflows, a blank canvas with an operation drop zone is shown, 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's Workflows tab (see Workflow actions menu in Project pane Workflows tab).
Each of these menu actions is available:
| Menu Item | Description |
|---|---|
 | Deploy deploys the workflow and its dependencies (see Workflow deployment). |
 | Configurable Deploy opens the deployment screen, where you can select workflows and operations to deploy (see Workflow deployment). |
 | Rename positions the cursor on the workflow name for you to make any edits as necessary. |
 | 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 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 (see Workflow dependencies and deletion). |
Rename a workflow
Workflows can be renamed from these locations:
- The project pane's Workflows tab (see Workflow actions menu in Project pane Workflows tab).
- The design canvas (see Renaming workflows, operations, and operation steps in Design canvas).
Workflow names within a project must be unique and must not contain forward slashes (/) or colons (:) to be valid.
Reorder workflows
Workflows can be reordered from the project pane's Workflows tab (see Reorder operations in Project pane Workflows tab).
Design a workflow
Workflows are designed by placing and configuring operations on the design canvas. Other design canvas elements such as drop zones, notifications, and lines connecting linked operations and notifications help you design workflows (see Design canvas elements in Design 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 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 contains three operations: Insert Workday Revenue Customer, Update Salesforce, and On Failure Email. The operation actions connecting these operations are configured such that, if successful, Insert Workday Revenue Customer kicks off the Update Salesforce operation; if the Insert Workday Revenue Customer operation fails, the On Failure Email operation is kicked off. If the Update Salesforce operation is kicked off and is successful, the chain execution is complete.
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 Insert Workday Revenue Customer appears as the second 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 each operation individually, but the execution of one operation would not lead to the execution of the others.
