Restricting order of fields.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2024 01:33 PM - edited 04-21-2024 02:03 PM
Hi ServiceNow Experts,
an Interesting use-case here. the below form is similar to what I have created in scoped application.
use-case: I want to restrict user such that he should attach file in order (attachment1>attachment2>attachment3),
if attachment1 is not attached then attachment2 & 3 should be read-only and like-wise.
Note: I dont wanna use multiple UI policies and UI policy actions, also I dont wanna create 3 client scripts for this use-case.
Regards,
Ubada Barmawar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2024 01:46 PM - edited 04-21-2024 01:48 PM
I dont wanna use multiple UI policies and UI policy actions, also I dont wanna create 3 client scripts
So what should it be then - devine intervention?
Also if I would interview someone for a job and he or she would state the same, that person would automatically be dropped from the list of potential candidates.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2024 01:58 PM
I just dont want to make this logic too complicated and long...thats what is my intention.....because already the flows, business rules, UI policies, and other things running on this table are too much to handle. just want to want to achieve it through most efficient way.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2024 02:07 PM - edited 04-21-2024 02:08 PM
Flows and Business Rules have nothing to do with UI Policies - so the former two don't influence the performance of the latter and vice-versa.
The former two (Flows and Business Rules) exist and effect performance server side, after a page has been submitted (by using a form/UI Button click or a GlideAjax call); the latter (UI Policies) run client side before a page is submitted and are the best choice performance wise anyway.
Also UI Policies can be considered data/configuration, rather then logic.
The logic has already been implemented by SN, one just has to configure it - using UI Policies.
Creating many UI Policies (and UI Policy Actions), which leads to robustness and ease of maintenance should far outweigh the barely noticeable performance gains that could maybe be obtained through some scripting hack.
In fact I go as far as to create a UI Policy + UI Policy Action for every field/variable, per policy action, per environment and I have never encountered problems with performance, predictability, maintenance, etc.