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:
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.
To successfully create workflows in Freestyle Orchestrator and run the workflows on a device, you must meet the following Workspace ONE UEM console, platform, and device-side client requirements.
Device-side client requirements: The Freestyle Orchestrator feature requires the following minimum version of VMware Workspace ONE Intelligent Hub installed on the target device:
The resources, conditions, and groups are the key components of a workflow. The workflow components are described in the following sections:
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 that are 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: The Re-install if removed option is supported on Windows 10 and macOS devices.
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 option to modify the default settings.
Note: For Windows devices, the Error Handling option is available for apps and profiles and for macOS devices the option is available only for applications.
The following table lists the error handling options and their default values.
Table 1-1. Resource Error Handling Options and Default Values
|Timeout||1440 minutes||Specify the maximum time to wait for a workflow step to complete.|
|Retry After||720 minutes||Specify the time interval after which the workflow steps with errors are retried.|
|Maximum Retries||4||Specify the maximum number of retries to reinstall a resource.|
|Backoff Rate||2||Specify a multiplier that determines the interval between subsequent retries.|
|Retry Interval||First retry after 1440 minutes, second retry after 2880 minutes, third retry after 4320 minutes, and fourth retry after 5760 minute||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 option, click the Restore To Default option.
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, sensor, and extended device inventory attributes data. 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.
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.
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.
Table 1-2. Sensor Data Type and Supported Condition Operators
|Sensor Data Type||Condition Operators Supported|
|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.
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.
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.
A time window is a schedule defined for your device during which updates and resource delivery can be scheduled as per your business needs. A time window can either be Maintenance hours or Business hours type and can either use the device local time or the UTC time zones.
An administrator can define one-time, daily, weekly recurring time windows during which apps, profiles, and scripts are downloaded and installed. For time windows, In or Not In Business hours and In or Not In Maintenance hours conditions are supported.
A time window condition differs from the other workflow conditions in following aspects:
Note: Currently, the time window condition is only supported on the Windows 10 devices.
For more information on creating a time window resource, see the Technical Preview: Make a Time Window and Apply it to Devices section in the Managing Devices guide.
An administrator can use the device attributes data, such as software, security, and system data to define a condition in a workflow. Using the attributes condition in the workflow you can filter and review any incoming extended device inventory data on the individual devices.
Note: The software, system, and security device attribute condition is supported on Windows devices and the software and system attribute condition is supported on macOS devices.
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.