WorkMail: collaborative document workflowmanagement by email

Davide Gazze, Mariantonietta N. La Polla, Andrea Marchetti, MaurizioTesconi, Andrea Vivaldi

Institute of Informatics and TelematicsNational Research Council (CNR), Pisa, Italy

<firstname.surname@iit.cnr.it>

Abstract. Processing documents is a critical and crucial aspect for en-terprises. The management of documents involves several people and canbe a long and time-wasting process. We developed a document workflowengine based on email paradigm. Exploiting a web application, the sub-ject of the workflow, the document, can be sent as an email attachment.Our solution overcomes the current limitation in the use of DocumentWorkflow software, especially regarding user experience. With our sys-tem there is no need for users to learn how a new framework works.In addition, users with different roles have different customized view ofthe document. Moreover a suggest feature has been implemented; thesystem suggests a possible receiver for the document, depending on thedocument flow.

Keywords: Documental Workflow, Web Technologies, Web based cooperationtools, Office Automation, Information Management

1 Introduction

The problem of processing documents is a critical aspect in the enterprise pro-ductivity ([1],[2], [3], [4], [5] and [6]). The management of documents involvesdifferent actors with different roles, the possibility of decentralized working envi-ronment, different tasks and responsibilities. Enterprise operations can be viewedas a series of steps involving the filling out of a form representing the document,often in concurrent manner. It is possible to define all these kind of activities re-lated to documents as Document Workflow (DW). In general, a workflow is “theautomation of a business process, in whole or part, during which documents,information or tasks are passed from one participant to another for action, ac-cording to a set of procedural rules” [7]. With the term Document Workflow werefer to a particular workflow in which all activities are related to document’scompilation [1]. Therefore, a DW can be viewed as the automation and admin-istration of particular document procedures ([8], [2] and [6]). Through a DW,a document life-cycle is tracked and supervised continually and the documenttravels among agents who essentially carry out the pipeline receive process and

send activity. With these features, a DW can solve problems related to documentmanagement in enterprises.

The paper is structured as follows: Section 2 reports a brief State of the Artconcerning different types of Workflow Management System and a discussion ofthe limits of existing practices. Section 3 presents our solution with an exampleof application of WorkMail in a real case. Section 4 draws the conclusions anddiscusses future works.

2 State of the art

Over the past years different workflow management systems (WfMS) have beendeveloped, but as explained in [9] and in [10], they lack of a standardized back-ground theory, that can play the same role of relational algebra for databases.However, according to [11], it is possible to classify the modeling methods ofexisting WfMs as follows:

Structured and Ad-Hoc. In the structured model the information needed for thedefinition of the workflow can be retrieved from the analysis and the modelingof the real process. This is due to the fact that, this kind of process, never ornot often changes after its definition.However, in real cases, there are exceptions and some parameters cannot bedefined a priori: this is the key idea of the ad-hoc model, which has the samecharacteristics of structured model, but includes the treating of less repeatablesituations.

Document-centric or Process-centric. As the name suggests, Documents-centricWfMSs have as key factor the document and its circulation between people. Thedocument can be also images, like in the existing Imaging Processing Systems.On the other hand, Process-centric WfMSs consider business process as a series ofinterdependent steps. At each step, data are processed using specific applicationtools, invoked either by the user or by the system itself. Data produced at eachstep represent the input of the subsequents steps.

Email-based or Database-based. The email based WfMSs use email system formessage routing, data distributing and event notifying during the execution ofa process instance. These WfMSs are typically used by many low-end systems.Database-based WfMSs store all the data (including application data) neededin a DBMS. In these WfMS the instance execution is the process of retrievingand processing data stored in the DB.

Task-pushed or Goal-pulled. Task-pushed WfMSs execute activities in a processone-by-one. An activity is created only if the previous one is terminated. Af-ter all the activities have been completed, the process is considered completed.Task-pulled WfMS are usual implementation of most process-centric WfMSs.Goal-pulled WfMSs resolve the entire process as multiple interdependent exe-cutable steps that need to be performed in order to obtain a goal (the process).

Each step can be viewed as sub-goal. When all sub-goal are terminated, theprocess can be considered finished.

Nowadays there are many web-based tools for the definition of documentworkflow (often named Enterprise Content Management-ECM). ECM refers tosolutions that combine conventional tool for Content Management and web-based components and that performs traditional archive, document manage-ment and workflow functionalities [12]. As examples, we can mention Alfresco1

