We recently introduced application file tables as the replacement for update synch tables. It's great that these changes can be tracked in update sets but there are more features that could be important, especially for 3rd party vendors publishing applications.
For this example, we've created a new app config table extended from App File table. In our development instance we also created 3 records. As you can see we identified the rows as readonly, replace on upgrade, and no policy so we can keep track of what's happening. The protection policy is set from the app file form context menu, "Show File Properties".
When deploying this application to another instance the records will automatically be loaded since they are app file types. As expected, we will not be able to modify the read-only record. This is a useful feature if you need to improve application stability or application upgradability by limiting what customers can modify. The customer can modify the other records. The "Customer update" field will identify which records have been updated or inserted in an App File table.
Back to our development instance, we also created a new table to store some data. In this case we aren't concerned with tracking changes in update set so we didn't extend the app file table. However, we would like to ship the application with some default data and demo data. Based on the steps to build demo data we previously covered, we added a few rows of demo data. We also created a record that we always want deployed and upgraded with future releases, overriding customer changes. The demo records will only be installed on initial install of the application if the customer opts to install with demo data.
Once deployed to the customer instance the customer has modified all of the Flight rules values.
The next time the customer receives an application update, the data record that was set to replace on upgrade will be reset to the vendor version automatically.
Interesting note: as of patch 2 hf1, the replace on upgrade feature seems to work great on data files but is not honored in app files. I'm looking into this to better understand the use of this attribute.
The full list of changes to an application's app files can be viewed from the application record under the Local Customizations related list.
For local customizations that are changes to store application source records, you have the option to revert to the store version just as you can revert ServiceNow delivered app files.