FusionGPS: Standards and Guidelines: Save Model Guideline

Save Model Guidelines
Version 2.0.0.0


Contents

Overview
Save Actions
Save Model Buttons
Confirming Unsaved Changes
Task Stamps for Save Actions
Save Model Interactions and Button Combinations
Save Model for Pages, Tabs, and Subprocesses
Save Model Messaging and Other Visual Indicators
Implicit Save on Session Expiration
Related Information

Overview

The creation or editing of transactional data objects by users in Oracle Fusion Applications relies on what is known as a save model to commit data objects to the database or to store them in memory on the applications server. The save model is generally explicit, meaning that data objects are committed or stored in response to deliberate user actions; the data objects are not committed or stored automatically by the application in the background. Any implicit save actions are explained in the Save Model for Manage Pages: Delete Actions and the Implicit Save on Session Expiration.

Product teams must design and code the functionality for any save model interaction.

Use this guideline to:

Design save model interactions for different user scenarios such as creating or editing data objects directly or as part of a guided process, within a subprocess, on static or dynamic tabs, managed, or other pages
Understand what happens when users cancel, close, or navigate from pages, windows, or tabs that contain unsaved data
Know how the application responds to saved and unsaved data when an application times out or fails


Save Actions

Oracle Fusion Applications enables users to save data objects or to commit these data objects to the database using the Save and Submit buttons.

Save and Submit Actions Concepts

Both save and submit actions commit data to the database. Save actions also save data objects in memory on the application server within a user session until the data objects are later committed to the database. A save or a submit action is usually the final action that users take on a page or in a taskflow.

When users click a Submit button, they are usually taking the final action in a taskflow or process that releases the object of that process or taskflow publicly for further work or hands off the object as complete. After clicking a Submit button, users are navigated to the initial stage in the taskflow.

