# Workflow

## Key Features

| I18N characters are not supported for values which are used as UI information (e.g. field titles), e.g. process variables

### Creating Templates

The Agile e6 Workflow module allows the definition of templates for the following tasks:

- individual workflow processes: process templates
- activities to be completed: activity templates

Creating Process Templates

Process Templates define individual activities and the sequence of these activities in a workflow process. Process Templates define resources, time periods, and completion deadlines, userexits etc. for these activities. Your process templates represent a collection of available workflow processes . They can be reused multiple times or integrated as subprocesses into any workflow process.

Creating Activity Templates

A Work Item template is created for all individual activities that are to be executed in the course of a workflow process. It can be used to insert several activities possessing the same properties. Activity templates must be defined via the single templates list, they cannot be defined in the Workflow Editor.

### Activities

Activities of your workflow processes are represented in the Inbox by Work Items. Reusable templates can be created for all activities and stored in template libraries. When defining the workflow process in the Workflow Editor, such templates can be copied and inserted as required. Alternatively you can create entirely new activities. Activities can be executed automatically.

Adding Activities

Using the Workflow Editor new activities can be added to a process:

- You may add copies of an existing activity template or
- add a new activity.

Activity Properties

Activities are described by means of the following set of properties. When an activity template is created with a set of predefined properties, these properties will be available as default values when designing a workflow process using the referenced activity template.

- Activity Name
  Name of the activity to be completed
- Phase
  Defines the current activity status (e.g. Definition, Execution) and is updated by the system
- Description
  Description of the Work Item to be completed.
- Alert User
  The user that is to be notified when the Work Item becomes overdue. If no Alert User is specified in this field, the process owner is notified instead, when the deadline of the process is exceeded.
- Duration
  Defines the estimated duration required for the completion of a Work Item.
- Limit
  Defines the deadline of the processing period. Once this deadline is exceeded, the Alert User is notified by e-mail.
- On Complete
  This is the pre-action userexit to be executed when an activity is completed. The userexit is executed synchronously and must be completed before other functions can be executed.
- In Background
  Userexit that is to be executed as a background process upon completion of the activity. The userexit is executed asynchronously and allows the parallel execution of other functions.

| Userexits can only be assigned to normal activities and operators with editable properties!

| If an error occurs while executing a background userexit, an e-mail is sent to the responsible user of the process. The activity can be restarted.

Activity History

The Activity History contains detailed information of the process activities. The mask contains a description of all actions related to the activity. If Split operators are used for voting decisions, the field Decision gets the Label Name of the link properties. If distribution lists are used for the vote, the voting results and in case of a positive decision, the weighting is displayed. If the process has process variables, the names and values are displayed.

### Processes

Define Processes

Processes can be defined as an ad-hoc process or as a copy of a process template. When creating an ad-hoc process the current user is inserted in the Responsible for process field. This entry cannot be changed. When copying a process template, the user responsible for the process template is entered automatically in the Responsible for process field. This entry can be changed. A project, a company or a department can be assigned to processes in the definition phase.

| With the role model, user positions (jobs) can be limited to specific projects. A project can be assigned to a workflow process. Group members must be assigned to a project to get specific Work Items!

Using the graphical user interface of the Workflow Editor you can create new or modify existing workflow processes.

Start Process

All changes are transferred directly to the database when you save a process. Completion of the definition phase automatically initiates execution of the activities in the specified sequence. In this case all assigned resources are notified by e-mail.

| A process can be started without assigning resources to all activities. As soon as reaching and starting such an activity during the process the user responsible for the process is assigned automatically!
| Automatic userexits can be executed upon start or finish of each process!

Process History

The History tab on the Process in Definition and Process in Execution masks provides information on process events, date and time they occur and which user is concerned.

Inbox
The Inbox provides a list of your active, incomplete Work Items. Assigned Work Items are added to the Inbox of each resource involved. New Work Items are marked as New. The Inbox provides a range of functions for Work Item processing.

Information in the Inbox

