Customizing FND Message Numbers in Oracle Fusion Applications: Manage Messages UI and UX Stakeholders
By ultan o'broin on Apr 23, 2012
I am often asked about removing the numbers that are shown with error messages in Oracle Fusion Applications. In fact, this can be done easily using the Manage Messages user interface (UI) Message Number field. A Manage Messages task flow is integrated into the Oracle Fusion Functional Setup Manager, and access to this is documented in the Oracle Fusion Applications Developer's Guide 11g.
But before you do, let’s explore what these numbers are for, and if and when you might want to remove then, and what the process should be.
Message Numbers Explained
These message numbers are assigned to error messages and warning messages stored in the FND messages table. Each product has a message number range assigned and the number itself takes the format of a product short code followed by a unique number. For example:
For customer extensions too, a reserved number range for FND messages is provided: 10,000,000 to 10,999,999.
Unlike the Oracle E-Business Suite (EBS) FND messages, these numbers appear after the summary message and not before. There is no Oracle Fusion Applications user preference to turn such numbers on or off or to hide or disclose them when a message is shown. They’re either there or they’re not. The numbers can also be on FND messages used for warnings at times.
Oracle Fusion Applications also uses ADF messages stored in resource bundles, and not just the FND messages ones. The ADF error messages are usually provided for native validation (such as for required fields, validators and converters) or navigation between ADF components. These types of messages do not have the numbers. Neither do any of the so-called common FND messages.
The Oracle Fusion Applications Developer's Guide 11g is your friend for understanding the message types.
How Are FND Message Numbers Used?
The numbers are used as reference indicators for Oracle Support to look up knowledge base information about reported errors or incidents. Because the message numbers are the same regardless of the language translation means that Oracle Support teams do not actually need to have a translation of the message text itself and can cross-reference resolutions from English if necessary.
The numbers are also used by AppsLogger when an incident is created and are included in the text output for logs.
Generally, Applications User Experience (UX) research shows that only internal help desk personnel or other enterprise support representatives want to report issues or message numbers to Oracle Support. Help desk operators do not like apps end users searching for their own solutions externally (apps user profiles are different to DB admins who might Google ORA numbers, for example). Instead, the help desk prefers their users to report issues to the help desk directly (or in the case of app failure by way of an implicit or explictly-raised incident). Frankly, even when end users do look up these numbers on the Internet (assuming they can), there is little they can do with the information anyway.
All said, you may find that some end users are irritated by these numbers and can consider removing the numbers on user experience (UX) grounds.
Which Messages Numbers Could Be Removed?
When might you want to remove the FND message numbers? In my UX opinion, the following types of FND messages are worth considering for customization in this regard:
- Messages for simple client-side, individual ADF component validations.
- Messages used for navigation or other UI rules.
- Warning messages with questions that require confirmation by users before proceeding.
- Common messages created in a product area that might or might not raise an incident.
I recommend that you never remove a number from an error message, warning or information message that is used for an application failure, or for an incident or log creation (AppsLogger won’t work unless there is a unique number there). Complex business rule messages, at EO level, for example, are also best left with message numbers.
You can use these guidelines when creating new FND messages too. If the message number is not in the FND message table, the message will still display. The number does not have any impact on the rendering.
Removing Numbers: Who Needs To Be Involved?
Successful implementations and customizations require the engagement of end users but also other stakeholders in a requirements and change management process to agree what the user experience will be.
So, if you are considering removing these message numbers, then you need to understand the context of use and identify appropriate stakeholders. These stakeholders may be internal and external to your organization. I suggest the following stakeholders for deciding about message numbers: end users, development teams or consultants who know about incidents and validation, internal help desks, internal training groups, Oracle Support, or other support representatives that you use.
After that, then you can make decisions about numbers changes. Do not just remove the message numbers without stakeholders, or without gathering your use case, assessing the real UX impact of their presence (users just don’t like ‘em or are they actually consuming time dealing with complaints about them and adding no task completion value?), and determining which numbers are really important to your help desk, support representatives and also to Oracle Support.
By the way, FND messages are seed data so changes are patch and upgrade survivable just like in Oracle EBS.
Questions or UX advice needed on any of this? Find them comments.