Conditions in Workflows

Omnissa Intelligence offers Conditions to use in Freestyle Orchestrator so that you can define action sequences mid workflow without creating separate workflows.

Benefits

Conditions reduce the overhead of maintaining separate workflows for each specific scenario. With conditions, you can use a common trigger rule to create alternative execution paths for each different scenario within one workflow. For example, without conditions, you had to create separate workflows for every action needed for every compliance scenario. Now, you can add conditions for multiple compliance scenarios with many actions in a single workflow.

Create a workflow with a condition

Find the condition menu item as a drag and drop option on the workflow canvas.

Important: Check the Potential Impact of your workflows, and test your workflows on a small number of targets by specifying more restrictive filters to ensure the workflow actions behave as desired.

1. In Intelligence, navigate to Workspace > Freestyle > Add Workflow.
2. Enter a name for your workflow.
3. Set up the trigger with the desired data source.
4. Select the Trigger Settings.
5. Work with the Potential Impact results for Manual or Schedule Trigger Settings in the Workflow Settings area.
   • Select Evaluate Potential Impact.
   • Select View Details to access the Potential Impact panel.
   • Use Group by to group the data by data attributes. For example, you can group data by device data or app data.
   • Use the arrow to close the Potential Impact panel.
   • Access the panel anytime during the creation of the workflow to help fine tune your filters.
6. Configure the Trigger Rule.
7. Add a condition by dragging and dropping the Condition icon from the components on the left or by using the + Add Step icon on the canvas.
   • You must add an action to either the Then branch or the Else branch.
   • You can nest conditions, and you must add an action to at least one condition in the nested condition group.
8. Name the condition for better readability.
9. Set the filters for this condition in the Condition window.
   1. Set the If statement for the condition.
   2. Set the Then statement for the condition.
      • If you nest conditions, you must add an Action to one of the conditions in the nested group.
   3. Set the Else statement for the condition.
      • You can leave the Else statement blank, you can stop the workflow, continue with other actions, or add more conditions.
10. Save the workflow. You can activate the workflow at any time.

Example condition

Find enrolled Windows devices, check the device's firewall status, and if the status is not equal to Pass, then install a Workspace ONE UEM Firewall profile to update the firewall.

1. In Intelligence, navigate to Workspace > Freestyle > Add Workflow.
2. Enter a name for your workflow.
   • For our example, we can use Update Windows Firewall.
3. Set up the trigger with the desired data source.
   • For our scenario, use Workspace ONE UEM > Devices as the data source.
4. Select the Trigger Settings.
   • Set the trigger as Automatic.
5. Configure the Trigger Rule.
   • The Trigger Rule for this scenario is Devices > Enrollment Status > Equals > Enrolled.
6. Add a condition by dragging and dropping the Condition icon from the components on the left or by using the + Add Step icon on the canvas.
7. Name the condition for better readability. In this scenario, enter Check Windows Platform.
8. Set the If statement for the condition.
   • For the scenario, set Devices > Platform > Equals > Windows Desktop.
   • We're using the same attributes in the condition as we did in the trigger rule.
9. Set the Then statement for the condition.
   • For the scenario, let's nest another condition so that we can check the status of the firewall.
   • Name the second condition Firewall Status Not Pass > Install Firewall Profile.
   • Select Devices > Firewall Status > Not Equal To > Pass.
10. Set the Then statement for the second, nested condition.
    • Add an Action as Workspace ONE UEM > Install Profile.
      • The workflow engine installs the UEM Firewall profile to update the firewall when it identifies that the firewall status is not Pass.
      • One of our conditions in a nested group has an assigned action.
    • For the Profile ID name, search and select your UEM Firewall Profile.
11. Leave the Else statements blank for the first and second conditions.
12. Save the workflow. You can activate the workflow at any time.

Configuration scenarios

You must configure all the necessary data for a workflow within the trigger rule. If using conditions, you either need to use a specific configuration (same entities or 1:1 relationships) or you need to reference the condition entity in the trigger rule (1:N relationship).

What are entities and attributes?

Trigger rules and conditions are made up of trigger filters that include an entity and an attribute. In the screenshot, Devices is the entity and Antivirus Status is the attribute.

Equals and Pass are the qualifiers of the Devices > Antivirus Status entity-attribute pair.

Scenarios

For conditions to work without error, configure your conditions using one of the methods listed in the Scenarios list.