The Work List of your Inbox facilitates your deadline management for the execution of Work Items and provides the following data:

- Priority
  Defines the priority level of a specific Work Item. Three priority levels are available. This value is set in the process definition phase an can be altered by the user that has accepted the assignment:
  - Priority High for high priority Work Items,
  - Priority Normal for medium priority Work Items (this priority is the default value assigned automatically by the system),
  - Priority Low for low priority Work Items.

- Urgency
  Depending on the values in the Duration and Finish by fields, the urgency level of an activity is either Due or Overdue. If the field contains the entry info, the Work Item is for information only and cannot be accepted or executed. This type of Work Item can be deleted from the Inbox via the context menu.
- Description of Work Item
  Description of the Work Items to be completed. This description is specified in the process definition phase or as part of the design process in the Workflow Editor. This field contains a hyperlink reference. Click this hyperlink reference to access additional information referring to the Work Item or to confirm the completion of the Work Item.
- Accepted
  Contains the date and time of your acceptance of the Work Item. If you are a member of a group or role, the Work Item is accepted for all members of the group or all persons fulfilling that role. The Work Item is removed from their Inboxes.
- Start by
  Depending on the Duration and Finish by parameters defined, this parameter specifies the date when the execution of a Work Item must have started.
- Finish by
  Depending on the Duration and Finish by parameters of a Work Item, this parameter specifies the latest possible completion date for a Work Item.
- Assigned To
  Resource type and resource name of a user, role, group or distributor. This field contains you if you have been assigned to a Work Item.
- Phase
  Describes the current phase of the Work Item.
- User
  Username of the user, who has rejected or forwarded the Work Item.
- Reason
  Reasons why the Work Item has been rejected or forwarded.

| Work items are not created for the start activity, the stop activity, joins and for automatically executed activities. They are not inserted in the Inbox!

Both the current user and the Alert User or (if no Alert User has been specified) the process owner are notified by the notifier if the deadline (Finish by date) for completion of a Work Item has been exceeded without a confirmation of completion.

The following diagram illustrates the Inbox function structure:

To execute this function, click one of the following buttons:

Accept
You take responsibility for the completion of the Work Item that you accept. Several Work Items can be selected and accepted. Within groups or roles, the Accept function signals, that a member of the group or role has accepted the Work Item and it is therefore removed from the Inbox of all other members of the group or role. The only exception to this are approval distributions where all participants are expected to respond. You need to accept a Work Item before forwarding it to another resource. The date of your acceptance is documented. You don't need to accept a Work Item before executing it.

Reject
A Work Item that you do not wish to complete can be rejected and the assigned activity can be restarted. If this Work Item was forwarded, it has to be completed by the resource forwarding the Work Item to you.
There are two cases:

- If a Work Item was forwarded to a single user, the sender gets the rejected Work Item
- If users of a group, role or distribution list reject Work Items, the user responsible for the process is informed.

Several Work Items of the Info type can be selected and rejected. If you select several Work Items which are not of the Info type , only the first will be rejected and a corresponding message is displayed.

Forward
Work Items that you do not wish to or cannot complete yourself can be forwarded to another resource. Please note that you cannot forward Work Items to yourself or to a group. Before you can forward a work item, you have to accept it. You remain responsible for this work item if the person you forward it to, rejects the work item.

Several Work Items of the Info type can be selected and forwarded. If you select several Work Items which are not of the Info type, only the first will be forwarded and a corresponding message is displayed.

Hyperlink in the Work Item Field
Clicking the Work Item field a mask with information on the processing status of the Work Item is displayed. You can accept, reject, or forward Work Items with the corresponding buttons in this window. Using process variables, input fields are displayed. Using split operators, checkboxes are displayed to specify successors. For the decision process in a distribution list radio-buttons are displayed.

Phases of Processes and Activities
The current state of processes and activities is displayed in the definition masks of processes/process templates and in the activity properties.

### Workflow Design – the Workflow Editor

