The application contains customization layer that allows you to make customizations which affect only certain instances of an application. For example, the application has a layer for US region. When you customize an artifact, you can choose to make that customization available only for US region.

Customizations you make are not saved to the base standard artifact. Instead, they are saved to an XML file that is stored in an Oracle Metadata Services (MDS) repository. This XML file acts like a list of instructions that determines how the artifact looks or behaves in the application, based on the layer that is controlling the current context. The MDS Customization Engine manages this process.

For example, say you want to customize the Applicant fragment by adding a new Passport field, but only for US region. Before you make your customization, you first select the layer to make your customization in, in this case the region layer whose value is US. When you make your customization by adding the new Passport field in the Application fragment, an XML file is generated with the instructions to add the field, but only in the region layer, and only when the value is US. The original page file remains untouched. The MDS Customization Engine then stores the XML file in an MDS repository.

Now, whenever someone logs into the application and requests an artifact, the MDS Customization Engine checks the repository for XML files that match the requested artifact and the given context, and if there is a match, it layers the instructions on top of the base artifact. In this example, whenever the Application page is requested (the artifact) by someone where US region customization is applied, before the page is rendered, the MDS Customization Engine pulls the corresponding XML file from the repository and layers it on top of the standard Application page, thereby adding the new field.

All users of the application can personalize the pages. Users can move elements around on a page, hide elements, and even add available elements to their page. When they do this personalization, the MDS Customization Engine creates an XML file specific to that user.

For example, say User 1 personalizes the Application page. There will then be an XML file stored in the repository, noting the changes that user made. When User 1 logs in, as in the previous example, the MDS Customization Engine pulls the XML file with the customizations from the repository and layers it on top of the standard Application page. In addition, the engine pulls the XML file with User 1's personalization’s, allowing the user to see the personalization changes along with the US region changes. When other users log in, they do not see User 1's personalization changes.

These layers are applied in a hierarchy, and the highest layer in that hierarchy in the current context is considered the tip. Within the default customization layers, the Region layer is the base layer, and the User layer is the tip. If customizations are done to the same object, but in different layers, at runtime, the tip layer customizations take precedence. For example, if you customize the label for a field in the site layer and customize the same label in the industry layer using JDeveloper, the site layer customization will be displayed at runtime.

Because customizations are saved in these XML files, when you patch or upgrade your application, the base artifacts can be updated without touching your changes. The base artifact is replaced, and when the application is run after the patch or upgrade, the XML files are simply layered on top of the new version. You do not need to redo your customizations.

Before you create customizations, you must select the layer to which you want your customizations to be applied.