Orka Workflow Information System

User Manual Creating workflows and using the interface

Introduction

In theory, a workflow consists of a sequence of connected steps. It is a depiction of a sequence

of operations, declared as work of a person, a group of persons, an organization of staff, or one

or more simple or complex mechanisms. Workflow may be seen as any abstraction of real

work.

For control purposes, workflow may be a view on real work under a chosen aspect, thus serving

as a virtual representation of actual work. The flow being described may refer to a document or

product that is being transferred from one step to another.

This document serves as a user manual for using the OWIS system and its Workflow module.

The purpose of this guide is to provide the users with basic information about how the system

is used, starting from the very beginning and logging on the system as well as clear examples

how the Workflow functions.

For easier understanding, this manual includes additional images of OWIS system and the

Workflow module and these will highlight the exact steps a user has to go through while using

the module effectively.

1. Module description

Workflow represents flow of documents and tasks through predefined procedures within the

organization. Features and procedures OWIS system provides are identification of tasks, their

streamlining, communication and grouping of information and documents around tasks.

OWIS workflow management module is specifically designed to handle tasks as a collection of

documents/actions while providing easy access to all of the meta-data and documents within

the task. Basic idea behind this module is to automate workflow handling through configurable

workflow. Workflow module is well-structured workflow management that prescribes how the

tasks are initiated, handled, delegated and executed. This workflow management encompasses

definitions of flow of documents between users across various organizational units and user

groups that execute the work on a certain task according to predefined rules. Workflow module

will utilizes workflow engine, while statuses of tasks are changed as actions are executed. Web

based interface will provides tasks/actions grouped information through which one can access

all information related to the specific workflow instance.

Workflow engine is designed in a flexible way to enable definition of custom statuses and

actions that perform status update, according to transition rules. This module is incorporated

within the administration module and will allow definition of status translation, read, write,

delete and execute rights for certain action types. Such approach provides flexible structure

upon which entire flow of documents and meta-data within the tasks can be streamlined to

correspond to existing procedures, and can be moreover adapted and modified to

accommodate newly formed procedures. This approach includes analysis of existing

procedures, presenting them in graphical form and implementation in the software.

Documents that complement tasks can be of two types: external documents from file system

(MS Office documents created independently and/or scans) and documents created from

within the system based on data inputted in the system. These documents can be attached to

every action that occurs in process of task handling. External documents can be attached to

actions from various sources; file system, directly from scanner, fax, email or another DMS.

Internal documents will be generated based on templates defined from within the system,

which are defined in Template management module.

1. Accessing and logging on to the OWIS system

OWIS is accessed through a web browser like Google Chrome, Mozilla Firefox or Internet

Explorer and in the same way we access any other web page.

Therefore, the first step is starting the web browser. Next thing we have to do is entering the

exact URL in the address bar of our web browser.

Now, the login page should be opened and at that point we should enter the username and

password in appropriate fields and click on the “Log in” button.

Image 1 – The Login screen

2. Accessing the Workflow module

OWIS Workflow module is accessed by clicking on the “Tasks” button in the main menu of the

application which is set in the top of the window.

Image 2 – Modules bar

2.1. Navigating through workflow views

OWIS Workflow module consists of three distinct parts which are:

- Workflow views

- Workflow instances

- Actions overview

Image 3 - Workflow module

Workflow views represent dynamic, custom made views created for each user group

depending on the needs of implementation. Default Workflow views include Pending tasks, All

tasks, Recycle bin. By selecting a specific view, user is filtering tasks based on the conditions

predefined for specific view.

In the right pane, Workflow instance, system displays all the tasks that are available to

specific user based on the Workflow view. Basic information about each Workflow instance are

displayed and these include: unique task number, task name, classification, party, starting date,

current user working on it, status etc.

Image 4 - Workflow instance overview

Each task can have visual attribute attached to it. This attribute notifies user that

specific tasks in due, meaning that due date has expired and immediate attention is needed.

Other than exclamation mark, there is also visual attribute. This attribute notifies user of

specific priority of task. All these attributes enable users to browse and work on tasks

effectively and timely fashion.

In line with the basic information about the task, system also enables administrators to

define additional data about each task that can be presented to user through info pane. By

clicking on pop up window is presented with summary data that are defined for each

implementation. This pop up can contain meta-data that is inserted during workflow execution.

Image 5 - Info pop up

Each workflow instance has detail box, where user can access data about specific

task in detail. Clicking on this icon opens detail view of task, which can be accessed or modified

