Inherit from risk statement field on risk form

[TheGOAT]

Hi , I want the field "inherit from risk statement" editable even after the new record is saved in risk form? Do anyone know where it is configured. How is it getting read only?

[Tanushree Maiti]

Hi @TheGOAT 

Refer:

https://www.servicenow.com/community/grc-forum/can-t-edit-risk-description-when-inherit-from-risk-st...

https://www.servicenow.com/docs/r/governance-risk-compliance/grc-risk-management-workspace/manage_ri...

[TheGOAT]

Hi, Tanushree. These dosent help with my question. what i want is the field inherit from risk statement itself should be editable in all states for risk manager?

[Faisal-Waheed]

Hi @TheGOAT,

For this exact checkbox, check the configuration directly on the Risk table, not the description-related UI policy.

The field is on Risk [sn_risk_risk]. First right-click the field label → Configure Dictionary and confirm the actual column name. Then check these areas:

1. UI Policy Actions
- Go to sys_ui_policy_action.list
- Filter Table = Risk [sn_risk_risk]
- Field = Inherit from risk statement / actual column name
- Look for any action setting Read only = true

2. Client Scripts
- Go to sys_script_client.list
- Filter Table = Risk [sn_risk_risk]
- Search for the field name or g_form.setReadOnly()

3. Field ACL
- Check write ACL for sn_risk_risk.<field_name>
- Make sure sn_risk.manager has write access to that field

If it is only a UI Policy making it read-only, do not edit the OOTB policy directly. Create a custom UI Policy on Risk [sn_risk_risk], run it after the OOTB policy, and make this field editable only for Risk Managers.

Example client-side script in the UI Policy:

if (g_user.hasRole('sn_risk.manager')) {

g_form.setReadOnly('<actual_field_name>', false);

}

Also validate the property sn_risk.risk_statement_mandatory under Risk > Administration > Properties, because if your process requires every risk to be tied to a risk statement, allowing users to toggle this after save may conflict with your data model.

So the short answer is: yes, it can be made editable for Risk Managers, but the right place to fix it is usually the UI Policy / Client Script / field write ACL on sn_risk_risk after confirming the actual column name.

Thank you!

XAAS Solutions LLC

If this helped you Mark "Helpful"
If this assisted you mark "Accept as Solution"

[Faisal-Waheed]

Hi @TheGOAT,

This field is usually locked intentionally after the Risk record is inserted because “Inherit from risk statement” controls the risk creation model, not just a display value.

When it is checked, the risk follows the classic inherited Risk Statement behavior, including the relationship between Risk Statement + Entity. When it is unchecked, ServiceNow allows the Risk Statement hierarchy to be used more like taxonomy/categorization and can allow multiple risks against the same Risk Statement/Entity combination. ServiceNow documents this behavior under “Manage risks linked to the same risk statement.”
Also refer to: Properties Installed with Risk Management.

I would check these places:

1. Go to Risk > Administration > Properties and check property:
   sn_risk.risk_statement_mandatory
   If this is true, the system expects risks to be associated with risk statements. ServiceNow documents this property as “Make risk statement mandatory in risk.”
2. Open the Risk form, right-click the field label → Configure Dictionary to confirm the actual field name, then check:
   • UI Policies on sn_risk_risk
   • Client Scripts using g_form.setReadOnly(...)
   • Write ACLs on that field/table
3. Turn on Debug UI Policies and reload the form. This will usually show which UI Policy is making the checkbox read-only.

Personally, I would not recommend making this editable for all saved records, because changing it after save can affect the intended Risk Statement/Entity relationship and reporting behavior. If this happened due to bulk import/load data, the safer fix is to correct the value during the Transform Map / before insert logic, rather than allowing users to toggle it later on existing risks.

So the likely solution is not only “make the checkbox editable”; first confirm whether your process should create inherited risks or independent risks, then set the value correctly at creation time.

Thank you!

XAAS Solutions LLC

If this helped you Mark "Helpful"
If this assisted you mark "Accept as Solution"