or Nuxeo Enterprise2: in these software documents can be shared or modifiedcooperatively, exploiting shared folders (like Google Drive folders). However, of-fered capabilities are too basic, in terms of supported workflow patterns anddesign, to serve specific and sophisticated needs. Concerning document work-flow system, not ECM solutions, an example is Doqui3, an Italian open sourceproject targeted to the public administration offices. Others examples are Cute-flow4, an open source workflow system that enables document circulation, andDocMGR5, a web-based Document Management System.

2.1 Limits of the Document Workflow Systems

As said in [13], the workflow system categorizes, formalizes and automates workthat often has a fluid and unpredictable nature. Many empirical studies by Joost-ens [14] relates workflow management to the organizational structure type de-fined by Mintzberg [15] stressing that, in addition to the positive impacts, thereare many possible negative aspects [13]. The nature of that includes rigid proce-dures, reduction of learning by employees (because the steps are pre-programmed),reduction of motivation of a worker (his work becomes more mechanical) and,finally, the underestimation of the importance of human communication. Produc-tion and administrative Workflow Management System are suitable for routinesituations [16], but not in the area of knowledge work. This because it is not pos-sible to define a precise flow beforehand and there is a need for communicationand collaboration between workers. In this case actors choose their next stepsone at time so it is very important to have a more flexible system. However,there are some works such as [17], that try to provide an environment support-ing an advanced form of coordination in a cooperative environment, introducingflexible execution.

3 Document workflow by mail - WorkMail

To design an efficient DW engine we started from some key aspects: (i) weneeded a simple tool for collaborative document elaboration; (ii) one of themost used tool in an enterprise environment is the email. Emails are very useful

1 http://www.alfresco.com2 http://www.nuxeo.com3 http://www.doqui.it4 http://www.cuteflow.org5 http://www.docmgr.org

in organization environment due to several reasons: users can provide quickanswers, easily communicate with each other (without physically meeting), ordistribute documents and information in an easy and paperless way. But theemail paradigm is not sufficient to manage a DW. Despite these advantages, wehad to take in account some drawbacks: emails are impersonal and could oftenbe misunderstood; answering complicated questions could be a time-consumingtask. Moreover, attachments cannot be modified after they are sent. We use theparadigm of email as base for a new approach for a document workflow system:WorkMail.

WorkMail is a web-based application that tries to combine the potential ofa DW with the flexibility of an email; in this way we exploited the advantagesof the paradigm and overcame problems related to the above-mentioned draw-backs.The document and his modification are key aspects of WorkMail. In our solution,a document is used as attachment of an email that moves from one person toanother one. In WorkMail the document is a special attachment: it is composedby different editable fields. Depending on his role, different users can visualizeand modify, at each step, different fields of the document. This represents oneof the most valuable advantages of using WorkMail: the attachment is unique.WorkMail is developed as a transparent system: this means that, if a user mod-ifies and re-accesses a document that was further modified by other users alongthe workflow he will be able to see the new modifications. However, it is possibleto adapt the system for situations in which a user can visualize only an interme-diate version of the document and he is forbidden to see further versions of thedocument that is modified later in the workflow. To modify a document, it isnot necessary to create a new one and attach the revised version as new attach-ment, but users can modify the existing one. Figure 1 shows the base concept ofWorkMail.In WorkMail users are important also for the role played in the company orin the organization. Every enterprise, organization or company have an organi-zation chart that provides information about employees and their assignmentand responsibilities. Typically, these distinctions are according to the consideredoffice: for example, employees in the administrative office have different responsi-bilities from human resource staff. Furthermore, in the same staff it is possible todistinguish between directors, employees, assistants, etc. We use these differencesbetween users to handle the document and his fields.

3.1 Architecture and Implementation

In order to implement our solution, we have designed the architecture shown inFigure 2.The core of the architecture is the WorkMail engine that manages all the actionsinvolving the shared document, such as the definition of the permission set.The Document Manager component creates the template of documents and isused to manage the lifecycle of a single document (create, read, update anddelete). The User Role Access Control enables managing the access to the system

Fig. 1. Conceptual Idea.

Fig. 2. WorkMail architecture.

according to user and his roles. The Template is used to adapt the view of theentire document, according to the user’s role. The Access Description Path allowsor denies dynamically the access to a particular field of a document based ondifferent parameters:

– user;– user’s role;– type of document;– step of document workflow.

The Workflow Description is a set of rules that describes the document workflowin term of users, roles and document.WorkMail has been developed using open source technologies like Apache, PHPand MySQL. We chose Drupal6 as content management framework for its high

