Application Scoping - Inconsistent Behaviour on New Dictionary Entries

The SN Nerd
Giga Sage
Giga Sage

For the 'Catalog Item' table, I am trying to create a new Dictionary Entry in a Scoped Application.
I get the following error message:

"Invalid 'Table' selected on the Dictionary Entry record. The 'Catalog Item' table is in application 'Global', but the current application is 'DevKIT/RDB'. The 'Table' field can only select 'Global' tables with read access enabled."

find_real_file.png

AS shown below, 'Read access' is enabled for 'Catalog Item':

find_real_file.png

You might then say 'Allow configuration' isn't checked!

However, take a look at the User table:

find_real_file.png

Note that 'Can read' is checked, and 'Allow configuration' is not checked.
However, I am able to create fields in my Application Scope for that table.

find_real_file.png

I then selected 'Can create' and 'Can update' on the Catalog Item table to reflect the same setting as the User table. 
find_real_file.png
It matches the exact same Application Access setting as the user table, for which I can create Scoped fields, but I still cannot add a Dictionary Entry to the table.
Only setting 'Allow configuration' allows me to do this, but I don't need to do this for the User table.

So, what is going on here? 
Is the error message incorrect, and/or is this a defect?

 

 

 


ServiceNow Nerd
ServiceNow Developer MVP 2020-2022
ServiceNow Community MVP 2019-2022
1 ACCEPTED SOLUTION
14 REPLIES 14

Nice, hopefully something is done about it! One of my outstanding HI problems just got marked as 'Won't Fix' today. But best of luck.

SaschaWildgrube
ServiceNow Employee
ServiceNow Employee

I ran into the same issue.

My intention was to implement a deactivation feature for Service Portals (yes, OOTB this does not exist).

To do that, I wanted to add a new field (within a scoped app) to the global sp_portal table.

I configured the sp_portal table to allow access from all scopes, allow configuration, allow the creation of new fields, and all access (create, update, write, delete).

But still I get the same error message when trying to add the field within Studio.

This script however does the trick:

var gr = new GlideRecord('sys_dictionary');
gr.initialize();
gr.name = 'the_global_table_of_your_choice';
gr.sys_scope = 'your_app_scope';
gr.element = 'x_yourappscope_yourfieldname';
gr.column_label = 'Your Field Label';
gr.internal_type = 'boolean'; // or whatever type you need
gr.default_value = 'true'; // likewise
gs.info(gr.insert());

Russ T
Kilo Guru

After wrestling with this for hours, I cobbled together all advice I could find then added to it. Here was my solution:

 

  1. Switch to Global scope
  2. Navigate to sys_db_object table
  3. Filter by the table you want to add a field to
  4. Ensure the column "Allow New Fields" is visible in your list view
  5. Check the value in this column for your table is "true". If not, double click that entry and set it to true
  6. Now enter into the table configuration by clicking the table name or the (i) icon
  7. Set all the values as follows:

    RussT_0-1725367363299.png

  8. Save the record
  9. Head to Scripts - Background
  10. Execute the following script: gs.invalidateCache();
  11. Switch to your scoped application
  12. Navigate to sys_dictionary.do to create a new dictionary entry (field)
  13. Select the table you want to add the field to and fill in the details and submit
  14. The field should now be created

 

Depending on your case you may want to switch all the settings above to how you found them. However, as you'll be doing this in a sub-prod instance (right!?) it's not normally essential as they'll be set back when you clone. Also note because these settings changes are in the global scope, they won't be captured in your application / scoped update set.

Nearly one year later, I found this again and it was helpful (!). 

 

NOTE: gs.invalidateCache(); will make your system seem unresponsive for several minutes. This is normal. So, avoid doing it when you know other devs are working, unless you warn them first 🙂