Scoped Application UI Policy on Global Field

Denise Taylor1 · ‎10-24-2019

I have a scoped application that needs to make UI changes to global fields (i.e. set mandatory, read-only, etc). I have tried to create these UI Policies in the scoped application, but global fields are not available in the UI Policy action drop down. I have been able to get around the issue by using SetMandatory(), but now I have a requirement to set a global field to read-only based on the value of a scoped field, but the global field isn't available in the UI Policy Action "field name" drop down. Once again I tried getting around this with a client script, but SetReadOnly() doesn't seem to work.

1) Why are global fields being restricted in the UI Policy Action field name drop down in the New York release, and

2) How can I meet this scoped application requirement of setting a global field to read-only based on the value of a scoped field and have that functionality as part of the scoped application?

Denise Taylor1 · ‎11-02-2019

Yes, I understand. However in this case I'm trying to augment existing OOB functionality. I don't want to extend the table or fields, I simply want to compliment what is already available OOB with additional functionality and options. We've all been doing this for years in global scope and adding "u_" fields as necessary to meet specific business needs. What I was hoping to do was to encapsulate those additional custom fields and functionality in a separate scope, which I can do for the most part except for in the cases below.

Below is a list of functionality I've found that cannot be affected on OOB (tables and fields) within scope.

- UI Policies (set Mandatory, Visibility, Read Only) & Data Policies
- Form Layouts, List Layouts, Related Lists, List Controls
- Table Changes (though I can add new scoped fields to existing OOB tables)
- Dictionary Overrides
- Before Query Business Rules (advanced with scripting)
- ACLs

I do wish ServiceNow would provide a workaround for us in the future so that we may fully contain all changes to both custom and OOB within a single application. For now, I'll be using a combination of custom scoped and global applications to track these changes.

Thank you!

View solution in original post

Chuck Tomasi · ‎10-24-2019

I'm not able to recreate the scenario you described. I can create a UI policy on a scoped app and pick fields on a global table (in my case work is extended from task and assignment group is available from the picker.) Let me know if I misunderstood. (Attempted on New York on my personal developer instance.)

Denise Taylor1 · ‎10-24-2019

I am in a scoped application trying to define a UI policy for a global field, but all I see are scoped fields. This is a domain separated instance, but global domain yields the same results.

Also, you can see when I'm in global trying to create a UI Policy, I cannot see the scoped fields

Build name: Newyork
Build date: 09-24-2019_1701
Build tag: glide-newyork-06-26-2019__patch2-09-18-2019

Chuck Tomasi · ‎10-24-2019

Interesting. I think our difference is that you are using a domain separated instance. I don't have access to one of these. Unless someone has some additional information here, I recommend reaching out to customer support on this one. Not sure if it's a bug or if there's a real reason why it's behaving this way.

Please keep the community posted on what you find.

Denise Taylor1 · ‎10-31-2019

Well Chuck, so far the answers back from Hi have been dismal. After missing the mark a couple of times on possible resolutions, I finally got the ticket escalated to a P2 and now, the answer coming back from Hi is that this is "expected behavior." They are referencing this page in docs for the explanation.

Not to be critical, but this really cramps a developer's ability to scope customizations to OOB. My opinion has always been that we want to scope as much as we possibly can, both from a protection standpoint and because binding artifacts to applications makes them easier to track and move around. This feature restriction forces us back into global scope (and working with update sets), as explained by Hi below, which both affects our ability to promote to the Store as well as forces us to remember that some of our scoped applications are two-part (i.e. scope/global).

CS4425879: "Scope application is to restrict access to application files and data. Since the documentation confirms the behavior, you will have to write UI policies on the global application if you want to access and set UI policy actions on the global table fields."

Bummer.