Short Description
Saviynt solution can be extended by making use of dynamic attributes, to support creation of custom application request form to capture the fields/data by the end user while raising a access request. Dynamic attribute enables the implementation team to present users with custom fields for capturing application access provisioning.
Applicable version
ALL
Detail best practice
- Try to limit the number of dynamic attributes on a form which make SQL
queries. This may impact performance of the form. For a dynamic attribute which contains a small set of values, try using static values (ENUM or MULTI LIST) instead.. - Try to limit the number of dynamic attributes with the configuration set to “Mapping” on the request form for – "What action to perform when Parent attribute changes?” This may also cause significant performance impact.
- Make sure that the SQL queries used in the dynamic attribute is properly optimized (refer analytics best practice document for examples on optimize query)
- Design the form in such a way that the previous attribute can be used to narrow down results in the current attribute (cascading)
- Always try to map one DA to one single column ( multiple columns can cause discrepancies and values may be get appended )
- Use groovy conditions in the validation conditions and can be utilized to validate conditions on request submission – for example – we can validate if an entered mobile number is in correct format or not. ${Mobile.length() == 10 && Mobile.isNumber() && Double.valueOf(Mobile) > 0} -> Here Mobile is a string dynamic attribute taken as input from the end user
- When Dynamic attributes defined has more than 2 level of hierarchy and the show/hide functionality is being used, then while updating the user from update user tile, the two-level down dynamic attribute does get hidden even if the scenario matches, so check out the below example of how DA works
| DA Name | Possible Values | Conditions for Show and Hide | Mapped to user column |
| L1 | L1-A, L1-B
L1-B -> Default value | L1A -> Show L2A, Hide L2B
L1B -> Hide L2A, Show L2B | |
| L2A | L2A-a, L2A-b | L2A-a -> Show L3A, Hide L3B
L2A-b -> Hide L3A, Show L3B | customproperty52 |
| L2B | L2B-a, L2B-b | L2B-a -> Show L3C, Hide L3D
L2B-b -> Hide L3C, Show L3D |
customproperty53 |
| L3A | L3A-a, L3A-b | | customproperty54 |
| L3B | L3B-a, L3B-b | | customproperty55 |
| L3C | L3C-a, L3C-b | | customproperty56 |
| L3D | L3D-a, L3D-b | | customproperty57 |
Suppose the user is saved Customproperty52 with value L2A-b and Customproperty55 with L3B-a. When we try to update the user from Update user tile, then on form load, L1 is loaded with L1-B, hence L2A is hidden, however L3B still shows up, which is because customproperty52 has L2A-b has that value stored and that value is loaded from the custom property on page load.
Key Benefit
