A workflow defines a series of tasks within an organization to produce a final outcome. Workflows allow for business process formalization and management. A collaborative workgroup computing application allows different workflows to be defined for different types of jobs. For example, in a publishing setting, a document may be automatically routed from writer to editor to proofreader to production. At each stage in the workflow, one individual or group is responsible for a specific task. Once the task is complete, the workflow application ensures that the individuals responsible for the next task are notified and receive the data needed to execute the next stage of the process.
A workflow schedule authoring tool enables a user to author a workflow by arranging building blocks in a particular order. Building blocks may correspond to events, conditions, or actions. Each building block is associated with source code that defines an action to be taken when the building block is executed. The order of the building blocks determines the workflow schedule process that will be performed when the workflow schedule is executed by a workflow execution engine on a server computer. Some building blocks may be predefined for commonly used actions. Other building blocks may be customized to execute a specific function or to provide a solution to a unique problem. The building blocks simplify workflow schedule authoring because the user does not need to write any code.
Previous workflow schedule authoring tools provide significant functionality for modeling a wide variety of real-world business processes. However, the previous workflow authoring tools provide limited functionality for defining and modeling human workflow-specific scenarios, particularly task processes in the area of approval and feedback collection. In previous workflow authoring tools, much of the task processes that users would like to model is hidden within a generic task assignment object. As an example, in some scenarios where time is of the essence, rejection is automatic if a document is not approved after a certain amount of time has passed. This type of logic cannot be defined utilizing previous workflow schedule authoring tools. While some workflow authoring tools do provide predefined building blocks for approval and feedback tasks, these predefined building blocks are not customizable. As a result, the predefined building blocks are unusable if they do not perform the desired workflow.
It is with respect to these considerations and others that the disclosure made herein is provided.
Concepts and technologies are provided herein for defining and implementing custom task processes. Through the embodiments presented herein, facilities are provided for declaratively defining a task process workflow action that permits flexible modeling of approval and feedback collection processes without writing program code. The embodiments presented herein also provide functionality for customizing predefined building blocks for approval and feedback tasks to more closely model actual task processes within an organization.
According to one aspect presented herein, a workflow schedule authoring tool (referred to herein as the “authoring tool”) is provided that includes a user interface and associated functionality for creating workflow schedules by arranging building blocks, called workflow actions, in a particular order. Workflow actions may correspond to events that trigger the workflow, effects the workflow should have on a collaborative workflow group application system, or conditional logic processing logic that determines the control of the workflow. The authoring tool is executed at a client computer and workflow schedules created at the client computer are transmitted to a server computer for execution.
According to one aspect, the authoring tool provides a user interface for defining a custom task process action within a workflow. The custom task process may correspond to an approval process, a feedback process, or a to-do process. An approval process is a process that involves participants approving a document or other item, a feedback process is a process that involves participants providing feedback on a document or other item, and a to-do process is a process by which a task is assigned to one or more participants. The technologies presented herein can be utilized to flexibly define and implement each of these process types and others.
According to other aspects, the user interface provided by the authoring tool includes functionality for defining a task action for the custom task process that encompasses one or more task instances. New workflow logic can be applied to both the task action and the encompassed task instances. For instance, in one embodiment, the user interface can be utilized to define process behaviors and completion conditions that apply to the task action. Process behaviors are event handlers that execute in response to an event occurring in the context of the task action. Completion conditions are event handlers that execute in response to the completion of a task instance encompassed by a task action.
According to other aspects, the user interface provided by the authoring tool also includes functionality for defining the task instances encompassed by a task action. For instance, one or more task behaviors may be defined for each task instance. Task behaviors are event handlers that execute in response to an event occurring in the context of a task instance. The user interface may also be utilized to define form fields for receiving data from a participant in the custom task process, task outcomes to be received from a participant in the custom task process, and task settings defining whether a participant can delegate a task instance or request a change of a task instance. Once a task process has been defined using the authoring tool, a workflow that includes the task process is submitted to a collaborative application for execution. The defined task action and task instances are executed by the collaborative application to implement the defined task process. Through the execution of the task process, assignments are made to the defined participants, and additional workflows, actions, and behaviors may be triggered and executed based upon the defined task action and task instances.
The above-described subject matter may also be implemented as a computer-controlled apparatus, a computer process, a computing system, or as an article of manufacture such as a computer-readable medium. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
The following detailed description is directed toward technologies for defining and implementing custom task processes. As will be described in greater detail herein, a workflow schedule authoring tool is provided that allows a task process workflow action to be defined that enables flexible modeling of approval and feedback collection processes. In this way, approval and feedback tasks can be defined and implemented that closely model the actual task processes utilized within an organization. Additional details regarding the concepts and technologies presented herein are disclosed below with respect to
While the subject matter described herein is presented in the general context of program modules that execute in conjunction with the execution of an operating system and application programs on a computer system, those skilled in the art will recognize that other implementations may be performed in combination with other types of program modules. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the subject matter described herein may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.
The subject matter presented herein is also described as being practiced in a distributed computing environment where tasks are performed by remote processing devices that are linked through a communications network and wherein program modules may be located in both local and remote memory storage devices. It should be appreciated, however, that the implementations described herein may also be utilized in conjunction with stand-alone computer systems and other types of computing devices. It should also be appreciated that although reference is made herein to the Internet, the embodiments presented herein may be utilized with any type of local area network (“LAN”) or wide area network (“WAN”).
In the following detailed description, references are made to the accompanying drawings that form a part hereof, and which are shown by way of illustration specific embodiments or examples. Referring now to the drawings, in which like numerals represent like elements through the several figures, aspects of a computing system and methodology for defining custom task processes will be described. In particular,
As shown in
According to one implementation, the client computer 102 also includes a Web browser program (referred to herein as a “browser”) 118. The browser 118 is operative to request, receive, and display information pages, such as Web pages, from the server computer 104. In particular, the browser 118 is operative to establish a connection to a collaborative application 124 executing on the server computer 104. Through the connection, the browser 118 may request information pages provided by the collaborative application 124. The collaborative application 124 is a computer software program that enables multiple users to collaborate on documents, projects, tasks, and other matters.
The collaborative application 124 also supports workflow processes. In general, a workflow is an abstraction of how work flows through a business process. This abstract notion of workflow has been modeled in computer programs and computer software for supporting workflow through a business process has become known as “workflow.” Hereinafter, the term workflow refers to such a software model (i.e., a software program that supports the modeling of how work flows through a business process). It should be appreciated, that the implementations described herein may be utilized with any type of computer system that supports workflow processes.
In order to support the provision of workflow, in one implementation the server computer 104 includes the .NET FRAMEWORK 3.5 122 from MICROSOFT CORPORATION. The .NET FRAMEWORK 3.5 122 is a framework for building, deploying, and running Web services and other applications. The .NET FRAMEWORK 3.5 122 includes the WINDOWS WORKFLOW FOUNDATION (“WF”) 120. The WF 120 is a programming model, engine, and tools for building and executing workflow enabled applications. The WF 120 allows a developer to more easily model and support business processes. Details regarding the .NET FRAMEWORK 3.5 122 and the WF 120 are publicly available from the MICROSOFT DEVELOPERS NETWORK (“MSDN”) and from other sources.
The WF 120 includes a workflow engine for instantiating and executing instances of workflows created using authoring tools, such as the workflow authoring tool 110. The workflow engine runs a workflow by advancing the workflow through a workflow schedule 112. The workflow schedule 112 is a data structure containing data that identifies the workflow actions 116 that should be executed as a part of the workflow, workflow logic, and various metadata. As will be described in greater detail below, the workflow authoring tool 110 may be utilized to author the workflow schedule 112. The workflow schedule 112 may then be transmitted to the server computer 104 for execution as a part of the collaborative services provided by the collaboration application 124. Additional details regarding this process are provided below.
As shown in
As discussed briefly above, the client computer 102 is operative to execute a workflow authoring tool 110. The authoring tool 110 is an application program that provides facilities for visually creating workflows that can be executed by the collaborative application 124. In particular, through the facilities provided by the authoring tool 110, a user can graphically create a workflow schedule 112. The workflow schedule 112 references various workflow actions 116 that are the building blocks that perform the actual processing for the various steps of the workflow. The workflow actions 116 are executable components that may correspond to events, conditions, or actions within a workflow process. As shown in
In one implementation, the server computer 104 stores workflow schedules 112 in a versioned document library 128 provided by the collaborative application 124. Once the workflow schedule 112 has been stored in the document library 128, the workflow schedule 112 may be instantiated and executed. This may occur, for instance, in response to the occurrence of an event or in response to a manual request to execute the workflow schedule 112. When the workflow schedule 112 is instantiated, the workflow actions 116 are utilized to perform the actual processing for the workflow.
According to aspects presented herein, the authoring tool 110 provides a user interface for defining a custom task process action within a workflow. In embodiments, the custom task process corresponds to an approval process, a feedback process, or a to-do process. Although the examples presented herein primarily describe the creation of an approval task process, the technologies presented herein can be utilized to flexibly define and implement each of these process types and others. Additional details regarding the operation of the authoring tool 110 and the collaborative application 124 for modeling and executing a custom task process are provided below with respect to
Turning now to
In one embodiment, the custom task process action is defined by a task action 202 and one or more task instances 204A-204N. The task action 202 represents the overall custom task process action and the task instances 204A-204N represent individual activities occurring within the custom task process action. As will be described in greater detail below, through the use of the authoring tool 110 a user can define workflow logic that applies to both the task action 202 and to the task instances 204A-204N. For instance, through the authoring tool 110 provided herein, a user can define process behaviors 206 and completion conditions 208 that apply to the task action 202. The process behaviors 206 represent event handlers that execute in response to an event occurring in the context of the task action 202. The completion conditions 208 represent event handlers that execute in response to the completion of one of the task instances 204A-204N encompassed by the task action 202.
In the embodiments presented herein, a user may also utilize the authoring tool 110 to define task behaviors 210 and task outcomes 212 for each of the task instances 204A-204N. The task behaviors 210 represent event handlers that are executed in response to an event occurring in the context of one of the task instances 204A-204N. The task outcomes 212 define one or more outcomes for a task instance 204A-204N that are to be received from a participant in the custom task process. As will also be discussed in greater detail below, the authoring tool 110 provides functionality for defining one or more form fields that are utilized to receive data from participants in the custom task process. For instance, an e-mail message may be transmitted to a participant that contains the specified form fields for collecting data from the participant. Alternately, an editing application, such as a word processor or spreadsheet application, may expose the form fields for completion by a user that is viewing or editing a document that has a workflow task associated with it. Other settings for the custom task process may also specified utilizing the authoring tool 110, such as settings defining whether a participant can delegate one of the task instances 204A-204N to another participant or request a change of a task instance. Additional details regarding the processes provided herein for defining and executing the task action 202 and the task instances 204A-204N are provided below with respect to
Referring now to
The routine 300 shown in
Once the “on approval started” activity has been executed, the routine 300 continues to operation 304 where the task instances 204A-204N are instantiated. The routine 350 illustrates the various activities executed in connection with the task instances 204A-204N. In particular, the routine 350 begins at operation 352 where an “on task assigned” activity is executed for each of the task instances 204A-204N. This activity executes each time a task instance 204A-204N is about to be created. The routine 350 then continues to operation 354, where a “wait for task to complete” activity is executed. This activity waits for certain predefined conditions to occur that indicate that a task instance 204A-204N has been completed. When this occurs, the routine 350 continues to operation 356 where the “execute on task completed” activity is executed. This activity is executed each time one of the task instances 204A-204N have completed executing. From operation 356, the routine 350 proceeds to operation 306 of the routine 300.
At operation 306, a “check exit conditions” activity is executed within the context of the task action 202. This activity determines whether all of the conditions for completion of the task action 202 have been satisfied. If these conditions have not been satisfied, the routine 300 returns to operation 304, described above, where execution of the task instances 204A-204N continue. If, however, all of the exit conditions for the completion of the task action 202 have been satisfied, the routine 300 proceeds from operation 306 to operation 308. At operation 308, a “on approval completed” activity is performed. This activity is performed each time a task action 202 has been completed. The routine 300 then proceeds from operation 308 to operation 310.
It should be appreciated that, through the embodiments presented herein, a user can customize the execution process illustrated in
Referring now to
The completion conditions section 410 includes user interface controls for defining the completion conditions 208 discussed above with reference to
The section 406 includes a task behaviors section 412, a task form field section 418, a task outcomes section 416, and settings section 414. The task behaviors section 412 provides user interface controls for defining the task behaviors 210 discussed above with reference to
The task form fields section 418 includes user interface controls for defining one or more form fields for receiving data from a recipient of one of the task instances 204A-204N. Details regarding the contents and use of the task form fields section 418 are provided below with reference to
The task outcomes section 416 includes user interface controls for defining one or more outcomes for the task instances 204A-204N that are received from the participants in the custom task process. According to the embodiments presented herein, there are two pieces of work that a task instance 204A-204N can capture from a participant. One type of work that can be captured is data via the form fields specified for the task. The other type of data is outcomes captured via user interface buttons shown to the participants. For instance, through the selection of user interface controls, the user may be able to indicate whether a document is approved or rejected. Because, however, not all tasks are defined by an approval or rejection outcome, users are permitted through the task outcomes section 416 to define the outcomes they desire for their particular tasks. Additional details regarding the form and use of the task outcomes sections 416 are provided below with respect to
Referring now to
If the user interface control 502 is selected, the user interface 402C shown in
Referring now to
The user interface 420F, shown in
Referring now to
Through the use of the task behaviors section 412, task behaviors may also be added, deleted, or edited. The user interface 4021 shown in
Referring now to
Turning now to
The task outcome section 416 includes items 902A and 906 corresponding to the approved and rejected tasks, respectively, and defines buttons corresponding to those outcomes. The user interface control 901 may be selected to add a new outcome. In response to such a selection, the user interface 402L shown in
Turning now to
Referring now to
The mass storage device 1110 is connected to the CPU 1102 through a mass storage controller (not shown) connected to the bus 1104. The mass storage device 1110 and its associated computer-readable media provide non-volatile storage for the computer 1100. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed by the computer 1100.
By way of example, and not limitation, computer-readable media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. For example, computer-readable media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks (“DVD”), HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer 1100.
According to various embodiments, the computer 1100 may operate in a networked environment using logical connections to remote computers through a network 106, such as the Internet. The computer 1100 may connect to the network 106 through a network interface unit 1106 connected to the bus 1104. It should be appreciated that the network interface unit 1106 may also be utilized to connect to other types of networks and remote computer systems. The computer 1100 may also include an input/output controller 1112 for receiving and processing input from a number of other devices, including a keyboard, mouse, or electronic stylus (not shown in
As mentioned briefly above, a number of program modules and data files may be stored in the mass storage device 1110 and RAM 1114 of the computer 1100, including an operating system 108 suitable for controlling the operation of a networked desktop or server computer, such as the WINDOWS XP operating system from MICROSOFT CORPORATION of Redmond, Wash., or the WINDOWS VISTA operating system, also from MICROSOFT CORPORATION. The mass storage device 1110 and RAM 1114 may also store one or more program modules. In particular, the mass storage device 1110 and the RAM 1114 may store the browser 118, the collaborative application 124, and the other program modules described above. Other program modules not illustrated in
Based on the foregoing, it should be appreciated that technologies for defining and implementing custom task processes are provided herein. Although the subject matter presented herein has been described in language specific to computer structural features, methodological acts, and computer readable media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features, acts, or media described herein. Rather, the specific features, acts and mediums are disclosed as example forms of implementing the claims.
The subject matter described above is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter described herein without following the example embodiments and applications illustrated and described, and without departing from the true spirit and scope of the present invention, which is set forth in the following claims.