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 chained 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 are automatically numbered sequentially in the order they appear: 1.0, 2.0, etc.
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 chained 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. If using a project's Designer setting Auto-number operations 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 vertical order of operations on the design canvas, each operation is at the same hierarchical level. The concept of "parent" and "child" operations applies only to operations that are chained together.
Operations within a workflow do not need to be chained. Running unchained operations does not trigger the execution of the other operations in the workflow. You can choose to run these separate operations individually or chain them to operations in another workflow.
Operation chains
Operations can be chained through the use of operation actions, the Invoke Operation (Beta) tool, or the RunOperation function. All chaining methods call other operations, allowing for complex logic within a workflow.
Chained operations called with any of the above methods are considered children to the caller or parent operation. When using operation actions or the RunOperation function, this relationship is visually indicated by lines on the design canvas connecting these operations within or outside a workflow.
Chained operations run synchronously by default. To maximize concurrency with agent groups containing two or more agents, an asynchronous option exists when using the Invoke Operation (Beta) tool or the RunOperation function.
Data scope and availability
In the context of data element scope in operation chains, child operations are "downstream" of their parents. Certain data elements defined "upstream" of an operation can affect it and any of its children:
- Global, project, and Jitterbit variables are all accessible downstream of their definitions in an operation chain.
- Variable and Temporary Storage endpoint values are also accessible downstream of their definitions in an operation chain.
- Caches generated by the
CacheLookupandSfCacheLookupfunctions are valid downstream of their calls for the duration of the operation chain.
Data can also be shared between distinct operation chains without requiring a parent-child relationship:
- Temporary Storage endpoints can be used to share data between multiple, distinct operation chains in a single-agent environment.
- Cloud caching functions can be used to share data between multiple, distinct operation chains in a multiple-agent environment.
Status and log considerations
The operation status is displayed for the first 6 operations that are run within an operation chain. The status for any remaining operations can be viewed in the operation logs.
Validation pattern considerations
For the operation validation patterns listed below, if an operation chain contains an API Request or API SOAP Request activity, it must be the only one in the operation chain. It must also be the source of the first operation. This means no other operation may call this operation from another operation.
- Archive pattern
- Transformation pattern
- Two-target archive pattern
- Two-target HTTP archive pattern
- Two-transformation pattern
Chain cancellation
Operation chains can be cancelled using the CancelOperationChain function when using operation actions or the Cancel operation chain if operation fails error handling option when using the Invoke Operation (Beta) tool.
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.
