There are a few ways to modify your use case behavior for different employees in your organization. Let's say you were building the following use case using Paths:
For employees requesting a new Zoom license: - if they're an Executive, auto-provision Zoom Pro licenses. - if not, provision Zoom Basic licenses. Executives are recognized as users with 'is_vip' set to 'True' in their ServiceNow identity.
Setup 1 use case for Zoom provisioning & provide user context as context to your automation tool. Then query the relevant attribute from your source system (
is_vip from Servicenow in our example) & modify behavior based on the value.
If you have easy access to an automation system, this is faster to build & maintain but offers lower flexbility. Limitation for building only 1 Paths use case is that the follow up questions will remain the same for all employees.
In this scenario, we'll create 2 use cases & use rules to filter launch natively in Creator Studio.
First, we'll register
servicenow.is_vip as a custom attribute. Then, we'll setup 2 Paths use cases: the first for provisioning Zoom Pro licenses & the second for Zoom Basic licenses.
Finally we'll setup a filter rule to make the first Path available only for VIP users & the second path available to other.
Filter for only VIP users
user.custom_attribute.servicenow.is_vip == "True"
Filter for all other users
user.custom_attribute.servicenow.is_vip != "True"
This option provides more flexibility to control experiences for individual employee groups.