Workflow Components

General information on process definitions

A process is generally a course, a development. A workflow process is a directed flow of a request, for which it is defined in advance what it should look like, which instances are to be passed through and which role holders are involved. It is thus a predefined sequence of activities in an organization (company, organizational unit). The workflow here consists of a sequence of functions, connected in time and by subject logic, that are necessary for processing a request and whose transitions between functions are controlled automatically.

A user role (role for short) defines the tasks, properties and above all the rights of a user. User roles are used so that various settings in Webdesk do not have to be defined for each user individually. Instead of assigning permissions directly to individual users, a user role is defined, which can then be assigned to many users. This simplifies permission management in Webdesk, particularly since, when changes occur, only the permissions of the user role need to be adjusted.
In principle, a role is a conceptual further development of user groups. A user can have several roles, and the user's rights then result from the sum of the rights of all roles.

Workflow variables are a container for calculation quantities ("values") that occur during the course of a workflow process. These values are used to designate the input parameters for a function. The value of the variables therefore does not change during the calculation of a function value. An expression with variables always has the same value, regardless of where in the program it occurs. This property is known as referential transparency. For example, a certain variable (a certain value) can be linked to a condition that influences the course of the request (e.g. to include an additional role).

The term transition represents the transition from one activity to the next within a process. Transitions can be linked to conditions. Several transitions can originate from one activity, e.g. in the case of a decision 1 transition in the case of approval and another in the case of rejection.

The general components of a workflow are set in the standard process definition. For individual requirements, these are defined specifically in an XPDL form.

General form types

6 standard form types are available for process design:

• Permission
  With this form type, an overtime permission can be configured, for example
• Absence
  This form type can be used, for example, to model a vacation or time-off request
• Follow-up absence reason
  This form type allows modeling a sick note submitted by a colleague
• Account correction
  With this form type, the correction of a certain account can be configured
• Time correction
  This form type allows the design of a time correction
• Collective time correction
  This form type enables the design of a process for several time corrections at once (with different dates)

General components

The general components of a request flow define, for example, whether and on which event (approval, rejection) the requester is to be informed, whether an email notification is to be sent, whether the request is automatically approved/reviewed, etc.

Workflow steps

In the workflow steps, the flow of a request is determined. This is done by defining roles that are to participate in the process flow (e.g. supervisor approves, HR department reviews). This also defines the actions that the role holder has to perform during the course of the request (approve, review). This is also where it is determined whether a role holder has to be selected by the user at process start (e.g. selection of a deputy). This is used, for example, when a user wants to go on vacation and wants to determine a deputy for this period, or names a colleague who is to take over their tasks during this time. Here the flow could be set up so that the colleague must agree to their "deputyship" (review) before the request goes on to the supervisor, who can then approve/reject it.

Every step, every task in the process flow, is to be performed by a role, or by its deputy, which is why the ranking within the role holders is important here:

• central = 2nd supervisor with lower ranking
• decentralized = user determines deputy themselves > selection (advanced settings of the user)
• Determination of the role holder based on the configuration of the process (parameter: Selection of the role holder required at process start?)

Context menu

The context menu allows the request form to be linked to e.g. the monthly journal or calendar/group calendar. This setting then enables direct access to the request from the monthly journal, calendar/group calendar).

Help

The Help parameter allows the design of a help text that is displayed in the request, e.g. how to handle the form or the like.

Mail

With the Mail parameter, an email notification can be designed that the user is to receive, e.g. that a new request or a new task needs to be processed.

Limit definition

Every activity in the workflow flow can be given a time limit (max. duration > unit in days, hours, minutes). This time limit applies from the creation of the request. If it is exceeded, certain actions can be triggered. As standard actions, a request can be approved or rejected automatically after the time limit expires. In addition, an email notification to the requester or escalation to a higher authority can be configured, or the process can take a different path.

Deadline definition

In contrast to the time limit, a fixed deadline is tied to a specific date.
Example: for business trips, open business trip requests are to be converted into travel expense reports on a specified cutoff date (for example the 15th of every month).
Another example: all time correction requests must be approved by day x, otherwise all unprocessed requests are approved automatically.
A dedicated job checks the specified deadlines and automatically starts the necessary action.