Overview
This standard describes the UI guidelines for Related Actions in Fluid based applications. The guidelines cover their usage on tablets, smartphones, laptops, and desktops.
Access to Related Actions
To access Related Actions, tap the Related Actions icon, which is available only when a related action is configured from the current transaction.
The following examples show how users can access Related Actions from various locations in fluid mode.
Accessing Related Action from Application Header
The Related Action icon appears next to the Employee name:
Accessing Related Action in a Grid
In this example, the Employee Photo is a column in the grid, and the Related Action icon appears next to the employee name:
You may want related actions to have a column in a grid, as shown in this example:
Accessing Related Actions from a Card View
In a card view, the Related Action icon appears near the right edge of the card header:
Accessing Related Actions from the NavBar
When using the second level of the NavBar, you can provide access to related actions as shown here:
If the row on the second level is tappable, it is recommended that you not use related actions to avoid mistapping. In the previous example, related action access is provided on the second level because the row is not tappable. For performance reasons, the related actions list is loaded only after the user taps the Related Actions icon.
Do not use related actions on the first level of the NavBar.
Accessing Related Actions from Search Results
You can configure related actions to appear with the Search results, as shown in this example:
Accessing Related Actions from Company Directory
In the Company Directory/Org Chart, the Related Action icon appears in the selected node next to the name (only if you are authorized to take configured related actions):
Accessing Bulk Related Actions
In a grid, you can configure related actions to be applied to multiple rows. The following example shows bulk related actions in a grid:
Tapping a Related Action
You initiate a related action by tapping it after accessing the list of related actions through the Related Action icon.
In most cases, a related action transfers the user to the respective transaction component to perform the action. In some cases, the related action opens in a modal window or it can run in the background.
In the following example, when the user taps the Performance related action from the Personal Details fluid page, the user is transferred to the Performance component
In this example, when the user taps the Notify Resource related action, it opens in a modal window:
Use a modal window for related action when it is important to keep the user in the current transaction once the related action is complete or when the current transaction provides required context to complete the related action.
Note: When the related action that opens a modal window is tapped from the NavBar, the NavBar should automatically be dismissed.
Responsive Design
Related actions automatically render in the various form factors. The following examples show what two of the previous examples look like in a small form factor (smartphone).
Mapping Between Fluid Transaction and Classic PIA Transaction
Until all the PIA transactions are converted to corresponding Fluid transactions, you need to evaluate whether the Related Action from a transaction needs to take the user to the respective PIA transaction or the Fluid transaction.
Enabling Conditional Navigation
The following documentation details how Conditional Navigation works and how PIA/ Fluid component mapping is done. Each Fluid transaction must be reviewed to determine whether mapping between the Fluid transaction and the Classic PIA transaction is needed.
When Fluid transactions and Classic PIA transactions are mapped properly, users will navigate from one fluid component to another fluid component and have a consistent user experience with the same look and feel. Ideally, users will not see a mix of Fluid and Classic PIA transactions as they navigate the PeopleSoft system.
The guidelines for enabling Conditional Navigation mapping are as follows:
- As a general guideline, if a Fluid transaction coexists with a respective PIA transaction (it may have only partially or completely replaced the PIA transaction), then the Related Action and menu navigation should take the user to the Fluid transaction. Note: As an exception, you may want to transfer users to a Fluid transaction when they select the related action/menu item from a Fluid transaction and to the respective PIA transaction when they select the related action/menu item from a PIA transaction. Evaluate these scenarios according to your requirements. If you want to give users access to both Fluid and PIA (Classic) components, do not implement Conditional Navigation because it will always take users to the fluid component and they will be forced to add a new CREF at their end to provide access to the PIA (Classic) component. Note: PeopleTools allows you to add PeopleCode to ignore Conditional Navigation and to take users to respective PIA (Classic) components.
- If a number of PIA transactions are replaced with a single Fluid transaction, then set up the Conditional Navigation such that only one related action and menu-label appears to take users to the respective Fluid transaction.
The examples that follow display the Personal Details Fluid transaction (related action and menu label) that replaces these Classic PIA transactions:
- Personal Information Summary
- Home and Mailing Addresses
- Phone Numbers
- Email Addresses
- Instant Message IDs
- Emergency Contacts
- Name Change
- Marital Status
- Ethnic Groups
Note: The Conditional Navigation for Menu and Related Actions should be in sync, that is, it should use the same labels and access for the items in both the menu and in related actions.
Examples:
Enabling Related Actions
In general, when you are in a process (for example, Guided Self Service and Approvals), do not allow Related Actions so that the main transaction is not abandoned halfway through.
However, if you have Save for Later functionality in a process and you are not required to complete the process in the same session, then you may allow Related Actions.
For any new Fluid transactions and existing PIA transactions converted to Fluid, you must evaluate:
- Whether Related Actions from the transaction should be enabled.
- Whether a Related Action to this transaction should be enabled in other transactions.
Using Buttons Versus Using Related Actions
Use a button for an action that is intrinsic or a primary action for the transaction. The primary actions should be prominently displayed so that they are highly visible and accessible to users. If such actions are listed under the Related Actions icon, users will have trouble locating them, which will not be a good user experience.
In the following example, buttons are used for the primary actions Approve, Deny, and Pushback so that these are readily available for user to take required action:
Related actions are not primary to the transactions, but users may want to access their functionality from within a given transaction. For example, while checking Benefits, a self-service user may also find it useful to access their last month’s paycheck to ensure that they were paid correctly. In this case, using a Related Action enables the user to navigate quickly to the Paycheck component, which is not the primary task on the Benefits component. Related Actions provide quick access to a functionally useful action that is related to the primary action.