based on specific user rights. Selecting the whole line of workflow instance, display details

about workflow execution in Action details pane. This pane lists all actions executed in order of

execution for selected workflow instance.

Image 6 – Action line details

Action line has main attributes about action listed. This includes action ordinal number,

action name, person that executed action, action date, action due date, delegated to,

description, details about action, documents attached to each action and delete

action icon. Clicking on details icon, system lists all documents and metadata about specific

action, depending on user access rights.

3. Browsing and retrieving workflow information

OWIS Workflow module offers simple overview of all the information about workflow instances

which include:

Image 7 - Workflow information

- Workflow view/category – enables filtering and grouping of workflows by specific

criteria. This information is relevant for browsing and retrieving workflows based on

their specific criteria defined for specific workflow view by system administrators;

- Workflow instance record – contains general workflow information of each instance.

This information include: priority, workflow number, workflow name, classification,

party, date, referent currently working on specific instance and workflow status;

- Workflow additional info – this popup displays all the information relevant to a specific

workflow and these can be configured by system administrators;

- Workflow Detail – opens the dialog window where all general information about

workflow is displayed. All of this information is inserted during initiation of a workflow

and depending on user privileges can be changed through this dialogue;

- Workflow Search – enables fast search through general workflow information;

- Action general info – this line enables users to overview all the information of a certain

action executed during workflow. They are set in chronological order and each line is

reserved for one action and appropriate information;

- Action detail – this opens up a window that serves additional information specified

during action execution, and represents a detailed review of the executed action;

- Documents – this icon represents existence of document in a specific action / step in the

procedure. By clicking document, system displays all documents that were attached or

generated in a specific step in the procedure.

4. Working in the Workflow module

4.1. Initiating a workflow instance

Each user starts procedure by clicking on Start Workflow button in

workflow module. When clicked, system lists all procedures that specific user has the right for

execution.

Image 8 - Initiating procedure

By clicking on a desired procedure, system opens up a new workflow instance and a

window where user can enters the data about the workflow. This dialog box is consisted of two

parts:

- Workflow data

- Workflow additional data

Image 9 - Workflow data dialog

Workflow data has required fields that need to be filled in order for workflow to be specified.

Fields include party name, department, classification, workflow group and etc. All data in these fields

are defined through administrative module. Automatic selecting of field values is implemented through

extensive administrative tools, where each workflow can be executed or specified for specific

department, classification, workflow group, etc. System generates ordinal number automatically where

ordinal number can be changed manually. Generation of ordinal number can be against classification,

department and/or workflow group. All these settings are defined through administrative mechanisms.

Additional data field is reserved for metadata about specific workflow in the system.

Administrators of the system define forms that are attached for each classification in the system. This

way administrator is able to define additional data about workflow that need to be inserted for specific

workflow.

4.2. Executing actions in a workflow

When workflow instance is selected, system automatically offers users those actions that can be

performed by logged user. All actions are listed immediately under workflow instance list. If the field is

empty, that means that the current user is not able to execute the action at that particular step of the

process. By clicking on desired action type system automatically opens a pop-up window in which we

can insert data about action. Other than list of most frequently used actions for specific status and user

system offers drop down menu with all allowed actions are listed and can be chosen.

Image 10 - Executing actions in a workflow

After choosing the action a new pop-up window will open, something similar to the dialogue box that opens upon

initiation of a new workflow. In this window we will insert data about the current action. User can again choose

between possible actions, users that the task can be delegated to and a due date for the delegated user can also

be set.

Probably the most important step is attaching the necessary content in a certain action. This is done by clicking on

the “Upload files” button and selecting the file we want to upload. Any type and any number of files can be

attached to a specific action.

Also, there is a form named “Comment” and this field can be used to write any additional comments about

executed action. By clicking on the “Submit” button, the user has effectively delegated the task to another user

and this shall go on until the process is finished.

Image 11 – Action data

5. Key features

- Web based interface

Workflow module of OWIS system is accessed through a web based interface. Module is

accessed from web browser without the need to install applications on a local computer

and provides ability to access the system from any platform and any standard industry

browser. Web interface enables access from remote locations for frequent travelers and

workers working from remote offices.

- Definition of multiple workflows

Through advanced and sophisticated Administrative modules OWIS enables creation

and definition of multiple workflows that can be executed and streamlined through

different organizational units or from different users in the organization. This enables

system administrators to create as many workflows in the system as organization need.

