New application tables can generally be classified into one of two categories, configuration and data. Configuration records are general application settings or process information, and usually need 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.
When creating a table in Fuji there's a new way to get this functionality. There's also a new name for this type of record, it's called an application file.
If you know ahead of time that you want the table data to be captured in update sets, you simple just need to extend the Application File table. Your new table will inherit a number of features, including the ability to track all record changes in update sets.
The other benefit of application files is the ability to set a protection policy. We'll have more about this in a future post, but it basically means you can set one or more records as read-only so they can not be modified or deleted in the target instance. From an application file record, use the form context menu to access the File Properties form and set the Protection policy field.
If you already have created the table and want to add these features, you can migrate the table to an Application File extension almost as easy as it was to add the update_synch attribute in the past. Just open the table record and click the Track in Update Sets related link on the form.
In the next post we'll cover how to ship initial or demo data in your application that are not application file records.