PL/SQLintermediate
CUSTOM.pll and Forms Personalization
Explain the two supported mechanisms for customizing Oracle Forms-based screens in EBS without modifying seeded forms
Two supported ways to change an EBS form's behaviour without touching Oracle's .fmb files. The choice between them is a standard question.
CUSTOM.pll is like giving a stagehand a master remote control that can react to any cue in the script (full programmability), while Forms Personalization is like sticky notes taped to specific scenes saying 'change the lighting color here' — simpler, safer, but limited to what the sticky-note format allows.
Key Concepts
1
CUSTOM.pll is a library EBS calls at defined points.
WHEN-NEW-FORM-INSTANCE the form opened
WHEN-NEW-BLOCK-INSTANCE the cursor entered a block
WHEN-VALIDATE-RECORD a record is being validated
SPECIAL1 .. SPECIAL45 custom menu entries2
Every Forms screen calls it, so your code identifies which form it is in and acts:
3
PROCEDURE event(event_name VARCHAR2) IS
form_name VARCHAR2(30) := NAME_IN('system.current_form');
BEGIN
IF form_name = 'APXINWKB' AND event_name = 'WHEN-NEW-FORM-INSTANCE'
THEN
...
END IF;
END;4
Full PL/SQL, any built-in, any package. It requires compiling the library and attaching it, and every
customisation for every form lives in one file — which becomes its own maintenance problem in a large
installation.
5
Forms Personalization is declarative. Conditions and actions defined through a screen, stored as
metadata:
6
Condition: Trigger = WHEN-NEW-ITEM-INSTANCE
Item = INVOICE.INVOICE_TYPE
Action: Property -- set INVOICE.PO_NUMBER Required = TRUE7
No code, no compilation. It can be scoped to a form, a function, a responsibility or a single user, and it
migrates between instances with FNDLOAD.
8
Which to choose.
Personalization make a field required, change a prompt, hide a
button, default a value, show a message.
Fast, safe, no compile.
CUSTOM.pll anything needing real logic: calling a package,
complex conditions, launching another form
with parameters.9
The practical argument for trying personalization first. It is metadata, so it survives patching
cleanly, it can be disabled without a code change, and a functional consultant can build it.
10
Reaching for CUSTOM.pll for something a personalization handles means a compile cycle and a library that
grows until nobody wants to change it.
11
And the third option, which is never. Modifying a seeded form is not on this list. A patch replaces the
.fmb and the change is gone — silently, because nothing records that the file was customised.
.fmb
12
The hierarchy to state. Configuration first, then personalization, then CUSTOM.pll, then custom
objects. Never modify seeded code. That order is what the question is checking, more than the mechanics of
either tool.
13
What the interviewer is probing.1. "Which would you reach for first?" Probing: the order. Stalls: "CUSTOM.pll." Moves up:
form personalisation — it is declarative, upgrade-safe and visible in the application, where
CUSTOM.pll is code shared by every form.
14
2. "What is the risk with CUSTOM.pll?" Probing: the practical warning. Stalls: "None."
Moves up: it is one library for all forms, so a badly written branch affects unrelated screens,
and it must be merged after a patch replaces it.
15
3. "What can form personalisation do?" Probing: the capability. Stalls: "Hide fields."
Moves up: change properties, show messages, enforce validation, call built-ins and launch
functions or URLs on defined trigger events.
16
4. "What is its main limitation?" Probing: honesty. Stalls: "None." Moves up: it cannot
implement complex procedural logic, which is where CUSTOM.pll or a proper extension is still needed.