FAB Process Flow standards / conventions / best practice guide

Owned by Charles Evans (Unlicensed)
Last updated: Jul 31, 2024 by Monica Nicolas
3 min read

Roles:

  • You can name roles specifically created for your solution as you see fit (like "Approver" below), but refrain from using spaces - use underscores instead.



FAB 3.3 UI - Roles
1665px

Levels:

  • Level Name should be a noun, and the Status should describe that noun. For example:

Please take note that the Level Name and Status fields are used in reporting and audit trail information, and should therefore be chosen carefully.


FAB 3.3 UI - Levels


Tasks:

  • Where possible, a Task ID should be defined as a verb. Where necessary, use underscores (but never spaces) in the Task ID. For example:


FAB 3.3 UI - Tasks


Note that the Task  ID gets used in the visual representation of the Process Flow (eg START, SAVE_DRAFT, etc.):

When zooming out, these get replaced with the Abbrev. field contents (Strt, Drft, etc.):

  • When defining parallel tasks, ensure that the relevant parallel tasks are defined in one level. It is important to note that, internally, all parallel tasks need to be completed before the Process Flow moves to the next level.
  • A number of sequential tasks can be defined within one level but these should be actioned by different approvers / actors where possible.

Task Actions:

  • Action ID's should be defined in UPPER CASE and contain no spaces by convention. If necessary, combine more than one word into an ID using an underscore. These are used in ABAP code, and as such should be similar to the Function Code values we define in a GUI Status.
  • Action Text should be a verb or a (very short!) sentence fragment containing one or more verbs. This is the actual text that will appear on the button. For example:

  • Please adhere to the Fiori guidelines for buttons where possible.
  • Try to ensure that the 'main' button (used most often) is defined first, as the buttons will appear in the Process Flow toolbar (left to right) as they are defined in the designer (top to bottom).

System (background) tasks:

  • We recommend using System Tasks where an action (approval, document posting, etc.) may require authorisations that the current user may not have. Note that when using a system task, no feedback is presented to a user - this will have to be catered for explicitly in your solution. You can set a task to be a system/background task by clicking in the "More" button on the Tasks tab (far right):

: