Mail address guest user

See also: Mail address user value reolver

Value resolver – Abstract

Purpose: Reads the 'E-mail address' property of a guest user account, either optionally as an input value or as a User of session, and returns this address (if present) as an element of a string list.


images/download/attachments/91132152/image2022-1-24_10-27-28-version-1-modificationdate-1643016448952-api-v2.png

The Mail address guest user value resolver returns the 'E-mail address' (emailAddress) field of a guest user account (see Guest users) that is optionally defined using one of the following methods:

  • If the Use input value option is not selected (default), then it is assumed that a guest user is logged in for the current session. Its account is evaluated if it is considered as the User of session in the execution context of the value resolver.

  • If the Use input value option is selected, then it is assumed that the guest user account evaluated is the input value for the value resolver.

If successful, the return value of the value resolver is a list of strings (string[]) containing exactly one entry for Guest users, namely the value from the 'E-mail address' (emailAddress) field of the evaluated guest user.

►NOTE◄ Even a single match is returned as an element of a list, so a value resolver (e.g. List item or Rule list resolver) may have to be used to access the single value directly. However, this does not matter in the typical environment within a E-Mail event action, since strings or lists of strings are accepted there when addressing e-mails (in the 'Recipient', 'CC' and 'BCC' parameters)

The return value of the resolver, on the other hand, is 'No value' (null) if at least one of the following conditions applies:

  • The method selected to determine a guest user account, depending on the Use input value option, does not return a guest user account. This is true in the following cases:

    • The Use input value option is selected, but at runtime the input value for the value resolver is not a guest user.

    • The Use input value option is unselected, but at runtime the User of session is not a guest user in the context of the value resolver. This occurs when one of the following conditions is met:

      • A full user (see Users and, if applicable, Mail address user) is logged in to the current session.

      • In the current session, a guest user (see Guest users) is logged in, but the value resolver is executed (directly or indirectly) within a Run as event action that temporarily defines a full user (see Users) as User of session.

  • The evaluated guest user account does not contain a value in the 'E-mail address' (emailAddress) field.

►NOTE◄ The evaluation of a guest user account by the Mail address guest user value resolver is performed without any regard to access restrictions that apply in the execution context (Role of session, Company of session, Run as) for the relevant guest user account. The value resolver can therefore also access any Guest users communication information that does not appear, for example, in a Search or overview with the same login data.

Configuration

If the Use input value option is selected, then the value resolver expects a data object of the 'Guest user account' type as an input value. This can also be volatile (unsaved) data of a new guest user, as passed to the createdGuestUser variable, for example, in the context of the Create guest user event action.

images/download/attachments/91132152/image2022-1-24_10-28-6-version-1-modificationdate-1643016486772-api-v2.png

If the Use input value option is selected, then a guest user is expected as the User of session in the context of the value resolver. This is only true if the current session is being run with a guest user login and no Execute with event action has been used in the direct or indirect execution context of the value resolver, which refers to a full user (see Users) defined as the User of session.

images/download/attachments/91132152/image2022-1-24_10-27-38-version-1-modificationdate-1643016459037-api-v2.png

Examples

Example: Access to the e-mail address of the logged-in guest user

When a particular interaction causes an e-mail notification to be sent to affected entities in a business object, the 'trigger' itself should also receive a 'blind copy' (BCC) of the message.

This process should generally apply to both Users and Guest users. Users should only be notified if an e-mail address for the 'BCC' context is saved in the user account.

Configuration:

Within the configuration of a E-Mail event action, which regulates the notification, the Bcc tab is opened in the image, which defines the recipients for the 'blind copy':

  • Via the images/s/-95e2zf/9012/8yg2g7/_/images/icons/emoticons/add.svg icon two entries for recipient definitions have been added here:

    • The first entry uses the Mail address user value resolver, which only returns one or more recipient addresses in the context of a regular login, as far as specified in the user account for the 'BCC' context.

    • The second entry uses the Mail address guest user value resolver with the Use input value option unselected, so that in the context of a guest user login, the e-mail address from the guest user account used is added as the addressee for a blind copy.

►NOTE◄ At runtime – depending on whether the User of session is a user or a guest user – only exactly one of the two configured value resolvers will 'deliver' e-mail address data at any time.

images/download/attachments/91132152/image2022-1-24_10-30-9-version-1-modificationdate-1643016609526-api-v2.png

►NOTE◄ If the E-Mail is executed in a context where a Run as event action explicitly refers to a user different from the actual login, the user is considered the User of session. Then only the Mail address user value resolver can provide an e-mail address if it is stored in the specified user account. The actual logged in Users or Guest users will then not be notified.

Example: Access to the e-mail address of any guest user account

An event handler in Lobster Data Platform / Orchestration triggered every night by a Lobster_data CronJob sends an e-mail warning to all Guest users whose accounts are due to expire within the next 48 hours, according to the time specified for the 'Valid to' (validTo) field.

Within event handling, the two event actions shown on the right are configured:

  • First of all, a Search (Event action) is executed, which will not be discussed in detail here. A Search is executed which passes a list of all Guest users into a variable named expiringGuestUsers for which the following conditions are true:

    • The guest user account is currently 'active'.

    • The number of registrations granted is unlimited or not yet used up.

    • There is an entry for 'Valid until' that is still in the future, but no more than 48 hours after the 'Begin of today'.

  • Subsequently, a For each loop is executed, which runs through all entries in the list determined by the Search (Event action):

    • The Resolver for entities is a Variable value resolver that expects a list of entities of the 'Guest user' type.

    • Within the loop, a E-Mail event action is executed, which sends the notification to the listed Guest users. The screenshot shows the Recipient tab, where the Mail address guest user value resolver is used to determine the 'E-mail address'. The Use input value option specifies that the evaluated guest user account should be available as an input value for the value resolver. This is guaranteed here within the loop without further measures.

►NOTE◄ Basically, all access restrictions applicable in the login context apply to the Search (Event action). The list passed as the 'search value' can therefore only contain Guest users entities for which at least read access is guaranteed. In the present context, the event is triggered periodically starting from Lobster_data via a CronJob, where a Single import triggers the DISPATCH_EVENT action for a Custom action event. The login context for event processing in Lobster Data Platform / Orchestration is defined within the profile definition (response path or mapping, if applicable). Depending on the specific objective, a combination of Role and Company value can be selected to control whether the notification is executed for all Guest users that will soon expire or only for accounts that are 'visible' from the perspective of a specific Company of session due to ownership and, if applicable, Company authorizations.

►NOTE◄ It should be considered that the Company of session selected for the login context is also the owner of any E-mails generated, if they are saved as an object in Lobster Data Platform / Orchestration.

images/download/attachments/91132152/image2022-1-24_10-34-7-version-1-modificationdate-1643016847170-api-v2.png