UI Policy Action fields field_message, value

[NS]

Hello, I noticed four interesting fields in the UI Policy Action (sys_ui_policy_action) table :

• field_message
• field_message_type
• value
• value_action
  
  

Their names suggest that a UI Policy Action can display a field message or set a field value. However, these fields do nothing in the Standard UI.

You can verify this yourself (also shown in the attached screenshots)

1. Add the fields to the UI Policy Action form.
2. Configure a message and a value.
3. Trigger the UI Policy on a standard form.
4. Observe that supported actions, such as Mandatory, work. Nothing more.

I was confused about these fields so I contacted the ServiceNow support. They confirmed that the core implementation limits this functionality to the Service Catalog context. Support also stated that the documentation would be updated in the “near future”. There wasn't much info about the fields, hence this post. 

The confusing part is that these fields exist on the standard UI Policy Action table, but the standard UI Policy documentation does not explain their purpose or mention that they only work in the Service Catalog.The confusing part is that these fields exist on the standard UI Policy Action table, but the documentation does not say that they only work in the Service Catalog.

[Abhishek Pal]

Hi @NS ,

Good observation. What you are seeing is expected based on how these UI Policy Action records are implemented.

The important point is that Catalog UI Policy Action [catalog_ui_policy_action] extends UI Policy Action [sys_ui_policy_action]. Because of that inheritance, some fields used by Catalog UI Policies are defined on, or inherited through, the parent UI Policy Action structure.

That does not mean every field on sys_ui_policy_action is supported by the standard form UI Policy engine.

For a regular UI Policy on a table such as Incident, the supported UI Policy Action behavior is primarily:

• Mandatory

• Visible

• Read only

• Clear field value where applicable

The standard UI Policy documentation likewise describes these standard field actions, while the current Catalog UI Policy documentation specifically documents Value action, Value, Field message type, and Field message for catalog variables. (servicenow.com)

This explains your test:

UI Policy:
Short description starts with "demo"

UI Policy Action:
Mandatory = True
Field message = configured
Value = configured

Result:
Mandatory works, but the message/value behavior does not execute on the Incident form.

So I would not use field_message, field_message_type, value, or value_action on a standard sys_ui_policy_action record, even though those fields can be manually exposed on the form.

If the same behavior is required on a standard form, use the supported client-side APIs from the UI Policy script or an appropriate Client Script.

For example, for a field message:

function onCondition() {
g_form.showFieldMsg('description', 'Supposed to be an info message?', 'info');
}

For setting a value:

function onCondition() {
if (!g_form.getValue('description')) {
g_form.setValue('description', '9001');
}
}

If using UI Policy scripting, also handle Execute if false when the behavior needs to be reversed, particularly for messages.

Architecturally, I would keep it as:

Standard UI Policy Action
-> Mandatory / Visible / Read only / supported field state actions

UI Policy script or Client Script
-> Field messages / dynamic value manipulation

Catalog UI Policy Action
-> Catalog-specific value actions and field messages

The confusing part is definitely that the fields can be exposed on sys_ui_policy_action. Their presence in the table schema should not be interpreted as support for those actions in every UI Policy context.

Your ServiceNow Support confirmation also aligns with the behavior shown in your screenshots.

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal

[NS]

Hi Abhishek, thanks for the reply. At this point these fields are clear to me, and that's what wrong here IMO. Scripting is no issue, but since SN recommends using configuration over scripting, one may assume that there are usable field in the table. From that perspective the fields certainly start to look interesting. Documentation doesn't clearly enough describe these fields. Having even the simplest mention "not applicable in standard UI" in the docs would be enough. Instead I went back and forth with the SN for two months to get an answer about these fields. Waste of time on both sides.

Another thing I wonder is why are the fields not created directly on Catalog UI Policy Action [catalog_ui_policy_action] but to UI Policy Action [sys_ui_policy_action]? What about the other extended tables Workflow Ul Policy Action and Wizard UI Policy Action.

Sorry if this comes off as a bit of a rant. It's just a bit annoying when there's no information available :--)