check-circle-line exclamation-circle-line close-line

<

Freestyle Orchestrator is a low-code IT orchestration platform that gives an administrator the flexibility to create workflows to fit specific deployment requirements for their organization. Use workflows to distribute resources to devices in a sequence of steps, based on granular criteria. The resources can be applications, profiles, and scripts.

An administrator can use workflows to perform the following tasks:

  • Sequentially order the installation of each resource, such as applications, profiles, or scripts to meet specific installation requirements.
  • Deploy a resource based on select conditional criteria using sensors, application inventory data, and more.
  • Push a script to a device similar to resources like applications and profiles.
  • Perform state evaluation rules and apply logic to individual steps within a workflow or across the totality of a workflow.

The Freestyle Orchestrator guide covers the following topics:

Intended Audience

This guide is intended for administrators who want to create customized workflows designed to fulfill a specific goal. You can create workflows to sequentially install resources such as applications, scripts, and profiles, based on the conditions you define.

Prerequisites for Freestyle Orchestrator

To successfully create workflows in Freestyle Orchestrator and run the workflows on a device, you must meet the following UEM console, platform, and device side client requirements.

UEM Console Requirements

To use Freestyle Orchestrator, you need Workspace ONE UEM console version 2010 and later.

Platform Requirements

Freestyle Orchestrator feature supports Windows 10 and macOS platforms only.

Device Side Client Requirements

The Freestyle Orchestrator feature requires the following minimum version of VMware Workspace ONE Intelligent Hub installed on the target device:

  • Windows 10: VMware Workspace ONE Intelligent Hub 20.10
  • macOS: VMware Workspace ONE Intelligent Hub 20.10 and VMware Workspace ONE Workflow Engine 20.10 (only required for macOS)

Components of a Workflow

The resources, conditions, and groups are the key components of a workflow. The workflow components are described in the following sections:

  • Resource: Building block of a workflow which consists of an application, profile, or script.
  • Condition: Use conditions to create conditional requirements, based on data points from different sources, such as sensors, application inventory, file inventory, and so on.
  • Group: Use groups to deploy sets of resources that do not have any relative priority to each other but are deployed as one collective workflow step.

Resource

Resources in a workflow include applications, profiles, and scripts. You must add all the required resources to your system inventory before you can add these resources to your workflow. You can add resources to a workflow as required and define actions on each resource. You can define actions such as install applications, profiles, and run script on devices that are assigned to a workflow. Resources are installed on devices in the order defined in the workflow.

In a workflow, you can only select the resources that are available in the system inventory and you cannot add resources to the system inventory from the workflow. You can add resources into a workflow that are part of your current organization (OG) and or inherited from a parent OG. However, you cannot add resources managed at a child OG. To add the resources managed at your child OG, you have to create a workflow at the child OG level.

After adding a resource to a workflow, you can use the Re-install if removed option as an additional setting. This setting is found in the workflow Admin Panel, under the Additional Settings and is enabled by default. If a user deletes a mandatory resource from a device, the Re-install if removed option ensures that the resource gets installed again on the device.

Note: This feature is only supported for Windows 10 devices.

Resource Error Handling

For each resource, you can configure the resource behavior based on an error condition and define the necessary action to be taken during an error condition. In the workflow Admin Panel, under the Additional Settings, the Error Handling option is enabled by default. You can edit the Error Handling options to modify the default settings. The following table lists the error handling options and their default values.

Options Default Value Description
Timeout 10 hours Specify the maximum time to wait for a workflow step to complete.
Retry After 3 hours Specify the time interval after which the workflow steps with errors are retried.
Maximum Retries 2 Specify the maximum number of retries to reinstall a resource.
Backoff Rate 1.5 Specify a multiplier that determines the interval between subsequent retries.
Retry Interval First retry after 4.50 hours and second retry after 9.00 hours Specify the retry interval for the first and second retry in hours.
When Retries Are Exhausted Archive workflows You can perform the following actions when the retries are exhausted: Stop workflow or Skip Workflow Step.

Note: If you want to restore the default settings for the error handling options, click the Restore To Default option.

Condition

An admin can deploy a resource to a device based on certain conditions defined in the workflow. A condition can be defined for resources such as application, file, registry, and sensor. You can define the criteria based on a condition and can select a condition at any step in a workflow after the initial platform and smart group selection.

