Scope error for sys_choice records on pm_project table

[Louis Savalli]

Has anyone run into an issue where ServiceNow thinks you are creating sys_choice records in another scope even though you are in global?

To recreate this, go to the pm_project table definition and open up a string/choice list field whose underlying table is Task (this bug doesn't happen with fields on planned_task or on pm_project).  Scroll down to the choice list related list and add a new one.  After you add it, go back and look at your new sys_choice record, and you should see something similar to my screenshot below.  And if you look at the sys_update_xml record that was created, it will also have the Goal Framework scope.  I've been able to recreate this on two separate instances.  Any ideas what this is or how to fix it?

[Louis Savalli]

I kept researching and found that it's because the choice list belongs to a Choice Set (sys_choice_set) which is in the Goal Framework scoped application.  Is this a bug, and if so, will it be fixed?

[Ankur Bawiskar]

@Louis Savalli 

this article explains it

Working with Choices in ServiceNow 

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Ankur Bawiskar]

@Louis Savalli 

Hope you are doing good.

Did my reply answer your question?

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Louis Savalli]

Thanks but I'm wondering specifically why the sys_choice_set for the impact field is in the Goal Framework application.  Why not in the global scope?