System enables dynamic and real-time change of workflows, which results in efficient

workflow management.

- Meta data

As with other modules within the system, meta-data implementation is performed via

FormsServer module. FormsServer enables OWIS administrator creation of custom forms

that can be attached to specific workflows created in the Workflow module. Attaching

forms to Workflows can be performed on several levels. First level represents attaching

form to specific classification or procedure in the system. It can also be attached to a

specific Action Type. System enables administrators to define different forms Meta data

forms provide the ability to assign detailed, structured description to documents based on

which standard database operations can be performed, such as search and reporting

functions.

- Security, access, execution level rights

OWIS supports authentication with usernames and password and two factor

authentication. OWIS system implements user access rights on several levels which will be

described in detail in this chapter. These access rights enable administrators to define

workflows to the least detail, and proper execution plan. OWIS supports advanced security

mechanisms. These mechanisms are implemented through logging of user activities on a

system level which enables authorized users to overview data. The system is built on an open

platform and data is available with appropriate access rights.

- Overview of pending tasks

Once logged in, user has access to overview of tasks / workflows. They are by default

divided in two major groups: pending and all by default, although custom views are created

through administrative modules. Pending cases indicate those that require action from user

that accesses the system (in this case, person that was delegated with the specific workflow

instance / task).

- Initiating tasks / workflow instances

Each user that accesses the system can be awarded with rights to execute step in the

procedure or to start specific workflow instance. OWIS system enables definition of user rights

in such way that each user can be awarded with specific rights so user will be able to start

specific workflows in the system.

- Integration with Calendar module

OWIS enables definition of Calendars that can be associated to different content in the

system. There are several types of calendars, based on the resource that is allocated by specific

Calendar. Calendars can be tasks, user, session, facilities or other resources defined by System

Administrators or Power Users. Administration of calendars is performed by users of the system

that have rights to create and modify specific Calendars.

Calendar module has default calendar, named Pending tasks, which is default for all users.

Through this Calendar users are able to overview pending tasks based on the due date that was

defined during workflow execution. Using Pending tasks calendar users are able to organize

their work and duties based on the information provided.

Image 12 - Calendar module

Orka Workflow Information System

Forms Server Creating and mapping forms

OWIS Forms Server OWIS system has integrated module for creation and management of application forms. These

forms are managed through administration module and enable administrators to define forms with

fields of different types (text, memo, dropdown, checkbox etc.) as well as validations for each field

(required, regular expression, range etc.). After creating these forms, system creates and maintains

physical implementation of forms as concrete database objects (tables). Forms management module

will control forms display, CRUD cycle, integrity of data, unique constraints and will serve as a mini

DBMS.

Dynamically created forms are later „attached“ to other database entities in the system (cases,

workflow steps/actions) and stored in the database with corresponding identifier of these database

entities. This makes it possible for system to have virtually unlimited number of mini databases that will

support information for collection of different attributes for different entities. Therefore, system is

equipped with flexible tools that ensure collection of specific data for various types of information.

Administration of forms can be done via administrator console or forms designer. Forms

designer supports drag and drop of controls to forms as well as arranging these fields in a form.

Figure 1 - Forms Server Modules

Forms server modules include:

* Forms module – which is representation of detailed information of forms and code tables and details

about specific fields in those forms and code tables

* Forms designer – represents interactive tool for defining forms and code tables through drag and drop

controls

* Code tables data – module that enables administrators to perform CRUD operations over code tables

* Content template map – module that enables administrators to define where and when will specific

forms be presented to user

Forms designer

Forms designer module enables administrators of the system to define and create forms and

code tables in the system.

Figure 2 - Forms designer module

Forms designer module, as represented on the graphic, is accessed by clicking on the Forms

designer (1) button in Forms server menu. By accessing forms designer module, on the left side, we are

presented with options for creating form. First option, Forms, is used for definition of forms that will be

presented to user, while Code tables option (2) is used for definition of Code tables, that can be used

later as a source for defining field in Forms that are type that represents set of data, such as code table

(for example, dropdown field type can have Code table as data source).

Definition of Code tables

In this manual we will first create Code table with specific fields, which we will use in Form later

on. By clicking on the Code tables (2) menu, system opens up the window shown in the Figure 16.

Figure 3 – Code tables

After that, we are able to select existing code table from the dropdown Form (2) and modify it,

or create new form by clicking Add form button (6). When add form button is clicked, system opens up a

dialog for inserting data about new form, in this example the Code table.

