There is a requirement to add filtering entitlement attributes but dynamically based on the application selection. Might need your expert guidance required to proceed, here is the problem description.
Short problem description:
Individual applications have 1000 entitlements
Employees have to select the right entitlement for them, but it’s difficult to find them without knowing the naming conventions for that specific application
Standard functionality provided by Sailpoint: Filtering
Problem: Applications may have very specific filtering criteria for their entitlements → Geography (Region, Country, Location), Roles, Functions (e.g. Operations vs Finance, Administrator vs Team Lead),
It is difficult to implement application-specific filters incl. descriptive labels etc.,
I don’t know of any OOB mechanism to accomplish that level of “dynamic filtering”, but I do want to note that the IIQ Full-Text Index searching capabilities are pretty robust. You can configure it for substring (or partial) matches, and update what all entitlement/role attributes are indexed (by default, name, attribute name, attribute value, and description are all indexed).
@brian_weigel Thank you for your response, looking for something that could be achievable via developing some plugins for the access request page to filter it based on the extended entitlement attributes. So it will be easy to understand non-it people instead of educating them on the way to search etc., If you have any experience or guidance will be appreciated.
I’m not sure if any plugin can directly interact with the Access Request page, since that basic flow happens internally in IIQ outside of any workflows and the like. What you can do is use quicklink scopes/scoping rules to filter down what is displayed and requestable by a user. See the Configuration Tab in the 2nd link above, which notes this:
What can members request?: specifies the objects to include in LCM requests governed by this population
This applies only to Lifecycle Manager QuickLinks attached to the population. The rules named in this section constrain the roles, applications, or entitlements which are presented to the requester.
NOTE: When one user meets the criteria for multiple Quicklink Populations which each govern LCM access, the least restrictive rules are applied for constraining the roles, applications, and entitlements the user can request.
In most cases, requestors are familiar with what specific items to request. To address this, it is recommended to enhance the role or entitlement descriptions by incorporating more descriptive text or keywords. Another effective approach is to include additional extended attributes, such as department, cost center, or location, Enabler Types to provide supplementary information and metadata about the roles or entitlements. This additional information can greatly assist requestors in finding the appropriate roles or entitlements to request. I recall implementing such attributes in the past to specify the supporting or additional roles/entitlements that requestors should consider alongside their current selections. Furthermore, utilizing the request object selector rule can further assist requesters by narrowing down the available options based on their specific requirements.
@sunnyajmera Thanks for your response, Already have the plan to extend the entitlement attributes like department, location, Roles or functions, however, the requirement is to achieve each application should list out some different attributes.
Ex. App1 should be visible Department and location, but App2 should be listed with Department, Roles only.
Likewise will need dynamic filters based on the application selection. Even when we have some common 5 attributes to appear for all applications, which doesn’t make sense for the end user and they might be confused. Is there any other possible way?
One idea that I have in my mind after using the plugin Hide User Access Filter from the developer ashishbhatia. Because the plugin does hide the attributes, in my case I need to show the attributes based on the application selection.
@kannan_sb85 - It sounds like your challenge can really be broken down into a few different parts:
Scoping requestable entitlements down to a more limited subset
** Basically pre-filtering what roles/entitlements are visible, searchable, and available to a person from the start when making a request based on identity attributes like department so that they’re not trying to search the entire entitlement catalog
Enhance the role/entitlement details shown on the Manage Access page cards to display relevant information (including possibly making these details searchable to facilitate in user searches). We will call this the “default display”.
Dynamically changing the role/entitlement details shown on the What to Request based on requestor or request context.
** ex. 1: User selects filter for app X, alter the ‘default display’ to add data attribute Y and remove data attribute Z.
** ex. 2: Requestor is in department A, alter the ‘default display’ to add data attribute B and remove data attribute C.
Adding additional filters/filter logic to #1 based on a requestor selecting an app from a filter on the Manage Access page.
Does this sound correct? Assuming it is, here’s the break-down:
#1 can be done a couple of different ways with either IIQ scopes and request authority, or using Quicklink Scopes with scoping rules. There are pros and cons to each approach, so you’ll need to detail out the different scoping requirements and evaluate them to determine the best path forward for you
#2 can generally be done through updating the IIQ UIConfig. There’s a good whitepaper on UIConfig on Compass. As to the enhanced searching, you can customize the FullTextIndex config to add additional attributes/data to index for request searches.
#3 and #4 are where you’re going to have issues. I won’t say it can’t be done, but there is no OOB mechanism to accomplish this that I know of. All of the Manage Access flow happens through the user’s browser making REST API requests/responses to the IIQ back-end.
You might be able to somewhat handle #4 by creating some custom request links that have the filters/searches pre-populated, but beyond that you’ll be in for some pretty heavy development effort.