SaaS management processes are often dynamic, and can be slightly different as a function of managed entity attributes.
Here are examples of use cases where you might want to automate variations of the same process:
1. Employee onboarding
The employee onboarding process typically consists of generic steps, such as creating an Okta user account for each new employee. However, specific steps within this process may vary depending on the employee's role. If the new employee joins the Sales team, it may be necessary to automatically assign them a Salesforce license. On the other hand, if the new employee is an engineer, you should create a Jira Cloud user account for them.
2. License optimization
When a user no longer utilizes an assigned license, it's more cost-effective to reassign it to another employee. However, the specific steps in this process may differ based on the characteristics of the licensed user. For instance, if they hold an executive position, it's likely that an approval is required before revoking their license. Conversely, for regular employees, you may prefer to proceed immediately and revoke the license after a specific period of inactivity.
3. Access provisioning
When a user requests access to an app from Application catalog, you are likely to have different access policies based on user roles. For example, if a user belongs to Sales department and requests access to Salesforce, they will be automatically provisioned with a license. However, if a user is associated with a different department, they will need approval from app owner before access can be granted.
With Torii's IF-ELSE branch action, you can segment the same workflow into multiple branches, ensuring that you cover the entire process comprehensively through a single automation.
How to create branches
In this section, we'll delve into configuring the IF-ELSE branch action and create a workflow that supports onboarding for different roles based on employee attributes in the HR management system.
1. Create a workflow with a "User meets criteria" trigger
2. Apply a generic filter.
Set up a filter that will be applied to every new employee who joins the organization. For example, if you're using HRMS software like Hibob, you can create a filter where "Hibob start date is exactly 7 days from now."
3. Add generic actions.
Include actions that are generic and should be applied to any new employee, such as "Create Okta user" and "Create Slack account."
4. Define Role-Specific Sub-Automations
Now it's time to define sub-automations that will be specific to different employee roles. Add the IF ELSE action. Note that this action will be automatically added with two branches - the first branch with specific conditions that need to be set and the second branch (None met) for users who do not meet the conditions in the first branch.
5. Define a filter for the first branch.
This filter will be applied to the entity enrolled in the workflow. For instance, if the workflow trigger is "User Meets Criteria," you'll need to set up a filter for the user. The filter setup is similar to what you used in the trigger setup.
In our example, let's set the filter to "Hibob department is Sales." Feel free to rename the branch for easier visualization on the workflow canvas.
6. Add more branches or actions
Now you can add additional branches and define their filters, or add specific actions to the Sales branch. In our example, let's create branches for other departments where unique licenses are required during onboarding.
7. Assign actions to branches.
Each branch should receive actions that are specific to new employees from the designated departments. For example, Sales team members may be assigned Salesforce licenses, while Engineering employees receive Jetbrains licenses.
8. Add actions to the "None met" branch.
We recommend adding actions to the "None Met" branch, to receive notifications in case you forget to cover all use cases. For instance, you can add a "Send Slack notification" action with a message like: "New employee <Employee name> has joined. Okta and Slack users were created, but no unique department licenses were assigned."
9. Activate your workflow
Now you can activate your workflow. When the workflow executes, you will see which branch was selected in the workflow audit log, in the details of the IF ELSE branch action.
Q & A
1. Is the IF ELSE branch action supported with all triggers?
The IF ELSE action is supported with all triggers, apart of App event and License count threshold. We also support the IF ELSE action in Access request policies in Application catalog.
2. What happens is a user meets multiple conditions and falls under multiple branches? Will all branches be executed?
Torii evaluates branch conditions from left to right. It checks the leftmost branch first, followed by the branch to its right, and so on. Consequently, only one branch will be applied to the user - specifically, the first branch in which the conditions are met.
3. Can I create nested branches? For example, I would like to create a dedicated branch for Engineering onboarding, and then define different automation paths for Engineering managers and Developers.
Yes, you can create nested branches. Another approach to achieve a similar outcome is by including multiple filters within a branch, similar to how it's done in the setup of the "User Meets Criteria" trigger. This offers flexibility in tailoring automation paths for specific roles or criteria.
4. Is there a limit to the number of branches I can add to the IF-ELSE action?
Yes, you can add a maximum of 20 branches to a single IF-ELSE action. If you need to add more branches, you can insert another IF-ELSE action as a sub-branch beneath the "None met" branch and add the remaining branches there. In general, we recommend maintaining a reasonable number of branches within the IF-ELSE action to ensure the manageability of your workflow.
5. Is there a limit to the number of nested IF ELSE actions I can add to a workflow?
There is currently no limit to the number of nested IF ELSE actions.