The OpenText Process Suite ABC Glossary - Inbox part 1

INBOX

An integral part of the OpenText Process Suite platform is the inbox application that can be accessed by means of the My Inbox artifact included in the My Applications App palette. The inbox is the default mail box that is used to receive or forward any of the tasks and/or notifications originating from a business process model or case model (only tasks).

The inbox enables users to work on their tasks, read details, add attachments or notes to the task, etc.

Alternatively, the users can set their preferences to send tasks or notifications to their email address. In that case, they will receive an email with a link to open and work on the task or to read the notification.

Task or notification

Both a task and notification are represented by a user interface in the business process or case model. A task will pause the current execution of the process or case instance and the receivers of the task have to act or respond to the task. Typically, the user interface will provide additional information on the given task. The state of the business process instance is set to “Waiting”, for the user to complete the task. As soon as the user completes the task, the process instance will continue by executing the next activity (activities) in the process flow. This means the process is running asynchronously or in OTPS terms, this mode of process execution is called long lived. In a case, the user has much more flexibility to decide on next tasks of the case instance to work on or to prepare next tasks. Therefore, the inbox application provides a different interaction while working on or completing any of the tasks that are received through a case model. The inbox contains a separate tab page (Case(s)) to support working with case instances.

A notification is just to inform the user and can be applied only in business process models. The process instance will execute without any pause, the OTPS process engine will send out the information message and continue process execution. This means the process is running synchronously, the notification message is sent to all the users concerned and the process instance continues to the next activity (activities) in the process flow. Notifications are not supported in case models, because the flow of a case model is mainly driven by the case worker, all human interaction represents tasks enabling the case worker to work on the task and the case andds decide on any other or next tasks in order to resolve the case.

Delivery model

Tasks and notifications are represented by a user interface. While you include a user interface in the process or case model, the OTPS platform creates a so-called default delivery model. The delivery model defines how the details or data of the task or notification are presented to the user. User Interfaces are based on data models, web services, or simple freeform controls to contain the data required for the business process or case model. All the activities in a business process or case model may not require the complete data as modelled in the user interface. You can model or segregate this data by creating different delivery models. While developing a delivery model, you select only those models or web services that are needed for the specific activity or activities, and thus create multiple delivery models for a user interface. For example, with a generic multi-purpose employee data form, you can hide private sensitive personnel data from non‑HRM users. The user interface that you carefully designed and its different delivery models can then be used for diverse purposes. With a delivery model, you can create inbox delivery models for presenting the tasks details in the OTPS inbox artifact and email models for delivery of the tasks details by email.

List of abbreviations 

Don't miss out on future blog posts! Subscribe to email updates today!