The global list actions you're seeing are controlled by the `sys_ux_list_action` table, and they get automatically associated with new UX Action Configurations through some behind-the-scenes logic in the platform.
When you create a UX Action Configuration, ServiceNow automatically links these default actions (typically New, Edit, Delete, and one other depending on your instance version) via the `sys_ux_list_action_config` table. This is handled by platform code that runs during the UX Action Config creation process.
For hiding them on just your custom workspace, you've got a couple of solid options:
The cleanest approach is to create workspace-specific UX Action Configurations. Clone your existing config, remove the unwanted global actions from the cloned version, then associate that new config with just your custom workspace. This way other workspaces keep using the original config with all actions intact.
If you need more granular control, you can also use condition scripts on the individual list actions. In the `sys_ux_list_action` records, there's a condition field where you can add logic like:
```javascript
// Only show if not on your custom workspace
current.getTableName() == 'your_table' && !gs.getUser().hasRole('your_custom_workspace_role')
```
The condition approach works but gets messy if you have complex workspace logic. The separate config route is usually cleaner and easier to maintain.
One heads up — if you're on a newer release, double-check that these aren't coming from the newer Declarative Action framework instead of the older UX Actions. The setup is similar but the table structure is slightly different.