| The workflow editor connects via the Windows client or Java client to the PLM server. Therefore, the Windows client always has to be started using the ECI-TOPIC parameter if you want to use the workflow editor (-p ECI-TOPIC:t:1:h:localhost:r:12349). Otherwise, the following message is displayed: "Could not read ECI-TOPIC from client environment Make sure that ECI-TOPIC has syntax ':t:transportmode:h:hostname:r:portnumber' For transport mode only tcpip-connection (=1) is allowed.
| Further infromation about how to set the ECI-TOPIC parameter can be found in the PDF document Installation Manual for Agile e6.1 Client on Windows.

### Structure

| The representation of Workflow elements is defined using a Style Sheet. The elements and illustrations shown below may therefore differ from the elements in your Workflow Editor!

The graphical user interface comprises several sections:

- The horizontal main menu with menu command icons and function icons is located at the top.
- The individual tabs of the Workflow Components window on the left hand side contain components that can be copied to the workspace using drag&drop.
- The Grapher view window on the right hand side is the workspace where your workflow process is modeled. To this end, drag the component from the corresponding Workflow components tab to the workspace.

Overview Window

The Overview window contains a simplified overview of the entire workflow. This is useful if you zoomed into details of a workflow:

The enlarged section of your workflow on the right side is color highlighted in the Overview window.
The illustration above shows the entire workflow on the right hand side, thus the entire Overview window is highlighted in color.
The zoom factor is controlled with a slider in the Overview window.

Message window

When storing a process a message window is opened in the Workflow Editor, notifying you about incomplete or component errors. This may - for instance - be caused by a link that was not assigned to a component.
The message window is displayed due to incorrect or incomplete modifications.

Click an entry in the message window to highlight the component that this error message refers to. Reopen the message window to update it.

Components

The Workflow Editor provides various workflow design components. These components are listed on the tabs of the Workflow Components window:

- Activities
- Main
- Automatic Resource Assignment
- Users
- Roles
- Distributions
- Groups
- Subprocesses
- Operators
- Process Variables

| The names and the number of components shown on the tabs may vary with the data on activity templates and process variables that have been defined in Agile e6!

Activities

Activities represent individual steps in a workflow process. It is referred to as "Work Item" when it is added to a users Inbox. New activity templates must be created in the Activity Templates list; activity templates cannot be modeled in the Workflow Editor. All previously created activity templates automatically become available in the Workflow Editor. Activity templates can be used to create a new activity - either by way of modifying the predefined properties of an existing activity template from the Activity tab or with an activity from the Main tab whose properties need to be defined from ground up.

Monitoring the State of Activities

During the process or when finishing the process the state of activities changes. The different states are identified by different colors:

- blue: completed
- green: Execution
- yellow: suspended
- red: aborted, Error

Main

The Main tab contains a number of basic building blocks that are essential for the design of workflow processes.

The Main tab contains the following components:

Graphics | Component | Description
| Start Activity | The first activity of every workflow process is the start activity. A workflow process may contain no more than one start activity.
| Stop Activity | The last activity of a workflow process is the stop activity. A workflow process may contain more than one stop activity.
| Activity | Template for a new activity that is not based on an existing activity template.
| Links | Links connect workflow components, they are represented by arrows. For activities: Click the solid line to connect activities, respectively start, stop, split or join activities. For resources: Click the dashed line to connect an activity with a resource.
|  | Click the connection line to highlight the line. To add several lines you need to click the corresponding object once again! Double-click the connection line to add multiple lines in the Grapher View window without having to click the line several times!
| Automatic resource assignment | Automatic resource assignment template

| Links can be defined only for suitable connections between process components!

Execute Activities Automatically

Automatic resource assignment is used in order to execute activities automatically without assigning resources. If you assign an automatic resource to a split-OR operator you have to assign a LogiView procedure to the operator with a background userexit. The LogiView Procedure identifies successors of the activity and of the process to control the further process flow.
Split-XOR operators cannot be executed automatically! Instead of this use a split-OR operator. In this case the corresponding LogiView procedure must define exactly one successor.

