Regulatory Change Management, Applicable button

anurampalli
Tera Guru

Saturday

Hello

 

Within the compliance workspace, there is a module for Regulatory Change Management. 

 

A coordinator with the role sn_grc_reg_change.manager or user is able to mark a New Regulatory Alert as Not-Applicable (state 3 within the sn_grc_reg_change_regulatory_feed table).

 

But to do so, the reason and mandatory are mandatory. There are no ui policies or data policies, no client scripts and no business rules governing this behavior that I could find.

 

I found a component in UI Builder-> compliance workspace experience that deals with the comments text area and reason fields and one more field called feed. I commented the client script code that makes the submit button disabled.  And also make the comments text area optional. But when I submit, I still can't complete the operation. 

 

There is one more spot I am missing and I don't know where the comments are being made mandatory. Can anyone help, please. It is rather urgent!

0 Helpfuls
  • 1,632 Views
5 REPLIES 5

anurampalli
Tera Guru

Saturday - last edited Saturday

@Pavan Srivastav 

@lauri457 

 

@can you help, please

0 Helpfuls

lauri457
Tera Sage
In response to anurampalli

Sunday

@anurampalli 

The reason is this rest data broker used by the submit button. 

/nav_to.do?uri=sys_ux_data_broker_rest.do?sys_id=d0f586ae079120103a2990a30ad

 

The api end point is:
/api/sn_grc_workspace/regulatory_management_workspace_services/not_applicable_feed/{{sysId}}/{{comments}}/{{reason}}/{{duplicateFeed}}

 

With comments being empty the empty param in the path seems to be throwing an error somewhere before it even reaches the api script. You'd need to send a placeholder comment or edit the data broker and api to use a request body for the comment instead

 

Simplest way is to edit the inline script on the submit button execute data resource handler

/**
 * @param {params} params
 * @param {api} params.api
 * @param {any} params.event
 * @param {any} params.imports
 */
function evaluateEvent({
	api,
	event
}) {
	if (api.state.disableSubmit) {
		return {};
	}

	return {
		sysId: api.context.props.sysId,
		comments: api.state.comments || "NA",
		reason: api.state.reason.id,
		duplicateFeed: api.state.selectedDuplicateFeed
			? api.state.selectedDuplicateFeed.id
			: 0
	};
}

 

0 Helpfuls

anurampalli
Tera Guru
In response to lauri457

3 hours ago

Thanks @lauri457 

 

With some help, I figured out the REST Data broker, the disable submit and everything else I needed to make comments and reason optional.

We implemented setting duplicates with state 3 as well using the same component. Added a check box, added an extra parameter to the REST API and inside the UX REST Data Broker.

 

It was fun! 

0 Helpfuls

Pavan Srivastav
ServiceNow Employee

Sunday

Hello Anurampalli,
 
In Workspace (UI Builder), each component has its own client-side validation, operating independently from UI Policies and Client Scripts. When working within the UI Builder canvas, you'll want to select the comments text area component and review its Component Properties panel on the right. Look specifically for properties such as 'required,' a validation binding, or a validators array applied directly to the component. These validations are declarative and internal to the component, which explains why searches in script or policy tables don't show any related entries. The same approach applies to the reason field component—inspect its properties for a 'required: true' setting or a validation expression.
 
To investigate further, you follow these steps: open UI Builder and locate the exact page variant associated with the Not-Applicable modal or panel. Click the comments component and examine all bound properties for required fields or validators. Next, review the submit button’s Events panel and trace the action chain. In Flow Designer, search for flows scoped to sn_grc_reg_change, then switch your active scope to sn_grc_reg_change and re-run your Business Rule query.
 
This combination of component-level required bindings, together with declarative actions or flow-level guards, is prevalent in modern GRC workspace implementations. Both are invisible to searches through classic UI Policy and Client Script tables, so focusing on component properties and flows is essential for troubleshooting validation issues.
 
 
 
Regards 
Pavan