Ways to Trigger Requests

Requests are messages that are displayed during the execution of objects. Requests either require you to enter data for further processing or they draw your attention to potential problems. There are different types of request, depending on how they have been triggered.

As a developer and object designer, you have the following possibilities to configure objects so that they trigger a request:

Assigning Notification Objects to Executable Objects

Notification (CALL) objects that have been configured to send either a Request, a Message, or an Alert trigger CALL requests. Since Notification objects can be configured to send notifications to multiple recipients, CALL requests are also sent to multiple users, namely the recipients. To see the list of recipients of a request, open the Recipients tab on the Ways to Trigger Requests of the Requests view. The Type column in the Recipients list identifies whether the recipient is a User in the system or an email address.

A CALL request can be accepted or rejected. The user who accepts it assumes the responsibility for the execution. When a CALL request is accepted, it disappears from the view of all recipients except the one who accepted it. It remains in the Requests view of the owner who accepted it until the Done button is pressed. If, instead of pressing Done, the owner rejects the request, it is displayed again to all recipients.

Assigning PromptSets to Executable Objects

PromptSets are interactive forms that are assigned to executable objects. When an object with a PromptSet is executed, the following happens:

The PromptSet is called during its Activation stage.
The task stops processing and its status changes to Waiting for User Input.
A request is sent to the user who triggered the execution.
The task remains in waiting status and the request in the Requests view until the user populates the required fields.

The status of the task is visible to users in the same Client in the Tasks list (Process Monitoring perspective).

Note: If the user who triggered the execution is not available, the task remains in Waiting for User Input status. To unblock it, a different user must take over the task. For more information, see Taking Over Ownership.

Using :READ Statements in Scripts

You can use :READ statements in your scripts to build requests with input fields.

:READ requests are similar to PromptSet requests, although they create simpler forms with input fields only. The main differences are:

Only the user that executed the task can access them
They are called at a later point of the execution, namely during Generation. For this reason, if the owner of the task is not available, it is not possible for another user to take ownership of the task. The script stops processing until the request is resolved.

Tip: Use PromptSets instead. If a script stops because it is waiting for user input after it has already made changes to, for example, a file system, you may end up with inconsistencies.

Using :PRINT Statements in Scripts

You can use the :PRINT statement in :BEGINREAD ...:ENDREAD statements in your scripts to provide information to the user about the execution of a task. This information is then available in the Activation Report, which is also written to a request and displayed in the Requests view.

Activation Report are called during Activation or Generation. They are for information purposes only.

CDA