Designing Simple Forms Personalizations for Functional Consultants

Forms Personalization: I kept reading about this amazingly new feature called 'Forms Personalization' but what really bothered me was almost all the articles / whitepapers had the targeted audience as ‘Admin / Developer’ who have some ‘knowledge of Oracle Developer, PL/SQL, Coding Standards and API’s’.

This really caught my attention and I spent about 2 hours trying to figure out what can a Functional Consultant like myself get out of this new feature. Good news is that you don’t need to have any technical knowledge to design some simple personalizations. So in this article, I have tried to explore some easy to design personalization’s which the Functional Consultants can easily build and test.

Why personalization’s are handy – Since Oracle Apps is a pre-built product, most of the clients would like to remove/ rename, change default values of some of the fields, buttons, tabs etc. Traditional method of getting all the above ‘extensions’ done was to ‘customize’ the form (by customizing the custom.pll) which was generally protected during upgrades / patching. Luckily most changes traditionally done using cutom.pll can be accomplished using Forms Personalization.

Functional Folks - How to quickly get started – The ‘personalize’ menu can be found at Help -> Diagnostics -> Custom Code -> Personalize. To prevent unauthorized users from changing the look and behavior of forms, please use the following profile options:
Utilities: Diagnostics = Yes / No
Hide Diagnostics = Yes / No

Four sections to define a Personalization – There are four sections in the define forms personalization form:
Rules Header – This is where you enter the rules and rule descriptions in plain English. You can sequence these rules using a number and enable/ disable any one rule by using the Enabled checkbox.
Conditions – Consists of Trigger Event: the event within the form that causes invocation of the rule, Trigger object: the context for the trigger event, such as a
particular block or item, Condition: an optional SQL fragment that, when it evaluates to TRUE, allows the rule to execute.
Context or Scope - 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.
Actions – Determines what the personalization does when the condition and context are true. Various types of actions available include ‘Property’, ‘Message’, Builtin’ or a ‘Special’. Based on the type, additional definition

Real world examples you can try – One of my banking client wanted the Journal Enter form to be customized for the following business rules:

1. Change the ‘Journal’ prompt to display ‘Voucher’
2. Journal description should always be in UPPER CASE
3. Do not display the Budget field, as budgets were not implemented
4. Note to display warning to change Period for prior period Journals.

The following screenshots explain how these four business requirements were implemented using Forms Personalization:

1. Change the ‘Journal’ prompt to display ‘Voucher’:




2. Journal description should always be in UPPER CASE:



3. Do not display the Budget field, as budgets were not implemented:



4. Note to display warning to change Period for prior period Journals:



Journal Entry Form after Personalizations:

When opening the form, the following note gets displayed:



Journal Entry Form after Personalization (Note - Voucher, Budget not displayed and Description in Upper Case: