Follow these guidelines for individual form fields:

• Validate data when users leave the field.
• Enable users should to complete fields on the current page in any order they want before need to submit the page using an action or navigate away from it.
• Validate required fields (indicated by * symbols) and interfield dependencies when users submit a page using an action, such as Save, Submit, Publish, and so on.
• Show error messages on editable fields using a component-level note window (figure 2). A list of these editable components includes a link to the field using the name of the field.
• Design heads-down data entry tasks for validating fields when the page is submitted using an action button. Messages appear in a list (figure 3).
• When component-level validation is not possible or for business rules that apply to the entire page, you can use a global message dialog box. This has no links to components, so name the fields with the errors in the message text to expedite resolution.

Follow these guidelines for tables:

• Show error and warning messages on editable fields using only a note window. A message list of editable components with messages includes links to the components.
• Rows may be programmatically marked with an icon in the row header indicating an error if teams can determine how to do so (figure 4). Work with your application development team.
• Individual fields should be validated the same way as form fields. Teams can convert entity level exceptions (that is, business rule dependencies) to attribute-level exceptions where possible.
• For entity-level exceptions converted to attribute-level exceptions, tell users which fields have the error by naming the fields in the message text (figure 5). The application team can decide which field to show the converted exception on.

Follow these guidelines for page navigation:

• Navigating between pages should validate all editable fields on the current page, as if a final save or submit action was committed, before users can navigate to another page. Where component validation is not possible, name the fields that have an error or warning in the message text.
• Do not allow navigation to continue until all errors have been fixed on the current page.
• Use warnings each time users change data on the page.
• If there is a risk of losing data when navigating or closing a page, then use the ApplCore and ADF page-level warning dialog box with a question and action buttons to enable users to understand the consequences and confirm their navigation intention. If you must use your own message, see the Save Model Guideline.
• For confirmation messages used when navigating between pages, show the message on the destination page, so that the navigation is not blocked. For more information, see the Create in a Form pattern.

Follow these guidelines for page navigation:

• Require users to complete all editable fields on the each page when current. There is no out-of-the-box "hidden messaging" support from ADF for messages on hidden editable fields or nonactive train stops or tabs.
• Enable users to perform submit actions only after editable fields are validated when the tab or train stop was current.
• If validation errors or warnings occur on a hidden page, place an icon on the tab (figure 6) or train (figure 7) to disclose the location.
• Use a page-level message to name the tab or train stop and fields with errors for any noncurrent tab or train stop. ADF provides a message for unsaved changes when navigating from a set of tabs. For more information, see the Save Model Guideline.

Follow these guidelines for composite components:

• For master-detail components, use an approach similar to that used with tabs. Validate each field as it is completed.
• If the master field is the cause of the validation failure, use the same approach used for editable fields (figure 8).
• If validation occurs on hidden details, place the icon before the master field and display validation messages on the editable fields when the master field is selected (figure 9).

Follow these guidelines with read-only components:

• Read-only validation of components is not supported. Instead, provide validation at a point in the task flow when users can correct editable fields.
• Put dependent fields on the same page if possible, rather than across pages, and validate them on the same page.
• When you cannot avoid dependencies across pages, use an in-field help note on editable fields to explain how the data will be used later, or use static instruction text explaining how to use the page or region, so that read-only situations can be anticipated later in the flow.
• Use a page-level information message to tell users when a page changes to a read-only status and why it does so, if it is not obvious.
• You can use status icons with tooltips to indicate errors, warnings, or information about read-only fields where appropriate. For more information, see the Fusion Icon Usage Guidelines. These are not considered messages.