Freestyle Orchestrator is a low-code IT orchestration platform that empowers administrators to create customized workflows tailored to their organization’s specific deployment needs. With Freestyle Orchestrator, workflows can be designed to distribute resources to devices in a sequence of steps, based on granular criteria.
The resources managed through workflows can include applications, profiles, and scripts. The availability of certain resources within Freestyle Orchestrator may vary depending on your Workspace ONE edition. For instance, scripts and sensors are only accessible to customers with the Workspace ONE Advanced, Workspace ONE Enterprise, or Workspace ONE Desktop Essentials editions. Additionally, the Freestyle Orchestrator feature for mobile devices supports only resources like applications and profiles.
Note: The Freestyle Orchestrator feature is available only for the SaaS version of Omnissa Workspace ONE UEM.
The Freestyle Orchestrator feature is supported on both desktop and mobile devices. Based on where the feature is supported, an administrator can use workflows to perform certain tasks.
When the Freestyle Orchestrator feature is supported on desktop, an admin can 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.
- Define state evaluation rules and apply logic to individual steps within a workflow or across the entire workflow.
- Run workflows automatically upon publishing, or deploy on-demand by displaying as an icon within the Intelligent Hub catalog.
- Prioritize entitlements with an onboarding deployment, to ensure all other entitlements are paused until critical resources are installed
When the Freestyle Orchestrator feature is supported on mobile, an admin can perform the following tasks:
- Sequentially order the installation of each resource, such as applications and profiles, to meet specific installation requirements.
- Deploy a resource based on select conditional criteria using device attributes, application or profile inventory data, and more.
- Run workflows automatically upon publishing, or deploy on-demand by displaying as an icon within the Intelligent Hub catalog.
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 based on the conditions you define.
Prerequisites for Freestyle Orchestrator
To create and run workflows in Freestyle Orchestrator on desktop and mobile devices, you must meet the requirements described in the following sections.
Prerequisites for Freestyle Orchestrator Desktop
To successfully create workflows in Freestyle Orchestrator and run the workflows on a desktop device, you must meet the following Workspace ONE UEM console, platform, and device-side client requirements.
-
UEM console requirements: To use Freestyle Orchestrator, you need Workspace ONE UEM console version 2206 and later.
-
Platform requirements: Freestyle Orchestrator feature supports Windows and macOS platforms only.
-
Device-side client requirements: The Freestyle Orchestrator feature requires the following minimum version of Workspace ONE Intelligent Hub installed on the target device:
- Windows: Omnissa Workspace ONE Intelligent Hub 22.06
- macOS: Omnissa Workspace ONE Intelligent Hub 22.06 and Workspace ONE Workflow Engine 22.06 (only required for macOS)
Prerequisites for Freestyle Orchestrator Mobile
To successfully create workflows in Freestyle Orchestrator and run the workflows on a mobile device, you must meet the following requirements.
-
UEM console requirements: To use Freestyle Orchestrator for Android Enterprise and iOS platforms, you need Workspace ONE UEM console version 2410 and later.
-
Device-side client requirements: For Android devices, Workspace ONE Intelligent Hub version 2411 must be installed on the target device. This is not a requirement for iOS devices.
-
Modern stack requirement: Enabling modern stack is essential.
Note: Freestyle Orchestrator is only compatible with Android Enterprise, and not Android Legacy.
Components of a Workflow
The components supported in a workflow vary for Freestyle Orchestrator desktop and mobile. The following sections describe the key components of a workflow for desktop and mobile devices.
Components of a Workflow for Freestyle Orchestrator Desktop
The resources, conditions, and groups are the key components of a workflow. The workflow components are described in the following sections:
-
Action: Use action to install or remove an app or profile, install scripts, enable offline domain join on workflows and so on.
-
Condition: Use condition to create conditional requirements, based on data points from different sources, such as sensors, application inventory, file inventory, and so on.
-
Group: Use group to deploy sets of resources that do not have any relative priority to each other but are deployed as one collective workflow step.
Action
In a workflow, an admin can perform actions such as add or remove an app, profiles,or scripts to a worklfow. 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 must 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 section. 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.
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 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
| Options | Default Value | Description |
|---|---|---|
| Timeout | 120 minutes | Specify the maximum time to wait for a workflow step to complete. |
| Retry After | 15 minutes | Specify the time interval after which the workflow steps with errors are retried. |
| Maximum Retries | 1 | 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 30 minutes | This value is calculated based on the admin input, as a product of Retry After, Retry Number, and Backoff Rate. For example, based on the defaults, if the Maximum Retries is increased to 4, subsequent retries would wait for 60 minutes, 90 minutes, 120 minutes, and so on. Admin would need to adjust the Timeout value to 300 minutes or more. |
| When Retries Are Exhausted | Stop workflow | You can perform the following actions when the retries are exhausted: Stop Workflow - Stop the workflow at the failed step and report a failed status. Skip Workflow Step - Skip the failed workflow step and report an error, but continue the workflow. |
Note: If you want to restore the default settings for the error handling option, 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 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 deactivated by default. When the Re-evaluate condition option is enabled, the entire workflow is re-run every 4 hours.
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. This condition uses a free text field, where the admins can type the application name and application versions to be targeted. To assist the administrator, the UI displays a list of potential matches. This list is inclusive of all the versions of the application installed across devices, whether the application was deployed through Workspace ONE UEM, downloaded from the Workspace ONE Intelligent Hub, or installed by the end user.
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 be added for Windows and macOS devices. To add an application condition for macOS devices, the Freestyle Orchestrator feature requires a minimum version of Workspace ONE Intelligent Hub 22.08 installed on the target device.
An administrator can create a condition to check if an application name and a specific application version is 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.
Table 1-2. Sensor Data Type and Supported Condition Operators
| Sensor Data Type | Condition Operators Supported |
|---|---|
| Boolean | Equals |
| Date Time | After, Before, Between, Not Between, Within, Not Within |
| 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 Documentation 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 be added for Windows and macOS devices. To add a file condition for macOS devices, the Freestyle Orchestrator feature requires a minimum version of Workspace ONE Intelligent Hub 22.08 installed on the target device.
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.
Condition with Time Window
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:
- A time window cannot be a part of a condition with And, Or operators.
- If a time window condition is present in the If branch, an Else branch cannot be added to the condition.
- Desired State Management (DSM) settings cannot be enabled on a time window condition. The DSM setting can be enabled on an action step under a time window condition.
- Nested time window conditions are not supported. For example, if time window is added in condition 1 then another time window condition in condition 2 cannot be added (where condition 2 is nested within condition 1).
When an installed app, that is, an app installed either through direct assignment or workflows is manually removed and re-installed through desired state management (DSM) enablement, the re-installation might not follow the defined time windows. The time window condition is checked before starting each app installation but a single app installation that has already started running inside a time window might continue to run outside the time window.
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 Make a Time Window and Apply it to Devices section in the Managing Devices guide.
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.
Components of a Workflow for Freestyle Orchestrator Mobile
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 application or profile.
-
Condition: Use condition to create conditional requirements, based on data points from different sources, such as application inventory, profile inventory, device attributes and so on.
-
Group: Use group 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 and profiles. 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 and profiles 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.
Note: Mobile workflows can only support up to 20 resource actions such as install or remove an app or profile.
Currently, the following apps or profiles are not supported:
- VPP applications
- Compliance profiles
- Declarative profiles
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 option to modify the default settings.
The following table lists the error handling options and their default values.
Table 1-3. Resource Error Handling Options and Default Values
| Options | Default Value | Description |
|---|---|---|
| Timeout | 120 minutes | Specify the maximum time to wait for a workflow step to complete. |
| Retry After | 15 minutes | Specify the time interval after which the workflow steps with errors are retried. |
| Maximum Retries | 1 | 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 30 minutes | This value is calculated based on the admin input, as a product of Retry After, Retry Number, and Backoff Rate. For example, based on the defaults, if the Maximum Retries is increased to 4, subsequent retries would wait for 60 minutes, 90 minutes, 120 minutes, and so on. Admin would need to adjust the Timeout value to 300 minutes or more. |
| When Retries Are Exhausted | Stop workflow | You can perform the following actions when the retries are exhausted: Stop Workflow - Stop the workflow at the failed step and report a failed status. Skip Workflow Step - Skip the failed workflow step and report an error, but continue the workflow. |
Note: If you want to restore the default settings for the error handling option, 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, profile, and device attributes. 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.
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 in Workspace ONE UEM, 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.
An administrator can create a condition to check if an application name and a specific application version are installed on a device. 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.
Condition with Profiles
For profiles, the profile exists or does not exist condition is supported. When the profile exists or does not exist option is selected, the administrator can search and select from the list of available profiles.
Condition with Device Attributes
An administrator can use the following device attributes data to define a condition in a workflow.
Table 1-4. Device attributes and their description
| Device Attributes | Description |
|---|---|
| Enrollment Date-time | Target devices that are enrolled before or after a certain time and date. |
| OS version | Target devices based on OS version. Free form field paired with dropdown: contains, does not contain, equals, not equal to, starts with. |
| Model | Target devices based on model name. Android Search and Select: OEM and Model. iOS dropdown: iPad, iPhone, iPod touch |
| Enrollment mode | Target devices based on enrollment mode. Android drop-down: Android (Legacy), COPE (Android ≤10), COPE (Android 11+), Work Profile, Work Managed. iOS: This condition is not yet available. |
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.
Was deze pagina nuttig?