Last Update: Mar 22, 2024

Platform: Web, Mobile, others (see section "Making Quick Actions available outside the SF Suite")

Designer: Paul Hopkins

Intro

A Quick Action is a lightweight function with just a few pieces of data that are needed to give the user the ability to perform a task quickly and with as little fuss as possible, without the need to go to the larger application.

Quick Actions can be either informational or transactional. The following will refer to "view" and "edit" Quick Actions.

Form-based Quick Action (left 2 pictures) &

List-based Quick Action (on the right)

Scope

This guideline applies to all Quick Actions in the SuccessFactors product, for all modules.

Usage

A Quick Action should be used to enable the user to complete a task quickly and with as little fuss as possible, without having to navigate to a full-page transaction.

The task can involve either looking up information (“view”) or changing information (“edit” - this term includes adding entries and deleting entries).

Examples of Quick Actions (see section “Application-specific examples” for screenshots of these):

• Delegate Workflows
• Recognize a Person
• Request Feedback
• Change Pronouns
• View Emergency Contacts
• Add Phone Number

(The first 3, and all other true Quick Actions on the Homepage that are not from EC, do not conform 100% to these guidelines (but they are pretty close 😊), so we will need to do some continuous improvement to improve consistency).

As the Quick Action pattern has at its heart a Fiori dialog, the “usage” guidelines from the Dialog also apply.

When to use the Quick Action Pattern

• It’s a simple and recurring task that users should be able to complete quickly without navigating away from the dialog in which the task is presented
• Users come to this quick action with a primary purpose in mind , they execute it and then exit
• It represents 80% of the use cases. It's a use case that the majority of the users in your product area do.

When not to use the pattern

• You want to create quick access to a module's functions
• The task requires a lot of time and a lot of thinking

Types

Form-based Quick Action: page 1 (left) and page 2 (right)

List-based Quick Action: page 1 (left: a list) and page 2 (right: a form)

There are 2 basic types of Quick Action:

• Form-based

  • A simple, single-column form with a small number of input fields. The input fields are typically a subset of all the fields in a single HRIS element. In the case of the EC Quick Actions, the input fields to be shown / used are determined by customer configuration. That is: a Quick Action “Change Location” for customer A can look different to the same for customer B.
  • Optionally, page 2 of the dialog can be used for further steps relevant to processing (typical example for EC: triggering a workflow)

• List-based

  • A simple list of entries of the same type that are related to an object. Examples: all phone numbers of a person, all job relationships of that person.
  • In most cases, the list entries enable the user to navigate to a detailed view. This detailed view may enable the user to change or delete the selected entry. The detailed view is therefore nothing more than a form-based Quick Action, which is presented on page 2 of the list view.

Structure & Components

A Quick Action is realized by means of the Fiori Dialog component, with SF-specific overrides documented in the appropriate guidelines.

For single object view and edit Quick Actions, the dialog contains a Form.

In the case of multiple entries (for example a list of phone numbers associated with a person), the dialog contains a List.

Use can and should be made of “page 2” of the Fiori dialog. For example: page 1 shows a list of objects, page 2 shows the details of one of those objects. Or: page 1 shows details of an object and allows the user to make changes, page 2 shows the details of a workflow associated with the object, allowing the user to trigger the workflow. These variants are described and illustrated further in the “Behavior and Interaction” section.

Dialog

A standard width of 512px is recommended for Quick Action dialogs, in keeping with the SF Dialog guidelines.

Fields on the form should have their width adjusted to an appropriate width, depending on the content of the field. For example: do not use an input box spanning the whole width of the dialog for a field containing Yes or No :-)

When the Quick Action refers to a person other than the logged-on user (for example in the case of an MSS process), it is good practice to use the SF User Preview component at the top of the dialog to show details of the target user (the employee whose data is being changed).

Here is an example:

Note that here we hide the “Quick Card” icon, for 2 reasons: (1) firstly, we want the user to focus on the task at hand. Offering routes to other information can be distracting. (2) the Quick Card would lead to a “dialog over dialog” situation, which we absolutely want to avoid.

The “name” element of the User Preview component is, however, shown as a link to the person’s full profile.

Forms

The form elements used must conform to the SF Form guidelines: single column layout, field widths (for example a fixed width of 136px for Date Picker fields), 10px padding between form fields, use of information value state when values are changed etc.

Behavior & Interaction

Access

There are many places from within the SuccessFactors Suite where Quick Actions can be accessed. These include:

• as a homepage tile
• from within a menu in a homepage tile (Manage My Team, Manage My Data)
• from the context menu of a card in an application (Manage My Positions --> card-based overview, with every card offering access to appropriate Quick Actions)
• from the Quick Card

See the next section for screenshots of these.

Typically, a Quick Action is accessed from a UI element that triggers an action. In most cases, this is a button or an item in a list.

Many Quick Actions, particularly in EC, are also available outside the SF Suite, in SAP Start, SAP WorkZone, MS Teams and Joule. As described in a later section, the look and feel of the Quick Actions there is sometimes very different, but the good news is that all “clones” of the Quick Actions make use of the same APIs, which also helps to ensure consistency of the experience.

Accessing Quick Actions

Making Quick Actions available outside the SF Suite

Quick Actions can be made available on multiple channels such as the following: SAP WorkZone, SAP Start, Joule, MS Teams.

The look and feel of the Quick Actions on platforms outside the SF Suite are of course influenced by the Design Systems of those other channels. For example: button order is different in Microsoft (Teams); only SAP uses the 72 font. Consider that it may not make sense to make a person’s name clickable in an SF Quick Action in Teams: the user may be using this Quick Action in an environment in which the SF instance is not available.