Figure 4 – Form data

Through this dialog, we can define a new Form by entering form name, description and marking

check box „Is code table“ as true. After this, by clicking insert, system automatically creates form, type

code table, which is then available in Form dropdown (2).

By selecting newly created code table in Form dropdown (2), system displays all the columns

that are part of this code table in dialog 6. Newly created Code tables have only Id field, which is identity

column for specific table.

Each Code table needs to have one column which will be of type „Value Textbox“, so we will

drag Value textbox to the right, and as such we will define which column will be displayed to user during

selection of data in Forms part (dropdowns, checkboxes etc.). When we drag and drop Value textbox to

the right, we can rename the label of that field by clicking on the „Label“ field and typing in the name.

Each Code table can have multiple fields, which will later use as source for reports and detailed

views, but only one Value Field, which will be used for presenting that data to user.

After defining code table, clicking on the button Create DB object (4), system will create

Database object in form of the table, which will have same column definition as we defined Code table.

If we select existing Code table from the dropdown (2) we can modify Code table columns, but

we need to have in mind that clicking button Create DB object will overwrite and therefore delete all

data that was present in given Code table. If we want to add some fields to Code table and not lose data,

we should use the Recreate DB object button, which will create additional, or delete specific fields

without losing data.

Forms definition

After we created Code table, we will go back to Forms creation and to the graphic from the

beginning of this chapter.

Figure 5 – Forms definition

By clicking on Forms (2) tab, system enables administrators to create Forms which will be

presented to user. Forms are similarly defined as Code tables, only they can have different filed types

inserted (4).

If we want to modify existing form, we can do it by selecting specific form using the Form

dropdown list (6). In this manual we will create new form and define couple of fields in it. First we will

click on Add form button, which will open dialog similar to one in code tables.

Figure 6 – Form data

In this dialog, we will insert name and description of form. After that we will click on the Insert

button. This action will add new record to Form dropdown (6). By selecting our newly created form in

Form dropdown (6), system opens up definition of specific Form on the right side. Newly created form

will have no fields. After that, we are able to define form by simply drag and drop field types and naming

their labels. System enables control of Form representation, by organizing fields in different columns

and rows. This way we are able to define interface of the Form, which will be presented to user.

Field types, dropdown and checkbox will need to have data source defined. In this example by

clicking on the icon (7) by the dropdown field, we will access detailed view for a specific field.

Figure 7 – Advanced settings

By clicking on that specific field, and clicking on the Edit button, system opens up dialogue box

for specific field. In Advanced settings tab of dropdown field, we can find attribute „Code table“ which

enables us to define this field data source as Code table that we defined before.

After defining specific Form by clicking on Create DB object button (4), system created database

object for this form, with columns of specific type that we designed fields in the form. For dropdown

and checkbox fields, system will create foreign keys to corresponding Code tables.

Code tables data

This module enables administrators to insert data to specific code table which is defined and

created in Code table definition part. By clicking on Code tables data module following window opens.

Figure 8 - Code tables date

In the Select code table dropdown we first select which code table we want to perform CRUD

operations. After selecting specific Code table, system displays all the data from that code table in grid

view (4). Users are able to edit and delete existing data from this grid view, through edit button or

delete button. Also administrators are able to insert new data by clicking Add data button (3),

which will open up dialog for inserting new record with all the fields specified for that code table. By

inserting new record it will be shown in grid view (4).

Content template map

Content template map module of the system enables administrators to define where and when

a specific Form will be presented. Location of the Content template map module is shown below.

Figure 9 - Content template map

After clicking on Content template map module, system opens up a window with all existing

records that were already inserted in the module. Through this grid view we are able to perform edit,

delete and update on each record. New records are inserted by clicking on the Add map (2) button after

which a following dialogue box will open up:

Figure 10 - Map data dialogue box

In this dialogue we attach a form for a specific action or other entity. In other words, this way

we choose when and where a specific form will be displayed. Forms can be attached to codes from this

dropdown list:

Figure 11 - Content template map codes

If we select action_action_type, form will be attached to a specific action type in Workflow

module and therefore it will be displayed when that action is being executed.

If we want a form to be display on specific workflow classification, we would select

case_classification value accordingly.

Following this logic, if we select document_document_type, specific form will be shown in the

Document module when a specific document type is selected.

After selecting the Code, system will show different data in the Value column. If we select

action_action_type in Code, system will present all action types in Value column. This is the part where

we define in what actions the selected form will be shown.

