how to hide ui actions for the "save" and " update" on the procurement case record.

[rajamusani]

Hi Team,

I have one requirement to hide "save" and "update " buttons when the procurement case record moved to "Resolved" state.I had tried with on load client script ,it is not helping.

please suggest if you come across this requirement.

 xanadu(version we are using.)

[Paul Kunze]

Hi, you can overwrite the two global buttons and add your own conditions.

The easiest way would be to open the "Save" and "Update" UI Actions for table "Global", adjust the table name and the condition field, and finally click "Insert and Stay".

[Me Being Mustaq]

Hi @rajamusani ,

For ServiceNow Xanadu, an onLoad Client Script often won't reliably hide Save and Update because:

• UI Actions can be rendered after the form loads.
• Workspace forms behave differently from Classic UI.
• Standard form buttons are not always controlled by g_form methods.

You can use a Display Business Rule + UI Action Condition. If the requirement is When Procurement Case   State = Resolved, users should not be able to Save or Update the record. Then the cleanest approach is to make the form read-only when resolved.

For Procurement Case records in Xanadu:

1. Make the form read-only when State = Resolved.
2. If the buttons must disappear, use UI Action conditions rather than a Client Script.
3. If users are working in Workspace, avoid DOM-based hiding (document.getElementById) because it is unreliable there.

This approach works consistently across Classic UI and is closer to ServiceNow best practices.

Warm Regards,

Shaik Mustaq

[Abhishek Pal]

Hi @rajamusani ,

An onLoad Client Script is not the right approach for this requirement. Save and Update are UI/Form Actions, and in Configurable Workspace they should be controlled through the action configuration rather than DOM/client manipulation.

For Procurement Case Management, the OOB Procurement Case table is:

sn_spend_psd_procurement_request

Recommended approach depends on where the form is being used.

If this is Source-to-Pay / Configurable Workspace:

1. Navigate to:

Now Experience Framework > Declarative Actions > Form Actions

2. Locate the OOB Save and Update actions being used by the Procurement Case record.

3. Do not modify the OOB actions directly.

4. Exclude the global Save/Update actions from the Procurement Case table.

Use the Action Exclusions related list and specify:

Table:
sn_spend_psd_procurement_request

5. Create/copy table-specific versions of the same Save and Update Form Actions.

Keep the same OOB implementation and configure:

Table:
sn_spend_psd_procurement_request

6. Under Record Conditions configure:

State is not Resolved

The result will be:

Procurement Case State != Resolved
-> Save and Update visible

Procurement Case State = Resolved
-> Save and Update hidden

This is preferable to an onLoad Client Script because Form Actions support record-based visibility conditions directly.

For Classic/Core UI:

Save and Update are inherited Global UI Actions.

The important Action names are:

Save:
sysverb_update_and_stay

Update:
sysverb_update

Create table-specific overrides rather than modifying the Global UI Actions.

For Save:

Name:
Save

Table:
sn_spend_psd_procurement_request

Action name:
sysverb_update_and_stay

Condition:

current.canWrite() && current.getValue('state') != '<resolved_internal_value>'

For Update:

Name:
Update

Table:
sn_spend_psd_procurement_request

Action name:
sysverb_update

Condition:

current.canWrite() && current.getValue('state') != '<resolved_internal_value>'

Replace <resolved_internal_value> with the actual internal value of the Resolved choice in your instance.

Using the same Action name on the specific table overrides the inherited action for that table.

Important:

If the real requirement is:

"After a Procurement Case is Resolved, nobody should be able to modify it"

then hiding Save/Update is not sufficient.

A user or integration could still update the record through:

- List editing
- REST API
- Import
- Another UI Action
- Server-side processing

In that case, also implement an appropriate server-side write restriction, such as an ACL or controlled validation, while allowing any required OOB Procurement Case closure/reopen processing.

Therefore I would implement:

UI requirement
-> Form Action / UI Action visibility

Data integrity requirement
-> Server-side write control

I would avoid:

- DOM manipulation
- getElementById()
- hiding buttons through CSS
- modifying the OOB Global Save/Update actions
- modifying the OOB Source-to-Pay Workspace page

ServiceNow supports record conditions and script conditions on Configurable Workspace Form Actions specifically for determining whether an action is rendered.

Official references:

https://www.servicenow.com/docs/r/platform-user-interface/declarative-actions-glossary.html

https://www.servicenow.com/docs/r/platform-user-interface/hide-global-action-from-a-table-or-view.ht...

https://www.servicenow.com/docs/r/xanadu/platform-administration/t_EditingAUIAction.html

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

[Chetna_Aggarwal]

An onLoad Client Script won't work for hiding the Save and Update buttons because those buttons are rendered by UI Actions.

A better approach is to create table-specific Save and Update UI Actions:

1. Open the global Save and Update UI Actions.

2. Change the Table to your Procurement Case table.

3. Add a condition such as:

   current.state != <Resolved State Value>

4. Click Insert and Stay to create the table-specific UI Action instead of modifying the global one.

When the record is in the Resolved state, the condition evaluates to false, and the Save and Update buttons will no longer be displayed for that table, while other tables continue to use the global UI Actions.

This approach is cleaner and follows the platform's intended customization pattern.