Your role as Designer in such cases is less to worry about the pixels, and more to consider the flow and interaction.

Interaction

The change cannot be saved immediately, it needs to be approved first. So page 2 of the dialog is used to inform the user of the need to trigger a workflow and add a comment for the approvers. “Submit” then submits the change for approval. A message toast should be used to provide feedback to the user that the request has been submitted.

So that is the basic flow of a Quick Action, shown here in “view” and “edit” variants.

Sometimes more than 1 entry is associated with a person, though. For example: multiple emergency contacts, multiple phone numbers.

In such cases, the dialog is first used to show the user all of the existing records, in the form of a list:

Selecting an entry in the list leads to a details page (Fiori Form!) where the details are shown and (in the case of “edit” Quick Actions) can be changed:

The “Back” icon button in the dialog title shows that this is page 2 of the dialog.

On this detailed view, the user can typically change data (then Save the changes), or Delete the record. In the “Change Email Addresses” shown previously, clicking the “Delete” button will delete the “Other” Email record, showing a deletion confirmation dialog box first. The message box is shown ABOVE the Quick Action dialog (which is strictly speaking an example of "dialog over dialog", as the message box is just the simplest form of a dialog ;-):

If the user clicks “Delete”, the entry is deleted, and control is passed back to the list (that is: to page 1), where a message toast is used to confirm the deletion. As per the message toast guidelines, this is shown towards the bottom of the screen, centred.

Use of page 2 of the dialog

“Extending” the amount of information that can be shown by using page 2 to show additional fields is not strictly forbidden, but please remember the Fiori guideline of max. 8 fields on a dialog. If the fields to be shown / entered do not fit into a dialog with this restriction, then the process in question is probably not a Quick Action.

So please use page 2 for a truly separate step: the workflow approval dialog shown above is a separate step: the data was changed in step 1; the approval workflow is triggered in step 2. So step 2 is a continuation of step 1, not an extension of that process in terms of content.

In order to improve orientation for users reliant on screenreaders, and to improve orientation within the Quick Action for all users, consider using the subHeader aggregation in the Dialog control in order to give the dialog a subheader, like this:

Dialog subheader

Note that the subheader is not used very often, so it's possible that most developers are not aware of it. Details of the subheader can be found in the API reference to the Dialog control.

Application-specific examples

UX Writing Guidance

When creating a dialog text:

• Keep the title short and crisp, it can´t exceed one line in length.
• Don't change the dialog title between pages 1 and 2. If it is necessary to provide more/different information, use the Dialog's subheader.
• Don´t use abbreviations.
• Don't use synonyms.
• Use active formulation.
• Use initial capital letters.

The following links point to:

• a chapters in the Frontify UX Guideline for additional information: About UX Writing
• the page: SAP SuccessFactors HXM Suite - Product Assistance: SAP SuccessFactors HXM Suite

For questions to the UA Team, please use the following DL:

• mailto:DL_6463A20EA1D4B3D3F6DA72BB@global.corp.sap

Accessibility

UI elements on the dialog need to be annotated as per normal.

The "interplay" between page 1 and page 2 leads to a need for special attention on the topic of wayfaring, i.e. ensuring that the reader always knows where they are and what has changed (not just in the content area, but also in the dialog header).

Whereas the title should always remain the same, the subheader element of the dialog must be used to ensure the user has information on the purpose of the dialog: am I looking at a list of items? Am I editing the information of a specific item? Am I submitting the changes I have made for approval via a workflow?

1. Static part: (handling the speech output on dialog opening)
   - The Dialog needs a labelledby relation to title and subheader, on 2nd the relation remains but because only the content changes, this will likely not cause speech output by default.
   - On opening the focus should be put on the first option to be changed/selected
2. Dynamic part: to indicate the change, we need to do the following:
   1. A string “[Title Content]+[subheader content]” for 2nd (BUT ALSO for 1st when activating the back button) has to be spoken on change using an invisible message https://experience.sap.com/fiori-design-web/invisible-message/

• The focus should be put in step 2nd on the first option to be changed/selected and NOT on the back button.
  On triggering back via the back button, the focus should be restored in 1st on the element that performed the navigation to 2nd.

This sounds more complicated than it is. Any questions? You know who to get in touch with :-)

Resources

SF Dialog guidelines

SF Form guidelines

SF Web Stencils Horizon Template

The following Figma components are available in the SF Web Stencils library.

Form

Since this is a dialog, any type of field that can be used on a dialog can be used. The field types shown in the template are only examples, and can be changed to suit.

Additional remarks:

• Message strip at the top of the dialog, for general messages, for example: an application error
• Subject user area below this, in the case of processes that relate to someone other than the logged in user. Typically, these are MSS processes, but another good example is a Quick Action to give someone feedback.
• Fields needed to support the process, read-only or editable. In the case of EC Quick Actions, the fields shown are configurable via a configuration template based on MDF. So the “Change Location” process for customer A might contain different fields from the same process for customer B.
• Finalising buttons in the footer. Typically there will be 2: Save (primary) & Cancel (tertiary). Or 1 (Close (tertiary)) if there is nothing to edit. Maximum number allowed: 3: 1 primary and 2 tertiary.

List

This could be a simple “view” Quick Action, listing all entries related to a person. Or it could be the frontend to an “edit” Quick Action: clicking/tapping one of the entries leads to a (form-based) dialog, where the user can edit / delete an entry.