Monday Apr 23, 2012

Customizing FND Message Numbers in Oracle Fusion Applications: Manage Messages UI and UX Stakeholders

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.

Manage Messages UI in Oracle Fusion Applications

Manage Messages UI in Oracle Fusion Applications

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:

The message number in Oracle Fusion Applications FND messages is shown after the message

Message number in Oracle Fusion Applications FND message shown after the message text

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.

Tuesday Sep 27, 2011

How to Write Effective Application Error Messages for Users

Whenever I’m asked by technical writers how they should write a “frontend” or a “backend” error message I’m reminded of the old Kerryman joke with the “I wouldn't start from here” punchline (this joke may have been localized for your region).

Starting the error message design process with a frontend or backend categorization is not useful from a user experience perspective. Users don't care for such a distinction. All users care about is how effectively the application messages communicate with users as they do their work!

It’s tough deciding on what a “frontend” error message is, anyway. Is it a client-side validation concept? Maybe they're ADF Faces validator and converter messages?

Hardly, as these error message are visually indistinguishable from other ADF af:messages validation on editable components that require a push of data to the server for validation, and can coded as business rule exceptions deep down in the model layer.

These error messages can also be shown on ADF page components that are then outlined in red, along with a note window with the message and navigation buttons to move between components showing exceptions.

These messages then roll up to a page-level list that includes a hyperlink to the name of the component if the user chooses to address all the component-level errors together. So, that consideration doesn't work either.

ADF messages could also be page-level popups, or inline on the page, and used for messages that don't reference editable fields at all, for complex business rule validation or for UI rules such as unsaved changes, and so on.

And then “backend” error messages, what are they, exactly? Are they all diagnostic logs triggered by the supportability framework when an incident is raised? They could be text-based output logs for sure, but they could be presented in custom ADF message dialogs too. These messages could also use user interfaces (UIs) designed by product teams for third-party application or web services integrations, for errors (usually from the FND messages dictionary) thrown by the execution of PL/SQL or other programs, and so on.

So, this frontend versus backend categorization is problematic as a decision-making concept. Instead, knowing why the message appears (the validation or UI rules fired up in response to user or application activity), and what the raising technology offers in terms of visual display and output, lets you know how to phrase the error message accordingly.

For example:

  • A decision about who (or what) was acting, and who needs to act in response, lets the writer make a decision about the use of active or passive voice in the message text.
  • Knowing if the exception is from an ADF component validation means writers don't need to tell the user which UI component has an issue or how to get there. The component is highlighted in red and the message is presented beside it along with navigation buttons to other components with errors. The name of the component is shown in the page-level list as a clickable link.

  • If it is page-level business rule message dialog not using component-level validation, then the writer may need to explicitly tell the user which components need redress, where, and how.
  • If the message is in a long text output format, writers will need to compose the text in a way that allows for easy online reading, and so on.

Knowing this information also enables writers to discover if ADF Faces provides a message natively, out of the box (navigation, validators, converters, missing values, and so on), saving the writing of a new one.

For a more useful starting point consider to a superior error messaging UX, maybe answer the following questions and then apply error message text composition basics about writing cause and action using the appropriate style, grammar and terminology:

  • Is the exception the result of validating ADF editable components on a page?
  • Is the exception the result a navigation action between ADF pages?
  • Is the exception by the result of validating business rules at a page-or task-level action on ADF pages?
  • Is the exception the result of a process? Does the result of that process need to be in a printable or readable output file and/or need to be indicated elsewhere as a message dialog or even a notification?
  • Is the exception the result of a third-party application or web service integration that requires a custom designed UI?
  • Who or what is acting to make this message appear, and who or what needs to act in response, and how?

Very likely no one person in the development team will know all the answers, so writers and developers must work collaboratively to find out the answers before the message text is written.

Tuesday Jun 21, 2011

Apple Gets the Message About Centralized Notifications on Mobile

Yep, looks like iOS5 introduces a centralized messaging system: the Notification Center.