Activities that are not assigned to a resource are subject to the responsibility of the process owner during their running time.

Users

The Users tab contains user resources that can be assigned to activities. The Workflow Editor doesn't automatically load all users stored in the system but only on the user's request, providing the means to search for users who match the same or similar characteristics. The wildcards used for the search function (e.g. %) can be changed.

Groups

The Groups tab contains group resources that can be assigned to activities.

Roles

The Roles tab contains role resources that can be assigned to activities.

| If the role assigned to an activity (as a resource) has expired (there's no job with a valid date), the process the activity belongs to will be suspended and the person responsible for the process will be informed!
| If such a process has already been started and the work item is reported as completed after the expiration of the role, then the process will be suspended and changes will be denied. Also, the person responsible for the process will be informed!
| If a role has jobs assigned that are already expired, the persons concerned won't be provided with work items any longer!

Distribution Lists

The Distribution Lists tab contains distributed resources that can be assigned to activities. Distribution Lists must be created before they can be assigned.

Operators

A Workflow process can have sub-branches for single or several activities or subprocesses. These branches and their connection are defined by operators which are logical splits or joins. Split operators (Split-AND, Split-OR and Split-XOR) fork the process into branches and control if one or several branches should be executed. Join operators (Join-And; Synchronous Join and Asynchronous Join) (re-)combine branches and control when the process and its assigned activities are executed.

| No operators are required for simple sequences of activities (i.e. one activity followed by another activity and so on)!

The operators are arranged between activities and linked using connecting lines (links). The conditions defined through the operator of the predecessor activity must be fulfilled before the follow-up activity can be processed.

The control functions of the operators are explained in the following example:

A Workflow process defines the following process:

- In a company, a purchase requisition must be issued for any acquisition: Entering the data and creating the order is represented by the activity Record, which is carried out by a user who is assigned to Role C.
- The accusation order needs to be approved (activity: Approve1 and Approve2).
- The approval is assigned to different resources: User A is assigned to the activity Approve 1, a member of the group Group B is responsible for the activity Approve 2.

The type of operators used controls if one and/or several resources have to approve, before the process can continue. This means that the operators define which activities must be accepted, started or finished before the process can continue with the next activity.

The image shows the described Workflow process with Split-AND- and Join-AND operators:

The first part of the following section describes the split operators that enable you to branch a process into several follow-up activities or branches containing several activities.
This is followed by a description of the join operators that allow you to combine multiple activities or branches.

Split-AND branching (activates all follow-up activities)

Splits the process into at least two branches which must be executed in parallel. As the process is split without special conditions, a resource is not required. The activity is executed automatically/implicitly.

Example:
As soon as the owner of Role C has finished the activity Record, the process is split by the Split-AND operator. Both the User A and the members of Group B are asked for approval.

Split-OR split branching (activates one OR multiple follow-up activities)

Selects from several succeeding process branches, one or several branches which are then executed in parallel.
To execute the Split-OR operator, a resource must be assigned who selects the respective branches.

| If no resource is assigned, the task is assigned to the process owner automatically!

To facilitate the selection, connection lines (transitions) are editable: Enter a descriptive name in the field Text in the properties of the connecting lines between the Split-OR operator and the succeeding activity. In the image below the amount is entered which does not require an approval (< 500), which requires approval by User A (> 500) and by the Group B (> 3000). If a value is needed for LogiView enter a unique name in the field Label (If no name is entered, a value is inserted automatically when storing the process).

Example:

As soon as the owner of Role C has finished the activity Record, user User E is responsible to select the next branch(es). He will be sent a Work Item associated with the Split-OR operator, and in this Work Item he will see options corresponding to the labels of each of the output links. Whichever options User E selects will be the branches that are executed.

Split-XOR - branching of the process procedure (activates exactly one follow-up activity)

Selects exactly one branch out of several within the process.
To execute the Split-XOR operator, a resource must be assigned who selects exactly one branch.

| If no resource is assigned, the task is assigned to the process owner automatically!

Example:

As soon as the owner of Role C has finished the activity Record, user User E is responsible to select exactly one branch. He will be sent a Work Item associated with the Split-OR operator, and in this Work Item he will see options corresponding to the labels of each of the output links. Whichever options User E selects will be the branch that is executed.

Split-XOR - branching with vote decisions

A workflow process can contain split-XOR branchings, to display vote decisions.

In this case exactly two possible successors must be linked to the Split-XOR operator as a resource. Edit the properties of the connecting lines which link the operator to the next activity. Enter YES for the label for the connecting line which is selected in case of a positive decision. NO is entered in the label for the branch which is selected in case of a negative decision. The process only continues when a decision is made ( for a majority vote 100 votes are required).

Join-AND - Junction (of all predecessors)

Joins several predecessor activities, all of which must be completed before the workflow process continues. Use this operator for joining branches which were split with the split-AND operator.
As the operator is executed automatically/implicitly, no resource is assigned!

Example:

User A must have executed the activity Approval 1 and Group B must have executed the activity Approval 2, that means the purchase requisition must be signed before the process will continue.

Synchronous Join junction (at least one predecessors)

Joins several predecessor activities, which were selected for execution by a Split-OR/Split-AND operator. As the operator is executed automatically/implicitly, no resource is assigned! The following conditions must be fulfilled before the workflow process continues:

- all predecessor activities have been split up with a Split-OR/Split-AND operator.
- all predecessor activities and running activities are completed.
- all links (of all branches) between the Split-OR/Split-AND operator and the Synchronous Join operator must contain at most a single activity or a single subprocess.

Using an synchronous join operator:

Example:

If User E has selected the branches with the labels> 500 and > 3000 with the Split-OR operator, the synchronize Join continues the execution of the process when the activities Approval1 and Approval2 are finished.

| There is only one activity (if applicable - also a subprocess) allowed between a Split-XOR operator and a Synchronous Join junction!

Asynchronous Join junction (exactly one predecessor activity)

Joins several preceding activities. The process is continued as soon as the execution of an activity or branch has been completed. As this operator is executed automatically/implicitly, no resource is assigned.

Example:

User A must have accepted the activity Approval 1 or Group B must have accepted the activity Approval 2, before the process will continue. Finishing the second activity has no influence on the further process.

Using Loops in the Workflow Process

Asynchronous Join operations are integrated before an activity to form a loop. A split-XOR after the activity operator linked to the Asynchronous Join operator in front of the activity closes the loop.

Subprocesses

Predefined process templates can be integrated into other processes. Thus, individual components of the process can be reused and do not need to be created again. Templates integrated as a subprocess are part of the superordinate process.

Process Variables

Process variables are input or output values of activities that are entered into the workflow process and which can be forwarded from one activity to the next. Attributes can be created with the manager functions of the Attribute Pool.

The assigned resource enters the corresponding values in the course of an assigned Work Item. In the course of this procedure, special masks are created for each Work Item where individual values can be entered.
Individual access privileges that are graphically represented by way of different connection line styles can be assigned to each value:

- read-only
- input optional
- input required

| When editing a process template, don't remove process variables when at least one process definition has already been derived from this template! When creating a new process as a copy of a process template, no additional process variables can be added!

Using Components

All workflow components (resources, connection lines, process variables, subprocesses, and all activities including start and stop activities) are available via tabs in the Workflow Components section. These components are represented in the Workflow Editor as boxes and lines. Double-clicking activities, operators, and links opens the corresponding Properties dialog window.

| You may define custom images for activities in the Style Sheet!
| Editing the Style Sheet

Editing Components

Components can be edited with buttons and menu commands.

In addition to process variables, workflow components can also be positioned freely on the user interface. Process variables are positioned in columns and assigned by way of connection lines.

If components are moved the connections will remain intact. Automatic positioning can be either horizontal or vertical. Agile e6 arranges the components in the Workspace.

Selecting Several Components

- Click the right mouse button and drag the frame over all components to be selected or
- hold down the Shift key and click all components to be selected.

Undo or Restore Modified Entries

To undo changes or restore modified entries use either CTRL + Z or buttons and .

Cut&Paste

Components can be cut (CTRL-X), copied (CTRL-C), and pasted (CTRL-V).

Store on Exit

If the Workflow Editor is closed after changes have been made to the workflow you will be prompted to save or discard those changes.

### Changing the Component View

| Java programming skills are required for the implementation of component view changes. If errors occur in the parameter configuration this will prevent the workflow from being displayed in the Workflow Editor. Therefore, all modifications of the Style Sheet must be performed by skilled persons! Manager Information

The representation of the workflow components is defined by way of Style Sheet parameters. You can therefore customize the user interface and graphics to customer-specific requirements (e.g. activities or connection line) according to individual requirements (e.g. corporate design requirements of your organization).

### Editing Component Properties

The properties of components can be modified in the corresponding mask. Fields of the masks vary depending on the type of component. Changes of properties are made in the corresponding lists (i.e. process template lists and process definition list) and saved.

### Distributions

Distribution Functions
The approval distribution of the Workflow module ensures uniform approval rules for voting procedures and approval processes. The distribution automatically assigns business processes with review obligation to authorized users and notifies assigned users. Generally speaking, a Work Item is always assigned to users or user groups in the system.

The main distribution may contain several subordinate distributions since it is based on a predefined structure. This method enables a detailed reproduction of complex organizational structures, which are defined centrally and be applied in different ways in various high-level distributions.

Users and groups can be assigned to a distributor. When using the distributor for voting, an individual weight can be determined.

In case the summation of all weights of all users and groups is less than 100, the workflow process will stop as the predecessor activity can't be finished because its successor (the activity with the distribution) can't be started. The user responsible for this process is notified automatically. After correcting the distribution, the predecessor activity can be finished and the process will go on.

Votes will be taken as follows:

- An activity is approved when the positive voting has reached 100 votes of all resources who must sign the activity.
- An activity is rejected when the negative voting has reached 100 votes of all resources who must sign the activity.
- In case no mandatory voters exist, the decision to approve or reject a process is done automatically if the summation of positive or negative votes reaches 100.
- Special case1: In case all members voted and there is no clear decision (positive and negative voting is less than 100) the activity is rejected.
- Special case2: In case all members voted and positive and negative votes are above or equal 100 the activity is approved.

For each entry of a group or a user in a distribution list, a new Work Item is created. A group assigned to the distribution list is also assigned to the Work Item. Besides the casted votes, the history shows if the user has casted the votes as a member of a group in a distribution list.

### Work Requests / Work Orders

A Work Request comprises all required information regarding a proposed modification:

in the Header form:

- Request identification number
- Version
- Purpose
- Type: changed Work Request or created Work Request
- Distribution: assigned distribution for distributed review activities
- Project that the Work Request is referring to
- Process template: assigned process template
- ID: identification number of the assigned process template

On tabs:

- General: Description
- Products: products where the affected objects are used
- Affected Objects: projects, items, documents that are affected by the Work Request
- Work Orders that result from the Work Request
- Projects related to the Work Request
- Documents with a detailed description of the Work Request
- Solutions to be selected and assigned from a common table with suitable solution recommendations
- Persons that are involved in the creation and execution of the Work Request
- Companies: companies/departments that are involved in the creation and execution of the Work Request

The standard procedure for the preparation of Work Requests and Work Orders is divided into phases:

Preparation Phase

- The first step is to prepare a Work Request. A unique number is assigned and descriptions need to be added.
- The objects (projects, items, documents) affected by a Work Request or Work Order must be assigned to a folder. A new folder is automatically generated for this purpose.
- Present several possible solutions for the problem at hand respectively assign several solutions to the problem (optional).
- Define a distribution list that is used for lifecycle and for the streamlining of individual activities (optional).
- Assign a process template to the Work Request and select a project to which the Work Request is referring (optional).

| When the Workflow Module is used in conjunction with the Enhanced Change Management Module, the Affected Objects tab of the Work Request/Work Order mask is replaced by the Change Operations tab!

Approval Phase

- State change: The Work Request changes the state to In Approval. The various states are defined by means of the lifecycle. State changes are carried out by the Agile e6 process management and documented in the corresponding history file.
- If a process template is assigned to a Work Request, the state of the template is changed to In Definition and the process is started automatically.

Release Phase - Work Request

- Changing the state of the Work Request to Released, a Work Order is generated automatically.

| When the Enhanced Change Management Module is active, a preliminary Work Order is created automatically with the creation of a Work Request!

Processing Phase

- Once the process is initialized, execution begins. The assigned employees are notified via their Inbox where they can accept, execute, or forward Work Items.
- Employees may view affected objects, modify those objects if necessary and add comments in the form of notes.
- Objects added to the folder are processed. All changes and the number of the Work Order are documented in the corresponding object history file.
- Distributions can be specified for all Work Requests/Work Orders and may be used for custom applications, e.g. for the evaluation of Work Requests in work lists or when forwarding documents.

### Folder

A folder is comparable to the file (floating file) often used in everyday work. It is therefore a virtual work folder combining elements which are to be processed jointly. It can contain different elements (items, documents, etc.) which are required for a specific work process (change, redevelopment etc.).
A folder is created automatically when a Work Request/Work Order is created and is displayed in the structure browser. It is also possible for each user to create a folder manually and store it under a logical name.

References

The elements in a folder only represent references to the original elements and thus the content of the folder is not a copy of the elements concerned. Therefore there is only one original in the entire system and several references to this original.

This procedure has the following advantages:

- A centralized, uniform view over everything that is being processed. This is the decisive difference to the usual floating folders in which copies are contained.
- No problems concerning coordination seeing that only one original exists which can be changed.
- Access supervision is based on the access authority of the original.
- An element can at the same time be present (referenced) in several floating folders.

Unique view of elements

In the folder itself the identifying data of all application elements are represented in joint columns (mixed projects, articles and documents). An additional symbol in the first column helps to denote which type of element is concerned. Hereby given letters mark the type of element:

P | Project
A | Article
D | Document
F | File

If the elements entered in the folder are structured (e.g. list of parts), this structure (structure levels) can be identified by indented dots in the first column.

### Notifications

In the Workflow module the following four different types of notifications can be generated:

1. Notification mail (new work item)
The notification mail is initiated by the notifier and contains links to the work item and to the inbox (both either via Web client or Java client).
Example:

| Please note that the sending of notification mails can be suppressed by activating the None checkbox in the Workflow Notification window!

> For further information on how to suppress the sending of notifications see the topic Set the Date of the Workflow Notification.

2. Due mail (work item got due)

The due mail is initiated by the watchdog if a work item of the recipient reached the due-date and contains links to the work item and the inbox (both either via Web client or Java client). The sending of due mails depends on the entries in the Duration and Limit fields of the Activity properties mask.
For further information on how to set time limits for the sending of due mails see the topic Edit Activity and Transition Properties.

Example:

| Please note that the sending of due mails cannot be suppressed!

3. Over-due mail (work item got over-due)

The over-due mail is initiated by the watchdog if a work item of the recipient reached the over-due date and contains links to the work item and the inbox (both either via Web client or Java Client). The sending of over-due mails depends on the entries in the Duration and Limit fields of the Activity properties mask.
Example:

| Please note that the sending of over-due mails cannot be suppressed!

4. Over-due mail to the process responsible

The over-due mail for the porcess responsible is initiated by the watchdog if an activity of a process reached the over-due date and is sent to the process responsible. It contains links to the process console (either via Web client or Java Client).
Example:

| Please note that the sending of over-due mails to the process responsible cannot be suppressed!