When users click a Save button, they are creating a data object for private use (although the data objects can be collaborated on by other users). The Save button does not provide any navigation. Navigation is provided by a Save and Close button or by another Save and <action> button (for example, a Save and Create Another button.

Including both a Save button and a Submit button on the same page indicates to users that data objects can be kept in some intermediate, incomplete, or draft state on the server before being finally completed and committed to the database. For example:

Users can create data objects that require the input of other users before the objects are considered complete. While that input is being collected, a user can save the object until it is ready to be finalized and submitted.
Users can revisit a data object or a process in different sessions before the overall task is complete and submitted (for example, when creating and publishing an order).

In these cases, a Save button indicates an intermediate state for the object and a Submit button (or variants of that label, for example a Publish button) indicates the final stage in the flow, when the object or process is complete and made public.

Additional attributes indicate the name of the person who last updated a saved object, the date that the object was last updated, and the status of the object (see figure 1).

Save creatiing a draft object. Indicate the draft status to other users.

Figure 1. Saving a newly created object to the server with a Save button. An intermediate status is indicated to users who have access. The object is finalized later using a Submit button.

Saving Objects and Page Context

When a data object is saved in draft status or a data object is made available to others, the page changes from a create context to an edit (or read-only) context. This change confirms the state of the saved object to all users in the taskflow. Examples of changing the context include:

Changing the page title and any object identifiers from Create <Object Type> to Edit <Object Type>, for example, creating an expense report changes the title from Create Expense Report to Edit Expense Report: IEW567789.
Changing editable fields on the page to read-only status. For example, if an appraisee creates a performance evaluation that is then shared with an appraiser for updating, any editable fields are made read-only.

For more information, see the Create and Information Entry Forms design patterns.

Save Actions and Access to Objects

Users can commit data objects to the database or save the data for personal review or review by others before the data is finalized. Two scenarios are generally encountered:

Users create data objects that have no shared access. Users click a Save button, which creates a draft version of the data object that only users can review and edit. The data object is saved on the server or committed to the database.
Users create data objects that are shared with others. Users click a Save button, which commits the data object to the database in draft status and enables other users to view and edit the data object.

In both of these scenarios, only one data object exists. The draft status of the data object should be communicated to all users, as the design requires, using indicators such as icons, listing the status in a table column, using a task stamp, and so on.

For more information, see Task Stamps for Save Actions and Save Model Messaging and Other Visual Indicators.

Creating Data Objects and Validation

Data entered on a page can be validated on the client side or the server side, depending on the business or user interface rules required. These rules are identified during the Application Process Model (APM) functional design phase. Product teams must design any data validation required.

Teams should be aware of the following limitations to validation and messaging in Oracle Fusion Applications version 1.0:

For validations to work (except for some simple Application Development Framework [ADF] client-side validators or converters that fire when data is first entered), users must explicitly perform save or navigation actions on the page. Navigating triggers any data to post on the page to the server, and as a result, errors or warnings may appear.
Users must complete all required fields on the page before they can leave the page either by a save or navigation action.
Users cannot navigate between dynamic tabs if there is a validation error in a component on a tab.
On pages that load with data objects, for example, when users create a new flow with tables, users must also complete required fields before saving or navigating from the page, even if they did not enter any data.

For more information concerning Cancel button actions, see Confirming Unsaved Changes.


Save Model Buttons

The following action buttons are used in the Oracle Fusion Applications save model when creating and editing data:

Save Buttons
Submit Buttons
Cancel Buttons

Place the Save, Submit, and Cancel buttons to the right of the action buttons, in that order. The name of the Submit button may also vary to reflect the final action in a taskflow.

The Save and Submit buttons sometimes appear as drop buttons that, when clicked, present a list of options that users can select from (such as Save and Create Another or Save As). The Rich Client User Experience button guideline refers to these buttons as drop buttons with other options as "split inline selector buttons."

For more information, see the Revert, Reset, and Undo Buttons and the Save Model Interactions and Button Combinations.

Save Buttons

A save action may or may not be the final action that a user takes on a page, and a page may include both a Save button and a Submit button (or renamed variant of this button). The Save button stores data objects in memory or commits data to the database, keeping users on the same page. The Save button itself provides no navigation.

Save Design Considerations

When a save action is the final action on a page or in a taskflow, then a Submit button is not required. A default Save button is not mandatory for all situations; other combinations or options are possible.

For more information, see the Save Model Situations and Button Combinations.

Use these guidelines for save buttons when these buttons are the final actions on a page:

Use a Save button as a final action for short transactional tasks when users have all the information on hand to complete a task in a single session.
Use a Save button as a final action when the data object creation is a small cognitive load for users.
Use a Save button as a final action when users are not required to complete a process in stages, or when they are not required to create an object across a number of steps.
Use a Save button as a final action on simple pages where only editing is required and there are no heavy components (hierarchical trees, master/detail objects, subtabs, subobjects, tables, and so on) on the page.
Use a Save button when users may not have all the information on hand to complete a task. A save action enables users to save data objects until they can revisit and complete the task.
Use a Save button to indicate that the status of a data object is in private, draft, incomplete, in progress, or in review by others until the data object can be finalized by clicking a Submit button.
Usea Save button when you want users to remain on the same page and not navigate elsewhere. When users click a Save button, a page-level task stamp appears under the drop button with the time that the data was saved on the server or committed to the database.

For more information, see Task Stamps for Save Actions.

Use a Save button as a drop button if other save options are required by the design (see figure 2).

Figure 2. Save drop button with options

For more information, see Save Options in Drop Button.

Follow these guidelines:

Use a Save and Close button as the final action button on a page if there is no Submit button or other final action that makes a data object public or that publishes the data object within a workflow.

A Save and Close button navigates users to the location where the flow was initiated.

Generally, make sure that when users click a Save and Close button to navigate that this action does not conflict with other navigation already available in the user interface and does not disrupt taskflow productivity.
If you require a Save and Close button and a Cancel button for a transaction, then present these buttons separately on the page. You must enable the Save and Close button.

If you require a Save button and a Save and Close button for a transaction, then present these buttons separately on the page (see figure 3).

Figure 3. Save and Save and Close buttons

The Save and Close button can also be the default button. Save and Close navigates user to where the flow was initiated. You can use a Save option in a Save and Close drop button (figure 4).

Figure 4. Save option in a Save and Close drop button

The Save and Create Another button can also be included as option in a drop button. For more information, see Save Options in a Drop Button.

When a save action is not he final action, then a Submit (or renamed variant) button is required. Use these guidelines for Submit buttons when they are the final actions and when they are used with Save button actions:

Use a Submit button to indicate to users that when they click this button, the data objects are made available to other users or the data objects are published within a workflow.
Use a Save button to imply that data objects are in draft, review, or incomplete status; use a Submit button to change the status and to finalize the data objects.
Use a Submit button to navigate users to the initial stage of the work flow, indicating completion of the current task.
Use a Save button on longer transactional tasks when users do not have all the information available to complete a process in a single session and they must revisit the task. Then, use a Submit button to finalize the process.
Use a Submit button as a final action on more complex pages where editing is required and where heavy components (such as hierarchical trees, master/detail objects, subtabs, subobjects, tables, and so on) are involved.
Use a Save button when the data objects being created or edited present a larger cognitive load, when there are additional actions required to create a data object, or when a process must be completed in stages, across a number of steps. Then, use a Submit button to finalize the object or data.

Teams can choose to design a confirmation message that indicates that a save action has been successful. Use error or warning messages for validations. In some cases, a warning message is acceptable on a final save action.For more information, see the Save Model Messaging and Other Visual Indicators guidelines.

Save Options in a Drop Button

When more than one save option applies to a transaction, use a drop button to present these various options. Do not include the name of the button in the list. Use the following guidelines:When a Submit button is the final action on a page, present the save options in the following order (see figure 5):

Save (default)
Save and Close
Save and Create Another (if required)
Save As… (if required)

Figure 5. Save drop button options when clicking Submit is the final action

When clicking a Submit button is not the final action, the order of the save options is as follows.For small objects and short transactions, the order of the save options is as follows (see figure 6):

Save and Close (default)
Save and Create Another (if required)
Save As… (if required)

Figure 6. Save options for small objects and short transactions, when clicking the Submit button is not the final action

For large objects and longer transactions, use a separate Save button, and place the options below the Save and Close drop button in the following order (see figure 7):

Save and Close (default)
Save and Create Another (if required)
Save As… (if required)

Figure 7. Save options for large objects and long transactions, when clicking the Submit button is not the final action

Save As… Button Option

Include the Save As… button in the Save drop button options only on existing objects. The Save As… button enables users to create a duplicate version of an object with a different name. Use these guidelines:

Include a Save As… option only when the option is a functional requirement. In most cases, the preferred way of duplicating is by clicking the Duplicate icon on table rows.

For more information, see the Create a Duplicate Design Pattern.

Include a Save As option in contexts where there is a considerable amount of information that users want to reuse in the data object that they are editing, or if the design has determined that the Save As functionality will be used often.
If users have performed an intermediate save action on the data object, and the object already exists, then the object should be available for duplication, if the design requires.
Include a Save As option only where users have permission to create new data objects or different versions of the data object (in some cases, objects may support only one instance and version).
Any required validations should be performed on the original object before the object is duplicated and saved, as the design requires.
Using Save As to create a new object this way places users in Edit mode for the new object (see figure 8).

Save As... creates a new object in an edit context.

Figure 8. Using the Save As... button to duplicate an object A and remain in edit mode on the new object B. User gives the new object B a new name in the Save As... dialog box.

After selecting the Save As… option, users must be provided with a dialog that enables them to save their object with a new name in a location to which they have access permissions (see figure 8).

Submit Buttons

A Submit button is the final action performed in a taskflow. You can rename this button to reflect the final stage of the task. Follow the button label guidelines when naming the submit action in the button. For more information, see the Rich Client User Experience Buttons Usage Guideline. Clicking the Submit button means:

All validations are performed, and a final version of the data object is committed to the database.
A data object or process is made public, published, or advanced through any workflow.
Users are automatically navigated to the place where the flow was initiated, or if users are in a secondary window and the submission is successful, that secondary window closes.

If teams want to provide multiple submit options, they can use a Submit drop button. Follow these guidelines:

The Submit option remains the default action in the drop button.
If other options are required, label them explicitly, for example: Submit and Create Another.
Avoid Submit button options that use a trailing ellipsis. The use of an ellipsis adds an additional step in the form of a dialog box, extending the taskflow and lowering productivity for a task that is being finalized.

Teams can choose to design a confirmation message that indicates that a submit action was successful. Use errors and warnings when validations fail. In some cases, a warning message is acceptable on a final submit action.For more information, see Save Model Messaging and Other Visual Indicators.

Cancel Buttons

A Cancel button must be used on all transactional pages where data can be created or edited. The Cancel button is always the last page-level action button, and it is right aligned. Do not use a Cancel button on read-only pages. Instead, use a Done button.For more information, see the Page Actions Guideline.Clicking the Cancel button means:

Users discard any data entered on the page in any editing or creating process.
Users discard all changes since the last save in any editing or creating process.
Any secondary window or dynamic tabs that were opened by users are closed.
Users are navigated to where the flow was initiated.

Note: This navigation does not apply to static tabs because users do not navigate to the tabs using actions (see figure 9).

Figure 9. Static tab with Save and Cancel buttons. On these tabs, Cancel buttons do not provide any navigation.

In the case of a static tab, clicking the Cancel button should restore the data on the page to its last-saved state, of if a subflow had been called. The use should be taken back to he parent flow. Important: For Oracle Fusion Applications 1.0, on Apps-UX direction, when users click a Cancel button they should not be warned by a native ApplCore or team-designed warning message about any unsaved data objects being lost. For example, on a create page there may not be much information entered, and therefore lost, so it is preferable not to prompt users with a series of validation messages and then the unsaved warning dialog box. Users should not also be warned about unsaved changes on read-only pages, for example about search results or LOV choices being lost. For more information, see Confirming Unsaved Changes. Revert, Reset, and Undo Buttons buttons are not supported in Oracle Fusion Applications 1.0. Reset buttons are supported as the method for users to set back all editable fields and choices on the page to their default states without having to individually revise each one. A Reset button is recommended for basic or complex form pages and dialog boxes, but they are discouraged for smaller, dialog box-based forms.For more information, see the Page Actions Guideline.


Confirming Unsaved Changes

This section explains how to warn users about unsaved data if they close, cancel, or navigate away from a page or tab.

When a Page or Tab Is Closed, Navigated Away From, or a Taskflow Is Refreshed

When users close or navigate from a tab or page with unsaved changes, a modal dialog box warning message asks users if they want to continue to leave. Yes and No buttons ask users to confirm the action that they want to take.

Note: These warning message dialog boxes cannot display a Save button for technical reasons.

For nontab work areas, ApplCore shows the following message (see figure 10):

Figure 10. Modal warning message for a page.

For a single tab work area, ApplCore shows the following message (see figure 11):

Figure 11. Modal warning message for a tab.

For multiple tabs, ADF shows the following message (see figure 12):

Figure 12. Modal warning message for multiple tabs

Here are the known issues with closing and navigating from pages or tabs in Oracle Fusion Applications 1.0:

If there is unsaved data on the page, close or navigation actions cause validations to fire as data is posted to the server. This means that users must fix all client-side and server-side validations before the warning message dialog box appears and can be responded to.
If users create a new flow that requires data objects to load (for example in tables), and users then navigate or close the new flow without having made any other changes, then users may see a modal warning message dialog box (see figure 13).

Figure 13. Warning message that appears when closing a new flow

If users navigate from a subflow, and there is unsaved data in the main flow, users are not warned about possible loss of the unsaved data in the main flow.

Designing Warning Message Dialogs for Unsaved Changes

Warning messages for unsaved changes are provided natively by ApplCore, and in some cases, by ADF. Product teams should use the natively-provided warning message modal dialogs. In cases where a team can control their own data APIs and cannot use the natively-provided warning message about unsaved changes, teams must provide their own message (for example, within subflows as shown in figure 11).

Follow these guidelines:

Use the same text as the ApplCore message, including the question part.
Show the message in a modal warning message dialog box with Yes and No action buttons.
Do not include an iconic close button in the dialog box.
Do not add an incident or support number to the text.

Direct Navigation Using the Web Browser Back Button or a New URL

If users navigate from a tab or page using the web browser's Back button or by entering a new URL, ADF can be configured using the af:document tag's UncommitedDataWarning attribute to display a page-level warning message from the browser (see figure 14).

Figure 14. Browser Back button warning message

Note: The web browser controls this message, not the application, so the name and order of confirmation buttons is different from the application's warning message dialogs.

For more information on the user experience of clicking a Cancel button, see Cancel Buttons.

Task Stamps for Save Actions

A date and time page-level task stamp informs users when they last saved a data object. The date and time that appears indicates when data was last saved on the server (see figure 15).

Figure 15. Task stamp showing last saved information to users

When using task stamps for save actions, follow these guidelines:

Show the stamp only after a save action has been performed.
Save and close operations that are part of a subprocess that saves data on the server and that appear in secondary windows do not use the task stamp. Instead, the task stamp appears at the master process level when the data is saved.
A stamp is not used on the same object viewed from a different flow.
Show the stamp under the page-level action buttons, right-aligned.

For more information, see the Page Region Header Guideline.

Follow this format:

Last Saved DD-Mon-YYYY Hour:Minute:Seconds AM or PM

For example: Last Saved 22-Oct-2009 10:15:22 AM

There is no colon after the Last Saved legend.

Date and time format should automatically reflect the local preferences of users.

For more information, see the Common Formats Usage Guideline .

On editable search pages a new search clears the stamp since it is no longer relevant.
The time stamp is read-only. No null Last Saved legend appears when the page loads.

For more information, see the Page Stamps Usage Guideline .


Save Model Interactions and Button Combinations

This section provides design guidelines for different circumstances that use a save model, outlining which Save and Submit button combinations are appropriate in each case.

The order of buttons used in the save model is Actions, Save, Submit, and Cancel. In general, here are the rules for choosing between save model button options (see figure 16). When there is no submit-type final action:

The Save button is optional.
Always show the Save and Close button.
Group any other Save and <action> options (for example, Save and Create Another) under a Save and Close drop button.

When there is a submit-type final action:

The Save button is optional.
Group any Save and <action> options under a Save drop button, starting with the Save and Close option. If you have Submit and <action> options, then you must have a Save drop button.
Always show the Submit button (or a renamed variant) that completes the flow.
Group any Submit and <action> options under a Submit drop button.

Figure 16. Save model drop button combinations

The following sections provide additional details on specific use cases and the combinations of Save and Submit buttons to use when:

Creating a Small Object or Small Process
Creating a Large Object or Large Process
Creating an Object as Part of a Guided Process
Editing a Small Object or Small Process
Editing a Large Object or Large Process
Editing an Object as Part of a Guided Process

Creating a Small Object or Small Process

Usage description:

Requires users to enter information on one page or less
Does not use heavy components (hierarchical trees, master/detail objects, subtabs, subobjects, tables) on the page or window
Imposes a small cognitive load for users to create the object or process
Does not require users to create the object or process in different sessions (there is no concept of a draft object or process)
Provides users with all the information they need to create the object or process in a single session

If Submit is the final action, here are the button functions (see figure 17):

Submit: Commits data objects to the database and navigates users to where the flow was initiated. Requires that all validation be complete. Any workflow, handoff, or making this object public is implied.
Cancel: Discards any unsaved data objects and navigates users to where the flow was initiated.

Figure 17. Submit as the final action

If Save is the final action, here are the button functions (see figure 18):

Save and Close: Commits data objects to the database (this is the only final action available) and navigates users to the place where the flow was initiated. Optionally, you can place the Save and Create Another and Save As actions under the Save and Close drop button.
Cancel: Discards any unsaved data objects. The user is navigated to where the flow was initiated.

Figure 18. Save is the final action

Creating a Large Object or Large Process

Usage description:

Requires users to enter information on only one page
Uses heavy components (hierarchical trees, master/detail objects, subtabs, subobjects, tables, and so on) on the page
Imposes a larger cognitive load for users to create the object or process
Requires that users to create objects or processes in phases, across multiple sessions, necessitating a draft status for objects and processes
Does not always provide all the information necessary for users to complete the data object or process in a single session

If Submit is the final action, here are the button functions (see figure 19):

Save: Saves the data objects in draft format and keeps users on the page. Any validation necessary is left to product team requirements. A task stamp is added to the page.
(Optional) Save As: This option is available after users perform an intermediate save on the data object, if the object already exists in the database and is available for duplication.

Save As… initiates a secondary window where users must name the new data object. Users are taken into the new object in edit mode, and any changes to the original object are not saved.

Submit: Commits data objects to the database and navigates users to where the flow was initiated. All validation is completed. Any workflow, handoff, or making this object public is performed.
Cancel: Discards any unsaved data objects and navigates users to where the flow was initiated.

Figure 19. Submit is the final action

If Save is the final action, here are the button functions (see figure 20):

Save: Commits data objects to the database and keeps users on the same page. Any validation necessary is left to product team requirements. A task stamp is added the page.
Save and Close: Commits data objects to the database and navigates users to the place where the flow was initiated.
Save and Close may be the default save action, with (optionally) Save and Create Another and Save As actions placed under a Save and Close drop button.
Save As (optional): This option may be available after users perform an intermediate save on the data object if the object already exists in the database and is available for duplication.

Save As opens a secondary window where users must name the new data object. Users are taken into the new data object in Edit mode, and any changes to the original data object are not saved.

Cancel: Discards any unsaved data objects and navigate users to where the flow was initiated.

Figure 20. Save is the final action

Creating an Object as Part of a Guided Process

Usage description:

Requires users to complete several pages of information
Uses heavy components (hierarchical trees, master/detail objects, subtabs, subobjects, tables, and so on) on the page
Imposes a larger cognitive load on users
Requires that users create the data object or process in phases
Does not always provide all the information that users need to complete the object or process in a single session

For guided processes, here are the button functions (see figure 21):

Back: Navigates users to the previous step. This may prompt users to save any unsaved data before navigating to the previous step.
Next: Navigates users to the next step. This may prompt users to save any unsaved data before moving on to the next step.
Save: Saves the data object in a draft status. This keeps users on the same page. Any validation is left to the product team requirements. A task stamp is added to the page.
Save and Close: Saves the data object in draft status. The user is navigated to where the flow was initiated.
(Optional)Save As: Available after users perform an intermediate save on the object, thus committing the object to the database and making the object available for duplication.

Save As initiates a secondary window where users must rename the duplicate object for it to be saved. Users are taken into the new object in Edit mode. Any changes to the original object are not saved.
Submit: Commits data to the database and navigates users to where the flow was initiated. All validation is completed. Any workflow, handoff, or making the object public is performed.
Cancel: Discards any unsaved data objects and navigates users to where the flow was initiated.

Figure 21. Guided process

For more information, see the Guided Processes Pattern Group.

Editing a Small Object or Small Process

Usage description:

Requires users to complete information on one page or less
Does not use heavy components (hierarchical trees, master/detail objects, subtabs, subobjects, tables, and so on) on the page
Imposes a small cognitive load on users who do not need to create these data objects in different phases
Provides all the information necessary to create the data object in a single session

If Submit is the final action, here are the button functions (see figure 22):

Submit: Commits data to the database and navigates users to where the flow was initiated. All validation is completed. Any workflow, handoff, or making this object public is performed.
Cancel: Discards any unsaved data objects and navigates users to where the flow was initiated.

Figure 22. Submit is the final action

If Save is the final action, here are the button functions (see figure 23):

Save and Close: Commits data objects to the database and navigates users to where the flow was initiated. Optionally, Save and Create Another and Save As may be placed under the Save and Close drop button.
Cancel: Discards any unsaved data objects and navigates users to where the flow was initiated.

Figure 23. Save is the final action

Editing a Large Object or Large Process

Usage description:

Requires that users complete information on only one page
Uses heavy components (hierarchical trees, master/detail objects, subtabs, subobjects, tables, and so on) on the page
Imposes a large cognitive load on users
Enables users to edit the data object in phases, across multiple sessions
Enables users to work with many others to create this object, at different times

If Submit is the final action, here are the button functions (see figure 24):

Save: Saves the data object in draft status and keeps users on the same page. A task stamp is added to the page.
Save and Close: Saves the data object in draft status and navigates users to the location where the flow was initiated.
Save As: Initiates a secondary window where users must rename the duplicate data object to be saved. Users are taken into the new data object in edit mode. Any changes to the original data object are not saved.
Submit: Commits the data object to the database and navigates user to where the flow was initiated. All validation is completed. Any workflow, handoff, or making this object public is implied.
Cancel: Discards any unsaved data objects and navigates users to where the flow was initiated.

Figure 24. Example of Submit is the final action

If Save is the final action, here are the button functions (see figure 25):

Save: Commits data to the database and keeps users on the page. A task stamp is added to the page.
Save and Close Commits data to the database and navigates users to the location where the flow was initiated.
Optionally, you can place Save and Create Another and Save As under the Save and Close drop button.
Save As: Initiates a secondary window where users must rename the duplicate data object to be saved. Users are taken to the new data object in Edit mode. Any changes to the original data object are not saved.
Cancel: Discards any unsaved data objects and navigates users to the location where the flow was initiated.

Figure 25. Save is the final action

Editing an Object as Part of a Guided Process

Usage description:

Requires that users complete several pages of information
Uses heavy components (subtabs, master/detail, tables, subobjects, and so on) on the page
Imposes a large cognitive load on users
Enables users to edit the object in phases, across multiple sessions
Does not always provide all the information that users need to complete the object or process in a single session

For editing an object as part of a guided process, here are the button functions (Figure 26):

Back: Navigates users to the previous step. This may prompt users to save any unsaved data before navigating to the previous step.
Next: Navigates user to the next step. This may prompt users to save any unsaved data before moving on to the next step.
Save: Saves data objects in draft status. Users remain on the same page. A task stamp is added to the page.
Save and Close: Saves data objects in a draft status. The user is navigated to where the flow was initiated.
Save As: Initiates a secondary window where users must rename the duplicate data object to be saved. Users are taken into the new data object in Edit mode. Any changes to the original data object are not saved.
Submit: Commits data objects to the database and navigates users to where the flow was initiated. All validation is completed. Any workflow, handoff, or making this object public is implied.
Cancel: Discards any unsaved data objects. The user is navigated to where the flow was initiated.

Figure 26. Editing an object as part of a guided process

For more information, see the Guided Processes Pattern Group.

Considerations for Editing and Creating Objects in a Guided Process

The final action in a guided process uses the Submit button if there is a workflow or handoff involved with the object being created or edited. Product teams can apply a more specific label when necessary for final submit-type actions using the standard process for creating and approving button labels.
The final action button may be available on every step of a train when appropriate. The button location does not change.
Product teams must determine the validation necessary between steps. In some cases, validation can be done at the completion of the process. However, validation requires that teams do additional work on messaging.
In other cases, validation can be done on each step or at the field level, taking advantage of the default ADF messaging and validation framework.

For more information, see Save Model Messaging and Other Visual Indicators.

See also the Guided Processes Pattern Group.


Save Model for Pages, Tabs, and Subprocesses

This section explains save model interactions for different design scenarios.

Save Model for Dynamic Tabs

Dynamic tabs use an explicit save model (see figure 27).

Figure 27. Dynamic tab work area

Users must be warned about unsaved data when they close a tab in the local work area using the Close icon or navigate to another tab. In Oracle Fusion Applications version 1.0, a modal dialog box warning message appears.

In Oracle Fusion Applications version 1.0, canceling a tab with unsaved changes should not cause a warning message to appear.

For more information, see Cancel Buttons and Confirming Unsaved Changes.

See also the Dynamic Tabs Work Area Guideline.

Save Model for Manage Pages: Delete Actions

Delete actions are governed by the underlying save model of the page. On read-only pages, a delete action is immediate and uses an implicit save, but on editable pages, a delete action requires an explicit save. In the case of manage pages, be aware of these two scenarios:

If a manage page is editable, any edits made require users to explicitly save the changes. Any delete action requires an explicit save like any other changes on the page.
If a manage page is not editable, users perform create and edit actions on detail pages or dialog boxes and save changes explicitly. Any delete actions on the manage page require an implicit page-level save.

You should not use mixed save models for actions on the same page. That is, don't include some changes that are saved implicitly as part of the action and other changes that require an explicit save.

Save Model for Subprocesses

This section addresses the save model for a subprocess (a process within a larger process). For example, when users start a process to create an order, they may realize during the order creation process that they need to create customer details. In these cases, users can launch a secondary window or drill-down page to create the customer details.

Here are two types of save situations in subprocesses:

Cached subprocess: The subprocess is a direct result of the main process from which the subprocess is invoked. Any data or object created by this subprocess is stored (or cached) on the server until the main process is completed. When the main process is completed using a Submit button, both the subprocess and main process data is is committed and final object is created.

Use Submit or OK buttons at the end of the subprocess. In the cached subprocess, data validation occurs twice: first, when users click the Submit or OK buttons, and second, when the data is finally committed to the database. If users cancel the main process, any association between the main process and subprocess is canceled as well.

Saved subprocess: Any data or object created is saved and committed to the database. In other words, any subprocess data or object created can live outside of an association with a main process. So the subprocess data and object are saved even if the main process is canceled before finalization. In the saved subprocess, validation occurs only once when users click the Submit or Save and Close buttons.

Issues of dependency between process and subprocess in terms data object submission are not apparent to users. For the final action button guidance for subprocesses of these two types, follow these guidelines:

For Cached Subprocesses Dependant on the Main Process

For Saved Subprocesses Not Dependant on the Main Process

For train subprocesses (see figure 28):

Use the Submit and Cancel buttons.

Figure 28. Train subprocess

The main process also uses a Submit action to finalize the process. Do not use OK or Continue buttons in train subprocesses.

Product teams requiring a train subprocess should follow the Subprocess Pattern.

For train subprocesses (see figure 32):

Use the Submit and Cancel buttons.

Figure 32. Train subprocess (saved)

For cases when the object is collaborated on and then made public, see "Save Model Situations and Button Combinations" for recommended button layouts.

Product teams requiring a train subprocess should follow the Subprocess Pattern.

For dialog box subprocesses (see figure 29):

Use the OK and Cancel buttons for single-page dialog boxes.

Figure 29. Single-page dialog box

Use the OK and Cancel buttons when the updates in the dialog box can be done iteratively (see figure 30).

Figure 30. Iterative updates in a dialog box (cached)

For dialog box subprocesses (see figure 33):

Use the Save and Close and Cancel buttons if the intent is to keep the object private and not to share the object with other users.

Figure 33. Dialog box subprocess (saved)

For more information about cases when the object is collaborated on and then made public, see the Save Model Situations and Button Combinations for recommended button layouts.

For page drill-down details (see figure 31):

Use the OK and Cancel buttons.

Figure 31. Page drill-down details (cached)

For page drill-down details (see figure 34):

Use the Save and Close and Cancel buttons if the intent is to keep the object private and to not share the object with other users.

Figure 34. Page drill-down details (saved)

For more information about cases when the object is collaborated on and then made public, see the Save Model Situations and Button Combinations for recommended button layouts.


Save Model Messaging and Other Visual Indicators

Product teams design confirmation, error, or warning messages as required for save model interactions. These messages are designed according to the APM functional design phase business or user interface rules for the taskflow.

Messages can appear in dialog boxes or inline (that is, on the page):

Dialog box-based messages are more noticeable and can also be modal, forcing users to confirm their actions before interacting with the base page again.
Dialog box-based messages are ideal for critical error messages or for warnings that ask a question about possible loss of data.
Inline errors or warnings are ideal for validation errors on relatively frequently performed tasks. You cannot use inline messages to ask a question as part of a warning message.
Inline messages are less disruptive and are ideal for confirmation messages after a final save or submit action.

Follow these guidelines for messages relating to the save interaction:

Use confirmation messages to tell users that their data has been finally saved or submitted as they intended, especially when no visual indication of a successful action is available.

These messages are important to users in the enterprise applications space, as data has a high value, and there may be some processing time required to submit data successfully because of performance connectivity issues. Research indicates that users prefer more rather than less confirmations.

Use error messages to tell users of validation problems when data is saved, depending on the designs of the business rule validation, or if the save or submit action has failed. Tell users how to correct the error.

Use warning messages to tell users when they are saving or submitting data objects that may have downstream implications if the action is final or requires correction later in the taskflow.

Use modal dialog box warning messages when users navigate from a page or dynamic tab, warning them that if they proceed any unsaved data will be lost. In some cases, ApplCore or ADF provides these messages natively, but in other cases, you must design and implement these messages according to the user interface rules of your taskflow.

For more information, see Designing Warning Message Dialogs for Unsaved Changes.

Messages cannot be turned off after first use by a user preference or dialog box-level check box in Oracle Fusion Applications version 1.0.

If any server-side errors or warnings exist in an object saved for later used or for editing by others, then use icons, status column indicators, or other indicators (as the design requires) to indicate to other users that the objects are in that state.

For more information, see the Message Pattern Set and Icons and Term Definition Guideline.

For Oracle Fusion Applications version 1.0, the default ADF validation framework supports messaging on editable fields on currently visible pages only. Other situations, such as hidden pages, objects, noncurrent tabs or train stops, or read-only pages, are not supported by default. If messaging is required for these situations, the product teams must design these messages.

For more information, see the Message Usage Guideline.

Implicit Save on Session Expiration

ADF View Controller provides taskflow-based savepoints that you can use to save data implicitly in the event of an applications session time out or failure. This requires developers to set the Enable Implicit Savepoints option in the Controller section of adf-config.xml and to set the Critical option of each taskflow behavior to True.

There is no central guidance to development teams in Oracle Fusion Applications version 1.0 about which taskflows should be marked as critical. Fusion Applications uses a page-model, so critical implicit saves, if used widely, require significant customer disk space to save data and page elements in the event of widespread implicit saves. Savepoints cannot be associated with named levels in the business process model.

In Oracle Fusion Applications version 1.0, users are warned about an expiration two minutes in advance, using a modal message dialog box (see figure 35).

Figure 35. Expiration warning

If no response is received to the warning, then the application times out, and any unsaved data is lost. A modal message dialog box asks users to click OK to continue (see figure 36).

Figure 36. Expired message

Clicking OK takes users to the application sign in page. After sign in, users are taken to the application overview page.

Tabs are not restored, and any URLs used by the application are not saved for later reload by users. Guidance on a restore UI has not been provided to product teams in Oracle Applications Fusion version 1.0.