# How to Use Forms Personalization in Oracle EBS (No CUSTOM.pll Needed)

> Source: https://netray.co/erp-help/ebs-forms-personalization-how-to
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

Forms Personalization lets you change field properties, set defaults, run built-ins and show messages on any Oracle Forms screen through Help > Diagnostics > Custom Code > Personalize, with no custom library or forms compile required. Rules are stored per form and responsibility in FND_FORM_CUSTOM_RULES and apply at runtime for every user who opens that form.

## Kind

how-to

## System

oracle-ebs

## Erp

Oracle E-Business Suite

## Module

Forms / Personalization

## Query

how to personalize Oracle EBS forms without customization

## Alternate Queries

- oracle ebs forms personalization tutorial
- hide field on EBS form without custom.pll
- forms personalization WHEN-NEW-FORM-INSTANCE example
- oracle apps forms personalization vs CUSTOM.pll

## Applies To

Oracle E-Business Suite 11i, 12.1 and 12.2, Forms-based screens only (not OAF or HTML pages)

## Steps

### Create a Forms Personalization rule

**Items:**

- Open the target form under the responsibility you want to change, then go to Help > Diagnostics > Custom Code > Personalize.
- Click Actions to create a new rule, give it a sequence number, and add a Description that explains its purpose for the next person who edits it.
- Set the Trigger Event, most commonly WHEN-NEW-FORM-INSTANCE for form load, WHEN-NEW-BLOCK-INSTANCE for a block, or WHEN-VALIDATE-RECORD for field-level logic.
- Optionally add a Condition, for example :SYSTEM.CURRENT_BLOCK = 'HEADER' or a check against a profile option using fnd_profile.value in a PL/SQL condition.
- Define one or more Actions: Property (set Enabled, Visible, Required or Prompt on an item), Message (raise a warning or error), or Builtin (execute PL/SQL or a menu function).
- Save the rule, then reopen the form to test; Personalization rules apply for other users immediately in most versions without a forms restart.
- Set the Scope carefully: a rule saved at Function scope fires only for that specific responsibility/menu path, while Form scope fires everywhere the form is opened, including unrelated responsibilities.

## Sections

### When to use Personalization instead of CUSTOM.pll

**Body:**

Personalization is metadata-driven, does not require a forms relink or a custom library deployment, and is upgrade-safe, which is why Oracle recommends it for the large majority of field-level changes: hiding a field, defaulting a value, enforcing a required flag, or raising a warning message.

CUSTOM.pll is still needed for logic Personalization cannot express, such as multi-step procedural code or trigger events Personalization does not expose. The two can coexist on the same form, but that combination makes debugging harder because a change might be coming from either layer, so keep CUSTOM.pll usage minimal once Personalization can cover the requirement.

### Common actions: Property, Message, Builtin

**Body:**

Property actions are the most common: set ENABLED to PROPERTY_FALSE to disable a field, set VISIBLE to hide it, or set DEFAULT_TYPE and DEFAULT_VALUE so a field auto-populates from a constant, a profile option, or the result of a SQL statement.

Message actions display text with Error, Warning or Information severity when the trigger condition is met, useful for enforcing a business rule without writing validation code elsewhere.

Builtin actions run a stored PL/SQL block, which is how Personalization calls out to an existing package to validate data or populate a hidden field based on logic that does not fit cleanly into a single Property setting.

### Scope, conditions and troubleshooting

**Body:**

The Scope tab controls whether a rule applies at Responsibility, Function, Form, Block or Industry level. A scope that is too broad is the most common cause of a rule breaking an unrelated flow that happens to share the same underlying form.

Multiple rules on the same trigger execute in sequence order, and an earlier rule's condition or action can effectively short-circuit a later one, so when a rule seems to silently not fire, check the Enabled flag first, then the sequence order relative to any other rules on the same event.

## Pitfalls

- Forgetting to set Enabled to Yes at the top of the rule, so it silently never fires
- Using Form-level scope for a change meant for one responsibility only, breaking other flows that share the form
- Conflicting sequence order between two rules on the same trigger, producing inconsistent behavior
- Referencing an item name that differs from the internal block.item name shown in Forms Personalization's item picker, so the property never applies
- Not testing the rule on a personalization-enabled non-production instance before moving it, risking a bad rule reaching production users directly
- Assuming a Forms Personalization change applies to OAF or HTML pages, when those use a separate Personalize Page mechanism entirely

## Ai Angle

An AI assistant grounded in your EBS instance's FND_FORM_CUSTOM_RULES can read every existing rule on a form, flag scope conflicts before you save a new one, and turn a plain-English request like 'hide the Freight field unless the order type is Drop Ship' into the trigger, condition and action values to enter, rather than a practitioner working it out from the Personalization dialog alone.

## Faq

### Does Forms Personalization survive an EBS patch or upgrade?

**Answer:** Yes. Rules are stored as data in FND_FORM_CUSTOM_RULES, not as code changes to the form itself, so a standard patch or upgrade does not remove them, though you should still retest after major upgrades in case the underlying form's item names changed.

### Can Forms Personalization call PL/SQL?

**Answer:** Yes, through the Builtin action, which can execute a PL/SQL statement or call an existing package procedure, giving you a hook into custom logic without writing CUSTOM.pll code.

### How do I migrate rules between instances?

**Answer:** Use FNDLOAD to download the rule as a LDT file from the source instance and upload it to the target, the same mechanism used for other FND setup objects, or recreate the rule manually if only a handful of rules are involved.

### What is the difference between Forms Personalization and OAF Personalization?

**Answer:** Forms Personalization applies to classic Oracle Forms screens through the Help menu dialog. OAF Personalization is a separate mechanism for HTML self-service pages, accessed through the Personalize Page link, and the two are not interchangeable.

## Search terms

oracle ebs forms personalization, custom.pll alternative, forms personalization tutorial, when-new-form-instance trigger, fnd_form_custom_rules, oracle apps hide field, forms personalization scope, oracle ebs personalize form

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json