In the Form column, we select the form that we want to attach to the specified Code and Value.

After we define all these parameters, we can click on the Insert button and system will create a new

record, which links Form to the specific part of the system. These links can be reviewed in the Content

Template Map data.

For example, if we set Code action_action_type and we select action Value “Forwarding to CMC”

and attach Form “Comment”, every time a user executes the aforementioned action in the Workflow,

the Comment form will be available.

Orka Workflow Information System

Administrative manual Creating and defining procedures

Figure 1 – Example of procedure

In this example we will use standard procedure in an organization, such as incoming documents

delegation and response to it. In this tutorial we will create procedure within OWIS system and

assign all relevant rights to specific user groups. In the example of procedure, Figure 1, we can see

that there are three user groups defined:

1. Protocol

2. Head of department

3. Referent

When we define a procedure such as one presented on the Figure 1, we can start creating this

simple procedure within the OWIS system. Through Administrative modules of OWIS application we

can control and define all data within the system, which includes user data, user and content rights.

Bear in mind that the procedure used in this manual is a simple, straightforward example and that

much broader and demanding procedures can be set up using same steps.

User management modules

First step that needs to be executed is User group creation. This is necessary for proper User

creation because each User belongs to a certain User group that has its place in a procedure. First

we need to go to module Users User Groups.

Figure 2 - User group management module

This module manages user groups and its main data. In this module, by clicking button Add User

Group, OWIS opens form for New User Group insert. In this Form we input three main parameters

of User Group and those are Name, Type of user and Email of User group (which is used for

notifications within the system).

Figure 3 - New user group form

There are four different types of User groups:

1. Administrators

2. Signators

3. Referents

4. Protocol

The difference lies in associated rights to access certain modules within the system.

So, User Type attribute is directly associated with module rights. In administrative module Users

User module rights we can define which type of user has access to specific module.

Figure 4 - User type module rights

After filling all fields in this form and clicking Add button we insert new user group. Repeat this

step for all three user groups that we defined in first step.

Next step, after user group creation and user type definition, is creation of specific users in

OWIS. This is implemented through Administrative module Users Users.

Figure 5 - User management

In this module, by clicking Add user button, OWIS opens form for New User.

Figure 6 - Add new user form

Other than main user data, we choose the User group menu for specific user that we are inserting

using the drop-down menu. Based on the User Group, User has some access rights on system level

defined. For this tutorial we will create three users that will correspond to each User Group that we

already created.

After successful user creation, we now create specific procedures in the system. Again, for this

tutorial we will use procedure defined in Figure 1, but procedures can be as complicated and large as it

is required by organizational needs.

For the proper system configuration we need to create organizational units that are part of the

subject organization. Based on organizational rights users will be able to access specific system. For the

purpose of this tutorial we will create just one organizational unit that these users are part of. In

administrative module Dictionary Sectors we are able to define sectors and sector codes that are

specific for each sector in the organization.

Figure 7 - Sectors module

Next step in this process is creation of Departments that are directly related to sectors. In

administrative module Dictionary Departments we create Departments that are related to

Sectors table with many to one relation. We can have multiple departments in one sector.

Departments are very important since all user rights for creation of workflows and execution of

workflows depend in some part to its rights on department.

Figure 8 - Departments module

After creation of departments, we now need to define user rights on departments. In administrative

module Users User by departments we define user rights for specific organizational unit.

Figure 9 - User departments rights

Rights on organizational unit that can be assigned to user are:

Case listing – User’s right to see workflows for specific department. For this example assigned to all

users.

Case create – User’s right to create workflow for specific department. For the purpose of this

example we will assign this right to user on protocol.

Case read – User’s right to read workflow data. For this example assigned to all users.

Case edit – User’s right to edit main workflow data in the system. For the purpose of this example

we will assign these rights to protocol user only since he is also creator of workflow. This can be

assigned to specific users involved in workflow. Note: This right is defined for editing only main data

of the workflow not action or other data defined in the system.

Case delete – User’s right to delete specific workflow case. This right will be assigned to protocol

since that person needs this right for proper system functioning in case of error in workflow input.

Execute actions – this right is assigned to the user who has the rights to work on workflows for a

specific department. For purpose of this example we will assign this right to all users since they need

it to properly execute workflow.

Directory access, Document management administrator and Calendar access are properties that are

defined to users to see Departmental folders and calendars.

Classifications

For the purpose of this example we need to classify workflow so it has one of attributes which is

