Scoped Application UI Policy on Global Field

[Denise Taylor1]

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?

[Sri61]

Hi Denise,

UI Policies can only be created on fields that exist within your application scope and mainly Application scoping protects applications by identifying and restricting access to application files and data. And so you can not create a UI Policy on a field that does not belong to the scope itself. Hence this is platform expected behavior

In this case, it looks like the company field is not present within your scoped app whereas the company field belongs to the Global scope. So if you want to create a UI Policy you could extend the company table or task table within your scoped application and you will be able to create a UI Policy on company field.

 Hope this information helps,

Regards,

Sri

[Denise Taylor1 · Accepted solution]

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!

[Chuck Tomasi]

I invite you to voice your request on the Idea Portal.