Administrators have been "personalizing" lists and forms in ServiceNow for years. It's time to mix up your lingo a bit. Now administrator "configure" list and form views when they want to define the global default for all users.
In the previous post we covered how to track changes to application files in an update set so they can be moved between instance environments. Sometimes, especially when you are building a vendor application that will be distributed to multiple customers, you might want the option to provide initial data or demo data without defining them as application files to be tracked in update sets once they are deployed.
When creating new tables for an application they can generally be classified into two categories, configuration and data. Configuration records are general application settings or process information, and usually needs to exist for the application to work correctly. This means that they should be consistent between dev, test, and production instances so we need a way to migrate these records when they are changed. In pre-Fuji releases configuration data tables were defined by using the update_synch attribute on the table. Inserts and updates of records on update_synch tables are captured in update sets which can be moved between instance environments.
I'm a bit old to search for easter eggs this spring but I did have a little adventure yesterday when I was trying to find all of the hidden report settings. Once you know where to look the new interface is impressive.
Look, it's more talk about application scopes. I told you this was a big deal. Today we'll cover the settings that control access between application scopes. By access, I mean access to data as well as configurations on tables in other scopes.