6 http://drupal.org

modularity. Figure 3 shows the implementation of WorkMail. CCK is a moduleof Drupal that enables the creation of any kind of structured document.

Fig. 3. WorkMail implementation.

We model every document in the workflow system as a new content type.Every content type is fully configurable so we can add or remove fields, set thetype of these fields and set different permissions per fields in the same document.Moreover, fields and content types have own properties, like information aboutthe author and the timestamps of creation and modification. To categorize theemail content type the Drupal’s Taxonomy is used. Users and roles are managedby Drupal core. Every user can have one or more roles and the permission settingis connected directly with a role. In this way, if a certain user performs an actionwe need to assign a specific permission to a role and then the role to the user.The first fundamental concept of the engine is the shared document to fill out(the attachment of the workmail). An instance of content type is called node.The attachment node is unique in the whole document workflow, so users editthe same instance of the document collaboratively; each user edits only his ownpart of the document. To implement this feature we need a container to deliverthe shared document between users, so another content type has been created tocontain the attachment. This new content type (workmail) has as many instancesas the number of users involved and performs the role of the classic email. Theworkmail content type contains data about the recipients, the object, the bodyand other flags indicating if an email is read or not. When a user creates anemail with a document attached the engine creates:

– workmail content types for each user in the recipient;– a single attachment content type.

A user creates new workmail content types also when he replies or forwardsthe email attachment. To make document’s editing really cooperative, differentpermissions to different roles can be assigned to every single field in the documentconfiguration. Every attachment node has not a prefixed permission setting,

because in our case the flow is dynamic and not static. So the engine is capableof calculating the right permission at runtime, depending on the content of therecipient field. We only need to preset generic roles with generic permissions onthe document’s field; the engine dynamically associates users to these genericroles during the document flow. The User Interface looks like a web-email client(like GMail, Yahoo mail, Microsoft mail, etc.).While the InBox and SentBox are similar to those of standard email clients,the Compose Tab is different. Differently from standard email clients, a sectioncontaining suggested attachments is presented. When a user chooses the type ofthe attachment, the system shows an instance of the document that the user canfill out. The visibility of each field of the document and his proprieties (readable,editable) depend on the user and on the step of the flow. After saving, the usercan see the attachment in the compose area.Optionally the user can specify one or more tags on the field TAGS enablingthe categorization of emails in folders. A vocabulary of tags is associated to thecontent type. For instance, if a user starts a Travel Request, as in our example ofapplication (see Section 3.2 for more details), he must click on the correspondinglabel.Moreover, for what concerns the ‘To’ field, differently from emails, the receivercan be either another user or role: this can be useful when a document has toreach a group of users with a specific role such as the administrative office. Evenif the receiver is a role, the system will resolve the role in relation to the sender.

One of the innovative features of WorkMail is the suggestion method. Whena user has to send a document to someone, the system suggests a list of possiblereceivers; this information is stored statically in the system database (see Section4 for further details). In case of wrong recipient, users can manually change theemail; this ability simplifies human actions, so a user can decide to follow theproposed flow or change it dynamically.

3.2 Example of application

To illustrate the usefulness of our solution, we propose an example of usage.We consider as case study the process of a travel request (T.R.) in our researchinstitute, the Institute of Informatics and Telematics of National Council ofResearch, Italy. In our scenario an employee that has to travel for a conferenceor a meeting, has to start a procedure of travel request. This procedure involves:

– the employee’s manager for a preliminary authorization;– the administration office for what concerns the budget effort;– the director for the final authorization;– the human resource office for closing the procedure.

The flow related to this procedure is summarized in Figure 4. In each phase ofthe process, users have to fill a travel request document, providing different kindsof information. The key aspect is that some of these information are known onlyby specific users with specific role. For instance, the information about budget

Fig. 4. Travel Request flow.

are provided by the administration office because these are information that anemployee does not know. This is a typical example of collaborative editing ofa document. If the same procedure was performed using the standard email, ateach step, the user had to

– read the current version of the document;– create a new document with the already known information;– fill out the fields of the document needed at this step;– attach the new version of the document;– send the email at the next user.

4 Conclusion and Future works

