CUSTOM.pll versus Forms Personalization

It is indeed time to stop using CUSTOM.pll
If you are on 11.5.10, then it is important for development team to enforce the usage of Forms Personalization over CUSTOM.pll, where possible.

Most of the things that can be done using CUSTOM.pll can now be done via Forms Personalization.
However there are certain gaps for which we have no option but to rely on CUSTOM.pll

This article compares the two techniques i.e. CUSTOM.pll versus Forms Personalizations

Why should we prefer FP over CUSTOM.pll ?1.    CUSTOM.pll is a single file/entity, hence only one developer can make changes to CUSTOM.pll at any given point in time.
You may also read best practices in CUSTOM.pll at this link
2.    If for some reasons CUSTOM.pll causes issues in Production, you will have to re-release the code changes after another round of UAT.
Form Personalizations makes this much simpler by allowing you to disable specific personalizations.
3.    You do not need to resort to programming for trivial tasks like changing prompt, and more so for changing prompts in Muli-Lang environment




Lets do a quick comparison between Forms Personalization and CUSTOM.pll

Task/Business Requirement	CUSTOM.pll	Forms Personalization
Change LOV Query	Yes	Yes a. Create a New Record Group b. Attach new RG to LOV
Change field properties like Mandatory/Display etc	Yes	Yes
Zoom to another screen	Yes	Yes a. Enable Menu b. Trap the Menu event
Disable a Menu entry when certain conditions are met	Yes	No See Note-1
Display messages, warnings, hints etc	Yes	Yes
Display message with Questions, and conditionally execute code based on users response to the question	Yes	No
Execute PL/SQL Stored procedures	Yes	Yes
Change Navigation and Navigational Properties	Yes	Yes
Change block properties like “Query Where Clause” etc	Yes	Yes
Change is applicable across multiple screens, like Changing window title for all screens within one Organization/Responsibility	Yes	Yes See Note-2
Show FND Messages with their tokens replaced	Yes	See Note-3

Important: Oracle will keep on improving capabilities in Forms Personalizations.
Hence some of these limitations that we see now in Forms Personalization might disappear over a period of time.


Note-1
Once a menu has been enabled using Forms Personalization, it then can not be conditionally disabled. However the proposed workaround over this issue is to display a message when MENU is clicked in the scenario’s it was meant to be disabled.



Note-2
Lets say you want to change the window title for all the screens within a responsibility. In this case, in CUSTOM.pll you could do so by a pseudo code similar to below
    If fnd_global.responsibility like ‘XX%CASH%’ THEN
        Set window title ( ‘Note: All transactions are audited’);
    End if
As you can see, this can be achieved quite easily in CUSTOM.pll  and the changes will be visible across multiple screens in the context.
However, for Forms Personalization, you will have to go and personalize each and every screen for which you want this change to be effective.


Note-3
The proposed workaround is to display the message that is returned as a result from SQL Statement.





Time for some Q&A

Question: Should we migrate code from CUSTOM.pll into Forms Personalization?
Not really, there is no value in doing so, given that CUSTOM.pll is still supported and will remain so within the realms of Apps Unlimited.


Where is the metadata for Forms Personalization stored?
These personalizations are stored in FND tables



What is called first? Forms Personalization or CUSTOM.pll
First your form personalization is called, and then CUSTOM.pll is called.



Is forms personalization called for additional set of triggers vis-à-vis CUSTOM.pll?
Not really, the same set of triggers are passed to both CUSTOM.pll and Forms Personalization. To understand the fundamentals, visit this link CUSTOM.pll concepts