Image of notification center referenced from Copyright acknowledged.

Wonder where they got that idea from?

Seriously, way to go though; this matches and probably betters what I really like about Android’s notifications system. I’ll have to check it out myself, though.

Application UX's own research last year confirmed that the centralized approach really is something that enterprise users in the US and in the UK wanted. The iOS5 feature will really help Apple in the enterprise user market too. Up to now, iOS has been dismal in the notifications space anyway, IMO, and pretty useless for users on the go using different apps and communications methods (business and personal - the line has become so blurred now) together and who need to manage all those their notifications efficiently, reflective of how they work.

I'll be also watching out for what personalization features are offered around the notification center, and what level of control users have over when, where, and how they get those notifications.

Good job, Apple.

Monday Mar 14, 2011


[Read More]

Thursday Mar 10, 2011

Attending UA Europe 2011 in the UK, June 2011

[Read More]

Wednesday Dec 22, 2010

Chrome Web Browser Messages: Some Observations

I'm always on the lookout for how different apps handle errors and what kind of error messages they show (I probably need to get out more). I use this 'research' to reflect on our own application error message patterns and guidelines and how we might make things better for users in future. Users are influenced by all sorts of things, but their everyday experiences of technology, and especially what they encounter on the internet in their own, increasingly sets their expectations for enterprise applications.

I recently came across a couple of examples from Google's Chrome web browser that got me thinking. In the first case, we have a Chrome error message about not being able to find a web page. I like how simple, straightforward messaging language is used along with the optional ability to explore things a bit further--for those users who want to.


The 'more information' option shows the error encountered by the browser (or 'original' error) itself in technical terms, along with an error number. Contrasting the two messages about essentially the same problem reveals what's useful to users and what's not. Everyone can use the first message, but the technical version of the message can be explicitly disclosed by the more advanced user to pursue the problem further. More technical users might search for a resolution, using that "Error 324" number, but I imagine most users who see the message will simply try again later or recheck their URL. Seems reasonable that such an approach be adopted in the enterprise space too, right?

Maybe. Generally, end users don't go searching for solutions based on those error numbers, and help desk folks generally prefer they don't do so. That's because of the more critical nature of enterprise data or the fact that end users may not have the necessary privileges to make any fixes anyway. What might be more useful here instead is a link to a trusted source of additional help provided by the help desk or reputable community. This takes me on to the second case, this time more closely related to the language used in messaging situations.


Here, I first noticed by the using of the (s) approach to convey the possibility of there being one or more pages at the heart of the problem. This approach is a no-no in Oracle style terms (the plural would be used) and it can create translation issues (although it is not a show-stopper). I think Google could have gone with the plural too. However, of more interest is the use of the verb "kill", used both in the message text and the action button label.

For many writers, words like "kill" and "abort" are to be avoided as they can give offense, or so I'm told. I am not so sure about that judgment, as really the use of these words cannot be separated from the context. Certainly, for more technical users, such words are fine and have been in use for years, so I see no reason to avoid using them if the audience has already accepted them. Most end users too, I think would find the idea of "kill" usable and may even use the term in every day speech.

Others might disagree--Apple uses a concept of Force Quit, for example. Ultimately, the only way to really know how to proceed is to research these matter by asking users of differing roles and expertise to perform some tasks, encounter messaging experiences like the two here, record the findings, analyze them and then make recommendations for our designs. Something to do in 2011!


Oracle Apps Cloud UX assistance. UX and development outreach of all sorts to the apps dev community, helping them to design and deliver usable apps using PaaS4SaaS.


Ultan Ó Broin. Senior Director, Oracle Applications User Experience, Oracle EMEA. Twitter: @ultan

See my other Oracle blog on product globalization too: Not Lost in Translation

Interests: User experience (UX), PaaS, SaaS, design patterns, tailoring, Cloud, dev productivity, language quality, mobile apps, Oracle FMW, and a lot more.


« July 2016