In this paper we presented WorkMail, a new approach for document workflowsystem which overcomes the limitations of the current document workflow soft-ware. The benefit that our model includes is twofold. From a user’s point ofview, the use of the email paradigm is helpful to learn using the document work-flow system. Due to the fact that we exploit the email paradigm, users can useWorkMail easily, without learning anything about the functioning of the system.They do not need to learn how to use a new document workflow system but cancontinue to send emails with attached documents as usual; therefore, startingto use WorkMail is not a wasting time process. From a system’s point of view,WorkMail encourages people for collaboration and it is exception free; this isdue to the fact that the user will manage the flow, choosing the receiver of thedocument at each step. Moreover, we want there is the advantage of using thissystem as a paperless way to manage documents.

Even if our approach can solve different problems, many technical aspectscan be improved and some new features can be developed. First of all, it shouldbe possible to define an end state for the document: this is the case of documentsthat are completely compiled. It is also possible to extend the search area forfiltering a workmail according to sender user, type of attachment, data andtags. It should be possible to add a feature for digital signature: in this way,documents generated by WorkMail can get legal effect. A very interesting andmost innovative feature that we are planning to implement is a smart suggestionmechanism. This mechanism will suggest to the user, for each kind of documentand for each step of the flow, who could be the receiver of the email. We willperform a statistical analysis of different information, like involved users, roles,type of attachments and step of the flow, to determine the frequency of therelationship between a sender and receiver, regarding a particular attachment.Obviously, the engine will need some time to learn the flow and then the receiversto be suggested, so it will be possible to provide a learning mode for the firsttime. In case of significant changes of a flow, it is possible to restart the learningprocess for specific type of attachments.

References

1. Marchetti, A., Tesconi, M., Minutoli, S.: Xflow: An xml-based document-centricworkflow. In Ngu, A., Kitsuregawa, M., Neuhold, E., Chung, J.Y., Sheng, Q., eds.:Web Information Systems Engineering WISE 2005. Volume 3806 of Lecture Notesin Computer Science. Springer Berlin / Heidelberg 290–303

2. Krishnan, R., Munaga, L., Karlapalem, K.: Xdoc-wfms: A framework for documentcentric workflow management system

3. Kappel, G., Rausch-Schott, S., Reich, S., Retschitzegger, W.: Hypermedia doc-ument and workflow management based on active object-oriented databases. In:System Sciences, 1997, Proceedings of the Thirtieth Hawaii International Confer-ence on. Volume 4. (jan 1997) 377 –386 vol.4

4. Baresi, L., Casati, F., Castano, S., Fugini, M.G., Mirbel, I., Pernici, B.: Wideworkflow development methodology. SIGSOFT Softw. Eng. Notes 24(2) (March1999) 19–28

5. Casati, F., Grazia Fugini, M., Mirbel, I., Pernici, B.: Wires: A methodologyfor developing workflow applications. Requirements Engineering 7 (2002) 73–10610.1007/s007660200006.

6. Georgakopoulos, D., Hornick, M., Sheth, A.: An overview of workflow management:From process modeling to workflow automation infrastructure. Distributed andParallel Databases 3 (1995) 119–153 10.1007/BF01277643.

7. Buhler, P.A., Vidal, J.M.: Towards adaptive workflow enactment using multiagentsystems. Information Technology and Management 6 (2005) 61–87 10.1007/s10799-004-7775-2.

8. Marchetti, A., Minutoli, S., Lazzareschi, P., Martinelli, M.: System for managingdocuments in a step by step process. In: XML World Euro Edition. (2001)

9. Haller, A., Oren, E., Petkov, S.: Survey of workflow management systems (2005)10. Aalst, V.D.: The application of petri nets to workflow management (1998)11. Meilin, S., Guangxin, Y., Yong, X., Shangguang, W.: Workflow management sys-

tems: A survey. In: in Proceedings of IEEE International Conference on Commu-nication Technology. (1998)

12. U., U.K.: Definitions, scope, architecture, components and ecm-suites in english,french, and german. (2006)

13. Suchman, W.: At workflow automation,overview and research issue14. Joosten S, Aussems G, D.M.H.R.M.E.: An empirical study of the practice of

workflow management (1994)15. Mintzberg, H.: Structure in fives: designing effective organizations (1983)16. Stohr, E.A., Zhao, J.L.: Workflow automation: Overview and research issues. In-

formation Systems Frontiers 3(3) (September 2001) 281–29617. Grigori, D., Charoy, F., Godart, C.: Flexible data management and execution

to support cooperative workflow: the coo approach. In: Cooperative DatabaseSystems for Advanced Applications, 2001. CODAS 2001. The Proceedings of theThird International Symposium on. (2001)