• The value resolver for Root items must return a 'list' that can contain simple values or complex data items. A single element must also be formally passed as an element of a list to appear as the only option in the context menu.
  
  

• The optional Label expression (see Calculation expression) is applied per list element to define the label of the context menu option. Here the complete list element is considered $input. The default entry {label}therefore refers to the value of the label field in a listed item. If the Label expression is empty, all items appear without a label.
  
  

• The optional Children field parameter identifies a data field of the listed item, which can contain a list defining items of a submenu. The items listed in it are also visualized as menu items by means of Label expression and Icon expression. This concept can be applied in a cascading manner, i.e. for several nested menu levels. Menu items are only considered selectable if they do not contain any 'Children fields'.
  
  

• The optional Icon expression (see Calculation expression) is applied per list element to define the path to an icon (see Working with image resources (Icons)). The complete list element is considered as $input. Therefore, the default {icon} entry refers to the value of the icon field in a listed item. If the Label expression is empty, all options will appear without an icon and the context menu will appear without an icon column.
  
  

• The option Enable search defines, whether a search for context menu entries is available in the menu or not (default).

The other parameters concern the behaviour of the opened context menu with regard to the selection of an entry by the user. Depending on the selected Mode, different configuration options are offered here:

The default Mode is the option 'Receive Item', which opens the context menu synchronously.

• The parameter Name of result variable defines through which variable the following event handlings can access the return object, as soon as the context menu (with or without selection) is closed. If the user selects a menu item from the context menu, then the associated list item (from the list defined by Root items) is considered a return object in its entirety.
  
  

• The Wait time defines the duration of the waiting time (in seconds) until the context menu is automatically closed if the user does not make a selection or closes the context menu without making a selection. The default value here is 30 seconds. The minimum value is 1 second. The waiting time can be set to be 'very long' with high values but not defined as 'unlimited'.

Alternatively, the Mode can be changed to the 'Execute action on client' option, which opens the context menu asynchronously, so that event handling continues immediately without waiting for a selection in the open context menu.

The only Item click action available when selected is the 'Client workflow' option. By selecting this option, a Client workflow can be defined that the event handler passes to the client at runtime for execution when the context menu is closed. The following applies to the context of the client workflow:

• The transferred input object is the return object of the context menu. If the user selects a menu item from the context menu, then the associated list item (from the list defined by Root items) is considered as the return object in its entirety. If the context menu is closed without selection, the return object 'no value' ($null) applies.
  
  

• The asynchronously triggered Client workflow does not get access to variables defined in the context of event handling or to their contents. This also means that in the triggered Client workflow, there is normally no access to the input object from the calling context, unless it is contained in or identical to the return object.

►NOTE◄ In conjunction with the Mode 'Execute action on client', the context menu remains open 'indefinitely' in principle.

Instead of labels, a unique field key is now provided, which at the same time ensures the unique identification and thus the starting point for a localization of the entries via the Localization (see right).

• A separate Resource bundle is dedicated to the context menu (contextHeading), which is not mandatory but maintenance-friendly.

• In the Resource name column, all values are displayed that appear in the JSON definition (left) as a value for the key field. These are provided here with translations for the languages German and English.

• The abbreviation GPS does not need to be translated.

• The value for the Root items parameter is defined by first defining the JSON structure as a static text value (see Static values) and then passing it via concatenation to a value resolver of the JSON to object type (with default settings).
  
  

• In the Label expression, the Localization is accessed via the syntax [Bundle, Resource, Default], where the key field determines both the 'Resource Name' (Resource) and the default value (Default), which causes, for example, the untranslated entry for GPS to be labeled as 'GPS'.
  
  

• For all other parameters, the default values are retained here. The JSON text has been adjusted to the default values for the data field of the Children field and the Icon expression right from the start.

►NOTE◄

• In addition to the labels, you could also define the paths for the icons via localization entries to enable language-specific symbols.
  
  

• Alternatively, you could create a single language entry that defines the JSON structure for the context menu as a whole for each language. If the same context menu should be opened in different contexts, this approach would be particularly maintenance-friendly, as it allows the menu structure to be managed centrally for all contexts.

Detailed requirements:

• When clicking on a Button, a context menu should be opened, which lists relevant users (with name and username) sorted alphabetically in ascending order and points to the 'language' selected for their user account via an icon.
  
  

• Only users whose user account is set to 'Active' are selectable. 'Inactive' users are also listed, but are not selectable.

Runtime example:

• The Save result as parameter defines the name of the variable (here: users), which can be used to access its return value after the search action.
  
  

• The Entity we are looking for in our example are Users.
  
  

• Under Mode, the search value was selected so that all 'result rows' are returned directly as a list.
  
  

• The Search is defined as a 'Tuple search', because on one hand access to complete user accounts is not necessary and on the other data should be prepared for the context menu by defining projections.

• The fields 'Username' (username), 'ID' (id) and language (locale) are taken directly as a Property projection.
  
  

• For the label in the context menu, the name fields from the user's address (adresse.name1/2/3) are concatenated by a literal space each via 'text concatenation projection'.
  
  

• The field disabled, which is used in the context menu to control whether a contact person is selectable or not, is assigned a negation of the Boolean value from the field 'active' (active) in the user account:

The negation can only be displayed here via a Case projection, which can be configured with a few clicks.

For the context menu, it is important that the values assigned as Literal projection (true or false) are actually of the Boolean data type and not just text values with the same wording.

The Search (Event action) stores all returned result rows as a list in the users variable, which can thus be used directly in the value explorer for the Root items for the context menu to be opened:

• Although the desired alphabetical sorting by the label field would also be possible within the definition of the search, for demonstration purposes the result list shall be sorted afterwards by concatenating a Sort list value resolver which uses the label field as the Compare value.
  
  

• The Label expression combines the label and username fields with some literal formatting.
  
  

• A data field for the Children field is not specified.
  
  

• The Icon expression takes advantage of the fact that the Lobster Data Platform / Orchestration default includes a collection of icons for national flags, whose filename matches the internal identifier for the selectable 'language' (locale) for many states. However, as the expression conveys, an exception had to be defined via the $replace function so that the icon for the flag of Great Britain (gb.png) appears when the language 'English' is selected.
  
  

• The selected Mode is 'Receive Item', because the context menu should be opened synchronously and the calling Client workflow should be interrupted until it is closed or the Wait time for value return (30 seconds) expires.
  
  

• The Name of result variable specifies that the element selected by the user is stored in the selectedUser variable.

After closing the context menu, a check should urgently be made whether a user has been selected or not. For this purpose, an If then else event action can be configured as shown to the right:

• The only condition that is sufficient is an Entity property rule that checks whether the selectedUser variable is 'not-empty'.

• In the Then block, the decisive Open external URL event action triggers the creation of an e-mail with the default mail client by building a URL via Concat strings that starts with the mailto: prefix for the protocol and then combines the username username with a static text for the domain name (@acme.org).

Runtime example:

►NOTE◄ The rigid structure used here for the e-mail address is of course only legitimate if all Users listed in the context menu can be reached via the same domain and that the mail address there always corresponds to their user name for Lobster Data Platform / Orchestration. In a real situation, a more elaborate logic for determining the e-mail address would certainly be appropriate, which could, for example, include further data from the user account.