Best practice - remove UI action from extended table

Daniel A-C
Tera Expert

Looking for advice on best practice regarding UI actions

Requirement: Remove 'Add to visual task board' UI action from context menu in a change request.

This UI action is defined against the 'task' table. We don't want to remove it from anywhere else. I know of a number of ways to achieve this but have been unsure whether there's a 'best practice' way or at least a ServiceNow recommended way.

Options (that I know of):

1. Add extra condition to existing task-based UI action - current.sys_class_name != 'change_request'

2. Duplicate the UI action, set the new record to active= false and use the 'overrides' field to specify the original action to override

3. Duplicate the UI action, set the new record to active = false and give it a lower order value whilst maintaining the same action name (and adding a unique one to both records if empty)

4. Duplicate the UI action, set the new record to active = false and set the table to change_request whilst maintaining the same action name (and adding a unique one to both records if empty)

5. Duplicate the UI action, set the new record to   condition = false and use the 'overrides' field to specify the original action to override

6. Duplicate the UI action, set the new record to condition = false and give it a lower order value whilst maintaining the same action name (and adding a unique one to both records if empty)

7. Duplicate the UI action, set the new record to condition = false and set the table to change_request whilst maintaining the same action name (and adding a unique one to both records if empty)

Notes/Observations:

- Option 1 seems simplest but amending an OOTB ui action ultimately causes more work during system upgrades. It can also have a horrible impact in a qualified and validated environment as you're potentially amending something which is used by multiple applications (incident, problem, change etc).

- Leaving a UI action active means the condition will get evaluated, but leaving it inactive may leave it vulnerable to being removed by a future developer

- I like the idea that defining a UI action with the same 'action name' in an extended table will override a UI action defined against a parent table as it feels closer to an object-oriented approach - but then what's the point of the 'overrides' field? and are there any downsides?

It's a nice problem to have though. I'd hate to be sitting here saying "why can't I achieve this!"

Thanks guys

Dan

1 ACCEPTED SOLUTION

Anurag Tripathi
Mega Patron
Mega Patron

Hi Daniel,



As you rightly said that there are multiple ways to do this and all of them will provide the 'RIGHT' result.



Burt generally speaking in such scenarios i go with the override the ui action option. Its neat, limited to a table or scope and you will save yourself from touching a global object that might have cross stream impact.


i got confused with so many options so ill just write it down:



So create a UI Action on change_request with same name, same action name and same order and condition = false.


-Anurag

View solution in original post

6 REPLIES 6

Anurag Tripathi
Mega Patron
Mega Patron

Hi Daniel,



As you rightly said that there are multiple ways to do this and all of them will provide the 'RIGHT' result.



Burt generally speaking in such scenarios i go with the override the ui action option. Its neat, limited to a table or scope and you will save yourself from touching a global object that might have cross stream impact.


i got confused with so many options so ill just write it down:



So create a UI Action on change_request with same name, same action name and same order and condition = false.


-Anurag

Hi Anurag,



That's the approach I thought would probably win. Where this doesn't work is when the global (or in my case task) based record doesn't have an action name to begin with. 😞



This one here as an example:


https://instance.service-now.com/nav_to.do?uri=sys_ui_action.do?sys_id=b5a56f321b031100e90d928f3d071...  



But after a bit more searching and I've just found ServiceNow's recommended strategy which explains what to do when there is no action name...



[https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/administer/list-administration/...]


Override or remove a UI action for an extended table


This example describes how to override or remove a UI action for a table that is extended from another table.


About this task


When a UI action is defined for the Task table, it applies to all tasks, including incidents, changes, problems, and any other tables that extend the Task table. Similarly, a global UI action applies to every table. However, you can override a UI action for a specific table. This example demonstrates how to override or remove a UI action on the Task [task] table for only the Incident [incident] table.


Procedure


  1. Complete the following steps to override a UI action on the Task table for just the Incident table.
    1. Create a UI action on the Incident table with the same Action name.If the Action name is not defined, use the same Name.
    2. Enter a script that is specific to the Incident table.
  2. Complete the following steps to remove a UI action on the Task table for the Incident table.
    1. Navigate to the UI action definition for the Task table.
    2. Add the condition current.getRecordClassName() !='incident'.

- ServiceNow Platform Form Designer, Istanbul



To avoid all of this only i just keep everything same, name, action name, function, script...all same


I just open the original record, change the table name and condition, and so 'Insert and Stay' from the top menu.


-Anurag

k0a1a
Kilo Expert

In my case i.e. Istanbul, none of (Overrides | Condition | Active | Order) had any effect while "Action name" remains empty. So you'll have to modify parent action if you're out of luck and your parent action has empty "Action name".