Each condition has a set of properties with a conditional operator and value that helps identify if a certain condition is met. Based on the result of a condition, whether a condition is met or not, the workflow transitions to the next step as defined in the workflow.

The following types of conditions are supported:

  • Complex condition: In a complex condition, you can define complex rules using the And or Or options within an If condition and evaluate multiple properties. Use the Then option to add more resources to a condition and the Else option is the last step in a condition. The following illustration describes an example of a complex condition.

  • Branches in condition: You can create different branches of conditions, check the value of each condition, and define further steps based on the value returned. You can have any number of branches within a condition and different results for the same condition are supported. The following illustration describes an example of branches in condition.

  • Nested condition: You can create a condition under a condition. For example, you can define a condition and if the value is "x" then define a specific action and if the value is "y" then define another action. Based on the value returned, you can define the action for a condition. The following illustration describes an example of a nested condition.

Note: A condition cannot be the last step in a workflow without any action associated with it.

After adding a condition to a workflow, you can configure the condition to be re-evaluated. In the workflow Admin Panel, under the Additional Settings, the Re-evaluate condition option is disabled by default. When the Re-evaluate condition option is enabled, the entire workflow is re-run every 15 minutes.

Note: When you enable the Re-evaluate Condition option for a script within a condition, the script re-runs on each evaluation. You must ensure that the script can run multiple times without any issue. You can implement a flag file or indicator to check if the script is running and to determine if the rest of the script operation must proceed.

Condition with Applications

For applications, the application exists or does not exist condition is supported. When the application exists or does not exist option is selected, the administrator can filter an application by specifying the application name and version. Based on the application inventory across devices, a preview of all the applications matching the condition is displayed.

In a condition, if operators such as greater than or less than are selected, and if the actual version on the device does not match the version input provided, then such devices are assumed to have not met the condition.

Note: An application condition can only be added for Windows devices.

An administrator can create a condition to check if an application name and a specific application version are installed on a device. When the condition is run on a device, the device first checks if the application is installed on the device and populates the results. In the results populated, the device checks if the specific application version is installed. There is no accurate versioning syntax for the applications. So, applying criteria like greater than or less than for alphanumeric application versions might not provide accurate results. However, when the actual workflow runs on the devices the system performs a more accurate search and populates the results.

Condition with Sensors

A sensor is a type of script deployed with the intent of collecting a single value of data from the device. You can use a sensor in an If, And, Or, Else, and Then conditions by searching for the sensor name in the Search field. The response data type configured for the chosen sensor determines the operator types that are available for the condition. The following table shows a list of operators available for each response data type.

Sensor Data Type Condition Operators Supported
Boolean Equals
Date Time After, Before, Between, Not Between
Integer Equals, Not Equal To, Less Than, Less Than or Equal To, Greater Than, Greater Than or Equal To, Between, Not Between
String Includes, Does Not Include, Equals, Starts With, Contains, Does Not Contain

For more information about creating Sensors, see the Collect Data with Sensors for macOS Devices topic in the macOS Device Management guide and the Collect Data with Sensors for Windows Desktop Devices topic in the Windows Desktop Device Management guide.

Condition with Files

For files, the file exists or does not exist condition is supported. In the file exists or does not exist condition you can filter the search results based on the File Path, Version Number, and file Modified parameters. The file path selection is mandatory in the file condition.

When the Modified on value for the file condition is used, you must ensure that the modified date is compared with the right format on the device side. If the administrator enters the date in the MM/DD/YYYY format and the device maintains the dates in the DD/MM/YYYY format, then the MM/DD/YYYY format must be converted to the DD/MM/YYYY format for comparison.

Note: A file condition can only be added for Windows devices.

Condition with Registry

For registry, the registry exists or does not exist condition is supported. The registry condition is only supported on the Windows devices. In the registry exists or does not exist condition you can filter the search results based on the Registry Path, Value Name, Value Type, and Value Data parameters.

Note: A registry condition can only be added for Windows devices.

Group

The group feature in a workflow enables an administrator to create a group and add all the required applications, profiles, or scripts to be installed on the devices simultaneously. For the resources within a group, the installation of the resources does not depend on the installation of any resource added in a workflow.

For example, the administrator can create a group to install all the productivity applications on the devices at the same time. In case, installation of any resource fails, then you can add a step in the workflow to continue the installation of the other resources or not install the other resources.