These scenarios are examples of the relationship between the entity in the trigger rule and the entity in the condition.

Scenario 1: Same entities

• Explanation
  • The trigger rule and the condition use the same entity.
• Example
  • The data source and trigger rule use the Survey entity to reference an Apps Survey, and the condition also contains a Survey entity for evaluation.
  • The workflow can have several conditions but all conditions must use the Survey entity.
    

Scenario 2: One-to-one (1:1) relationships

• Explanation
  • The trigger rule uses one entity and the condition uses a different entity. However, the entities in the trigger rule and in the condition have a one-to-one relationship.
  • For example, the workflow engine, when using a Devices entity in the trigger rule, can identify a unique Users entity in the condition.
  • Another example is the workflow engine, when using an Devices entity in the trigger rule, can identify the value of a particular Sensors entity like device_manufacturer_name in the condition.
• Example
  • The data source and trigger rule use the Devices entity to see if the device is enrolled and the condition uses a Users entity to check that the device user is in the HR user group.
  • The trigger rule and the condition use a 1:1 entity relationship because the workflow engine identifies a specific device enrolled in a specific user group.
  • These workflows can have more than one condition as long as each condition entity has a 1:1 relationship with the trigger rule entity.
    
    

Scenario 3: One-to-many (1:N) relationships

• Explanation
  • The trigger rule uses one entity and the condition uses a different entity. However, the entities in the trigger rule and in the condition have a 1:N relationship.
  • For example, a single device has many applications assigned to it or installed on it. In this scenario, the trigger rule has a device attribute, and the condition includes application attributes.
  • A similar example is the relationship between Devices entities and Profiles, Products, or OS Updates entities.
  • This 1:N relationship can hinder the system from using the entity from the trigger rule to uniquely identify an instance of the entity from the condition.
  • This configuration can be complicated and requires extra configurations.
• Example
  • The Devices entity in the trigger rule checks for a name of a device, but the Apps entity in the condition checks for Apps > App Install Status, and this device has many apps installed on it.
  • The system does not let you save this workflow.
  • See the section Additional configurations - 1:N relationships for actions you can take if you want to use this relationship but you get this UI error.
    

Additional configurations - 1:N relationships

When using 1:N relationships between trigger rules and conditions, you must add another trigger rule that references the condition entity. When it executes, the workflow targets matching records in the trigger rule (the original entity) and the entity that references the condition.

The addition of the trigger rule that references the condition entity increase the possibility that the workflow engine executes on large numbers of iterations as it matches records. The possibility to run iterations further increases when a workflow is set to run on a schedule. The targets in your workflow with a 1:N relationship can be excessive, so check the Potential Impact.

Actions

• If you use a different entity in the condition, you must include a trigger rule that references the entity introduced in the condition.
  Note: You do not have to include the extra trigger rule if using a 1:1 relationship.
  • The system needs this trigger rule that references the condition entity because it needs to join the data of the different entities to find matching records and display results.
  • If we revisit the example for 1:N relationships in the Scenarios list, you can add a trigger rule as App Name > Equals > Intelligent Hub.
    
  • This filter references the entity Apps that was introduced in the condition (Apps > App Install Status) and it completes the joining of the Devices and Apps entities.
  • The entities in the trigger rule are more restrictive and have a better chance of minimizing the matching device and application pairs that the workflow can iterate against (also known as the Potential Impact).
  • If you do not add the trigger rule that references the condition entity, you cannot save the workflow and the UI displays an error.
• Check the Potential Impact.
• Test the workflow on a small number of targets to see that it executes as desired by adding a more restrictive filter. For example, the attributes in the filter Device GUID > Equals > the GUID of your test device restricts iterating to finding a specific device GUID.
• Use the Automatic trigger setting when applicable.
• Consider creating a separate workflow.

Additional configurations - status changes

Workflows acquire data used to evaluate conditions at the beginning of the workflow execution and not at the time of evaluation.

If the status of an attribute changes (for example from true to false) due to an action before the condition (for example removing an app or updating a device), then the workflow won't have this status change at the beginning and the system does not report the status changes in the results.

Actions

• Use attributes in your conditions that won't change status during workflow execution. An example of an attribute status change is due to the action that removes a purchased app, an app installation status changes from true to false.
• Use a separate workflow to perform the actions that would have occurred after the change in status.