Application files included within an scoped app that users in global scope can modify without the requirement to switch application scopes.

[Todd Adams1]

Hello,

Use case: Several application files will be included within an scoped application.

I do not want to require users to be required to switch from global to the application scopes to edit/delete them.

Create application files to include sample data | ServiceNow Docs

It seems the same process is followed whether these are files are demo data or configuration files.

Since new records to table (within the application scope) do not require users to switch application scopes, application files bundled with the application scope should also not require this, either. It is confusing to users.

Tried using cross scope privileges, but it still requires the user to switch scopes if the original files was include within that other scope.

Other options we have thought of (update set in global, scripts that generates these in global), but these options require unnecessary overhead.

Can this be done and if not, are there other options not listed here?

[Maik Skoddow]

Hi @Todd Adams 

on page https://docs.servicenow.com/bundle/rome-application-development/page/build/applications/concept/c_Ap... you can read:

Application files are configuration records that allow developers to extend application functionality. Application developers create application files when they add configuration records for application logic such as business rules, workflows, and script includes. Scoped applications do not own these tables, but they do own the records (files) within these tables. For example, adding a business rule to check for available rooms from the Conference Room table adds an application file to the Business Rule [sys_script] table. Application developers can view the complete list of application files from the custom application record.

Therefore, I'm wondering about your statement: "I do not want to require users to be required to switch from global to the application scopes to edit/delete them" A normal user should not be able to edit or delete application files! Only developer are allowed to do this as part of an organized process to continue development of the application. And a developer knows that a scope change is required to change Application Files (Studio does this in the background for you).

So why do your users change Application Files? Can you please provide more details, examples & screenshots to help us understand you better?

Kind regards
Maik

[Todd Adams1]

Thanks for the response. 

I've had read through the above documentation. It seems like there is no easy way to deploy files into global from a scoped app or allow users to edit existing files that exist in a scoped app without having the extra click of "this records exists in a scoped app xyz, click here to edit." I was hoping there was a cross scope privilege that was missing. Update set could also do this, but that feels like an extra step users should not need to take.

One of my biggest frustrations with ServiceNow is the lack of real world examples to help explain how something works or what is possible. Adoption at our organization has been strong because of the personal instances we can create. The demo data that is included here is very helpful, wish there was even more "demo" data with the configuration type files (business rules, UI scripts, UI Pages, etc).

We are creating a new CMDB Class, called map layers.

These are highly customizable JSON files that users can create/generate and can become complex very quickly. Having several map layer examples that can be used and available to users is key. Many of these will be set to inactive, but quickly can be used by simply by making them active.

Users can/should create map layers in the global scope with the cross scope privileges that are included.

I know it is just an extra click for users with "map admin" (role we created) to click "edit this record in application scope xyz" to edit/add these records, but they should not need to do that since they do not need to do to this to add new records.

Practically, many users simply won't do that because they don't know what it means and they should not need to know. in this example, it is an extra unnecessary (in this case) click that prevents full adoption.

Eventually, we would like to use the guided setup where users can select what type of map layers they wish to install, but I think they will also be created in the scoped application?

[-O-]

I believe you missed the main point of @Maik Skoddow's post: users are not meant to be messing with application files, the ones that show the message you mention. Only developers are meant to modify those (application) files.

[Todd Adams1]

I was aware of the existing restrictions, but looking for a workaround given my use case.

Perhaps this is a better way to phrase the question...How do we give sample data to users without needing to send them an update set installed in global that provides concrete working complex examples they can build upon.

The answer may be put them in the application files and provide users access to edit them, which gets back to needing to click the extra "this file exists in xyz application scope, click here to edit it". The folks editing these files are GIS developers but not ServiceNow developers.