Form Personalization on Release 12

The Form Personalization feature allows you to declaratively alter the behavior of Forms-based screens, including changing properties, executing builtins, displaying messages, and adding menu entries.

For each function (a form running in a particular context based on parameters passed to it), you can specify one or more Rules. Each Rule consists of an Event, an optional Condition, the Scope for which it applies, and one or more Actions to perform.

Rules can be specified as acting either at the Function level (the default) or at the Form level. In this latter case they are applied for all functions that run the form. When creating rules at the Form level, pay close attention to the Sequence number and how it will blend with other rules at the function level for the same form.

An Event is a trigger point within a form, such as startup (WHEN-NEW-FORM-INSTANCE), or when focus moves to a new record (WHEN-NEW-RECORD-INSTANCE). There are standard events that almost every form sends, and certain forms send additional product-specific events.

The Scope is evaluated based on the current runtime context to determine if a Rule should be processed or not. The Scope can be at the Site, Responsibility, User, or Industry level. Each Rule can have one or more Scopes associated with it.

The Condition is an optional SQL code fragment that is evaluated when the Event occurs; if it evaluates to TRUE then the Actions are processed.

Each Action consists of one of the following:

·                     setting a Property, such as making a field Required or hiding a Tab page

·                     executing a Builtin, such as GO_BLOCK, DO_KEY or FND_FUNCTION.EXECUTE

·                     displaying a Message

·                     enabling a menu entry

Once Rules are defined, when the target function is run then the Rules are automatically applied as events occur within that form.

Although the Form Personalization feature is declarative, the intended audience is a person familiar with Oracle Forms including the PL/SQL programming language, and the Oracle Applications Development Guide. 

Additionally, any change made could interfere with the base code of a form (the code that Oracle ships), thus the Support statements must be followed diligently.