Best Practices for UI Policies where multiple fields and applications are involved

carlh · ‎02-13-2017

Hi All,

I'm looking for guidance. I have added many fields to my incident form as required by the business to help report and troubleshoot application issues. I started adding business rules based on the application but have noticed strange behaviors when it comes to fields that are shared by applications and or business rules.

The question is, is it best to build UI Policies based on the application or should I make them for each field instead. Either way it's a ton of fields and UI policies.

I spoke to support on one issue. I had a field show up as mandatory but after I set a value, it doesn't appear on the form. It's part of another UI Policy and they say it's because of the "Reverse if False" being unchecked. I will have to start over and am not sure I understand that feature completely so while I'm at it I thought I'd ask for advice.

Anyone have tips?

Thanks

Carl

Chuck Tomasi · ‎02-14-2017

If it were my app and I had complex show/hide rules, I'd make it data-driven so when someone changes the rules, you don't have to refactor the code. Sort of a super-UI policy.

Create a lookup table that defines what fields you want to display under which conditions. Use a GlideAjax call in a client script to pass the current values, then returns a list (array, or comma separated values) of fields to show (or hide) and then run that through g_form.setDisplay().

I know that's a pretty broad picture of the solution, and may take some time to implement, but will save you maintenance time in the long run.

Docs: Client Scripts

Docs: GlideForm

Docs: GlideAjax

Client Script Best Practices - ServiceNow Wiki

View solution in original post

Chuck Tomasi · ‎02-13-2017

Hi Carl,

What are you referring to when you talk about sharing these between applications? Is Application a field on the form that is part of the UI policy condition?

Can you include a screenshot?

carlh · ‎02-13-2017

Hi Chuck,

OK here's the situation. We have all this data but nothing telling us how things were resolved, what was tried, certain things about the incident that need to be known before support or developers can answer.

So I gathered the requirements of our Product Mangers who support our custom built software and added fields and subcategory choices.

I have attached a screen shot of the mess I am trying to clean up. While I realize it's not advised to do, exactly what we are doing, I don't have another way I can think of to NOT add all these fields if this is what they want to report on.

So we will set the "Category" first to applications. Next, I require the "CI" which I have labeled Affected Application and it references CMDB_CI Business Services.

This is where the hard part comes in. Not all fields are needed or pertain to all of our software so I can of course use UI policies to hide or show fields based on conditions being met. And I need to as it is a big mess!. I'm having a hard time because some fields require the same field and that is where support helped me by showing me the "reverse if false" checkbox but now I've got about 25 UI Policies I need to go dig through as more was added.

I'm looking for ideas and best practices to solve that mess above.

Thanks as always for your help.

Carl

Chuck Tomasi · ‎02-13-2017

Hi Carl,

Thanks for the explanation. Is "Category" the key driver to which fields are visible or not or are there other variables involved?

carlh · ‎02-13-2017

Category just makes the cmdb_ci field required or not

The main field is the cmdb_ci "affected application" next is "application subcategory" then subcategory details

These are all using the previous as a dependent value

Then the other fields will come in to play

Get Outlook for iOS<https://aka.ms/o0ukef>