workflow classification. Workflow classification is attribute that is very important in managing user

right to access workflows or action types that are specific for workflows.

In administrative module Dictionary Classifications we can add, modify or delete specific

classification from the system. Each classification has its unique code that is defined and which

allows us to dynamically define workflow numbers or tags. For the purpose of this tutorial we will

create some dummy classification which can be Incoming documents.

Figure 10 - Classifications

After we created classifications, now we can move on with creating the procedure through the

Workflow designer.

Creating workflow through Workflow designer – frontend for procedure definition

Workflow designer is administrative module designed for simple and fast creation and

modification of workflow, which includes definition of statuses, actions and workflows.

Figure 11 – Workflow designer

Procedure definition and configuration

If we want to create new procedure in the system, we need to click on the button in

the bottom of the screen where system opens dialogue where we define name of the newly created

procedure. If we want to modify some existing procedure, we would select it from the drop down list in

the bottom of the screen.

Status definition and configuration

After selecting desired existing or new procedure we start process of workflow creation. During

process of workflow creation first we define statuses that one workflow can be in. It is important to

note that each procedure should start with the default status named Created. This

action is performed by simple drag and drop method. Next, by clicking and dragging

button system drops a new status each time this option is used and by clicking on the

status name administrators easily change the name of any status in the procedure. After all statuses are

defined, we approach to action definition.

Action definition and configuration

After all statuses are in place, we change tab and make sure that

button is selected. After that we draw the lines between statuses which

correspond to actions that can change status of workflow from one to another.

Figure 12 – Naming an action

After creation of action we define name for the action. After we defined all the statuses and

steps in the procedure we approach to the part where we define user groups that will be able to

execute specific parts of the procedure. This is performed through Workflow designer by selecting

desired action and clicking on button.

Figure 13 - User group action rights

After clicking on action rights, pop up window is opened where we define rights to specific user

group. Each user group can be delegated with Execute, Read, Write, Delete and View rights for specific

action type. After definition of user rights, by clicking button we exit dialogue pop up.

Specific procedure configurations

We can define specific classifications for each workflow, where administrators of the system are

able to set one or multiple classifications to appear when initiating specific procedure. This way we are

able to define additional data for each procedure or classification.

Definition of metadata

Metadata is defined through Form Server. Each Workflow can be attached with metadata

through different phases. We can define forms that can be attached to

- specific workflow classification,

- specific action type,

- specific action type in regards to classification;

All these settings are defined in administrative part of this document which focuses on Forms Server

mechanism.

Assigning user rights and security levels

Other than user group rights for executing action, there are several more levels of user rights in

the system, defined through administrative module, and directly associated with Workflow module.

- Departmental rights – Via administrator module it is specified to which organizational unit certain user has right to access. These rights are further differentiated to perform Workflow operations which include read, write, delete, modify, and execute action and access documents within that organizational unit. Each of these rights can be assigned to individual user.

Figure 11 - User department rights

Each user can be assigned for all the necessary rights based on the department they are working in. If the specific workflow is created for one apartment, and user does not have execute actions right defined on that department, that user will not be able to appear in forward able user list during workflow execution. Other than that we can limit specific user to access details about specific workflows through fine tuning of settings.

- Action type rights – Via administrator panel it is possible to allow execution of certain actions on the level of the user group. This approach enables streamlining of workflow with reduced possibility of error given the fact that delegation of cases and transfer between users is narrowed to only those that have the right to proceed with the case. All this is explained in detail in the part of workflow creation.

- Procedural rights – At the level of the user group it is possible to grant rights on certain workflow procedures. Once the right for certain workflow procedure is revoked from a user he/she is not able to perform actions that correspond to steps in certain workflow procedure

- Classification rights – Access to cases with certain case classification can be revoked from users at the level of user group from administrators modules

- Document rights – Users can be able to view certain case but not all of the documents within that case. If documents are properly identified, it can be possible to restrict access to these documents.

Disabling user in the system

One of the main tasks for everyday administrator of the system is creation and disabling user.

Steps for disabling user are as follows:

- If we want to disable user from the workflows we go to administrative menu Users User by

departments, where revoking user rights from all departments automatically disables user from

the workflows. User that is disabled this way will not be able to access workflow instances.

- User can be partially disabled by changing its user group or its user rights for specific steps in the

procedure through administrative menus for workflow configuration

- Other than this initial step in disabling user, we can also partially revoke user rights on

procedures, classifications or action types, where user can be