According to the workflow management coalition workflow is defined as:
"The automation of a business process, in whole or part, during which
documents, information or tasks are passed from one participant to
another for action, according to a set of procedural rules."
In the real world workflows are rarely "simple" and are usually made up of several individual and logical steps each of which are known as an activity. These activities can have human involvement or might just be a piece of work a machine is responsible for. The workflows themselves will involve both human and system involvement and will also involve various branching, splitting and joining of the numerous paths taken in a process. Don't be scared away, automating and managing a work process can provide huge returns in efficiencies, and will drive process improvement on a regular basis.
What is Microsoft doing in Workflow?
For developers, and ISV's Microsoft has introduced Windows Workflow Foundation as part of the .Net framework version 3 Windows Workflow Foundation a programming model/ framework for building workflows into your applications. The goal of WF is to provide a general framework that supports workflow, and make it a standard part of the Windows environment.
Microsoft Office SharePoint Server (MOSS)
The office team has seen a significant advantage in leveraging WF and hosting it inside of the SharePoint process to facilitate new functionality. For the 2007 release of SharePoint,(MOSS) Microsoft had a goal of providing an infrastructure that would drive work processes around what SharePoint does best: share and collaborate on documents. With this in mind you will see that there was a focus on document-centric workflows, processes that a particular document needs to go through during its lifecycle, such as being reviewed and edited or being approved for publication. With SharePoint in 2007 you can attach and run a process directly on a SharePoint document or list item. Companies will begin to evaluate MOSS both for its tremendous out of the box web capabilities, as well as for some workflow capability newly introduced into the latest 2007 version. Microsoft has heard the plea of its customer base and implemented workflow into the SharePoint platform. Essentially what the office team has done is built on the work done by the Workflow Foundation team and extended it as well as provided a host process for it. So not only do you have some out of the box workflow, if you have the development skills to do so, you also have the ability to code your own workflows utilizing WF and deploy them to the SharePoint server leveraging its host process.
Microsoft has built and is hosting some common workflows that will be shipping with MOSS, these workflows are easily configured and usable upon installation of Moss. We will touch more on these in a bit.
SharePoint Designer(SPD), will be released as part of the Office suite of products replacing the long standing FrontPage as the web designer. SPD can be used to create workflows that will be hosted in MOSS. Again more on this functionality and what to expect later.
The office 2007 client supports and integrates with workflow right out of the box. Providing a somewhat seamless workflow interaction ability with the workflows that run in your MOSS deployment. This is a fantastic ability that will greatly increase the use of and success of workflows being deployed in a Moss environment.
Before you start to make a decision on where workflow and MOSS fit into your organization you need to figure out what your true needs are,
- How complex are your workflows?
- Who will be building these workflows?
- Where will your data live?
- How much detail do I need in auditing, and reporting?
- What interfaces do I need?
Without knowing the answers to all of these you will be unable to make a valid decision and may spend valuable time and resources going down a path that will not end with the result you desire. It is worth the time to sit-down with the stake holders now and figure out what your real needs are longer term and choose the right tool for the right job.
If you want a process based effort to succeed you must think about your users first.
- How do your users work?
- What tools do my users use? (IE, MySites, SharePoint, Outlook, LOB App)
- How do my users get their information?
- How do my users do their processes now?
Keeping these in mind while building a process or application will dramatically increase the adoption and success rate of your effort. Try and force users to do it differently or throw a cultural curve ball at them and you are asking for users to find a way to bypass this new and more efficient way of doing things.
So the questions that get asked over and over again is what should I be looking to do in SharePoint either out of the box or though the SharePoint designer, and when am I going to either have to breakout Visual Studio and start writing custom code, or look to the ISV community for a more extensive workflow solution. How do I evaluate what it can do for me and at what point am I going to start building and supporting the code.
Let start by walking through some evaluation criteria.
1. When I think about my workflow what interfaces and interactions am I looking to use.
Basic WebPages?
InfoPath forms or InfoPath forms rendered through the new Forms server?
Do I need to solely use the interfaces provided through the Office clients?
These amount to some serious decision criteria for several reasons. From a probability of success stand point, think about which interfaces are best for your users. From a technical standpoint if I am building workflow through SPD my only choice is to use the ASP.net forms that SPD generates for me when building out the workflow. My ability to customize or re-host these forms is limited. The OOB workflows however do use InfoPath forms , and can use the rich features provided through the office clients if I am using Office 2007, which provides a very attractive option if my workflow needs are simple. However if I am like most organizations who sees deploying office 2007 as a more distant goal my options can be more limited. Thus I am left looking to building the workflow using Workflow Foundation.
2. Where does your data live?
This is perhaps the most important question in this decision process. Quite honestly if the answer is not SharePoint you are in most cases going to do some significant coding. Once you have determined this now you have to consider whether, you will write your own host process or will you be able to leverage the integrated functionally given in MOSS. In this scenario the answer is the same. If my data does not live in SharePoint you are going to be better served by building your own or buying one.
3. When you think about your workflow needs what other systems are going to be involved.
a. If you are integrating into other systems such as ERP, CRM or other back end applications, you are going to have to breakout Visual Studio and start writing custom code, or look to the ISV community for a more extensive workflow solution, as there is no ability either through the OOB workflows nor the SPD interface to interact with backend systems in a meaningful way. MS does allow some data to be surfaced through the use of the BDC which will provide me with a read only list type copy of back end data. You do have the ability to take this data if exposed in your site and leverage it in a workflow, however this data is read only.
4. What type of business logic will you need to have to run or determine the flow of your processes?
a. Complex if this then that.
b. Simple and straight forward.
c. How much conditional branching or parallel processing would be involved?
With regards to the OOB workflows your ability to add any type of business logic, or branching and converging is non-existent. This capability was not their focus when building them. Also be aware that you take the out of the box workflows and add to them. So you move on to SPD, and while SPD does support the base concept of If else type branching if you need to leverage complex business logic you are most likely going to be going back and developing these with custom code via the Visual Studio interface. However if your workflows do not contain this requirement and the logic behind them is straight forward the OOB or SPD type workflows will be able to provide good value.
In the same vein you need to think about how this business logic is determined
Is it based on data that is a critical part of the workflow Such as meta data associated with a document or based on user input values. Both of these really bode well for using MOSS and SPD etc. However many organizations base most of their workflows on External Data and as stated previously this makes your effort more difficult.
5. What other key items/features do you need to make your workflow efforts more successful?
a. Escalations
Escalating a workflow either at a individual step or as a whole is limited to sending email reminders at a given point in time. This may work great for some groups whose workflows are not tied to an SLA, or other critical functions. However you may see a need to develop in more advanced escalations such as automatically redirecting the workflow to a different user or group of users, or taking some kind of custom action. If this is the case for your organization you will be back at a building or buying.
b. Time zones
Does your workflow require accommodation of people in different time zones? This mainly takes on additional importance with time or business processes. These should be less common in the SharePoint world but will probably still exist. I am currently not aware of any way to accommodate this so if this is an area of importance to you, creating your own workflows and possibly host is going to be a consideration.
6. What level of auditing and reporting is necessary to effectively manage and improve processes?
a. How much do you need to know about the process, who was involved and how do you need to track and store progress. Once you store it how long do you need to keep it? The level of reporting that is involved with both the OOB workflows as well as those created with SPD, are great for their purpose. It will tell me when a process started, who was involved and other basic information. Advanced levels of reporting are not available in the OOB workflows and do not provide a great deal beyond what you would find in SPD. Other methods should be considered if this is an area of great importance.
b. Security
Microsoft has done a great job in increasing the granularity and flexibility of the security model in SharePoint. This has obviously been extended to include workflows and the various applications you build on top of that platform. However there is a part of workflow in its management of tasks that does have a shared aspect. In high security environments this may be a concern.
7. Does my SharePoint site design and architecture match a design necessary to meet my workflow needs?
a. Since workflows are site bound are the workflows that you will be creating isolated enough to meet this requirement, or do I need to have workflow actions that cross site, application, and or portal boundaries. If this is the case, you will need to leverage the Visual Studio interface to make this happen.
Lets look further into how we create and use MOSS workflow.
SharePoint Designer and Workflow
So what can you do with SPD? Workflows are created by specifying conditions and actions through what can best be described as an outlook rules type design interface. For workflow I can check for the presence of certain conditions and then take actions either based on those conditions or without condition. SPD does have the ability to create multiple steps, with different conditions, and actions including support for such things as "If then else" type logic.
Benefits:
1. Workflows can be created very quickly
2. Deployments are not complex and can be executed quickly
3. Can be created by non development focused people
4. Risks from deployments are minimal because of the trusted list of conditions and actions.
5. Created from a finite list of conditions and actions, trusted by the system and its administrators, making the creation of workflow easier.
Drawbacks and limitations
1. Actions are site bound to the site they are run from.
2. Still need to have IT skill sets, cannot be done by normal Business Users
3. Limited support for advanced complexity and scope in building out workflow.
4. No re-use capability, is authored against a specific list of document library cannot then be used again on another list.
5. No ability to modify in flight.
6. Must use ASPX pages.
7. Limited customizability of these ASPX forms.
8. Cannot be accessed directly from Office 2007 applications, must be accessed with a web browser other than through email notifications etc.
Figure 1
Some conditions to check for are as follows:
1. With Specifics words in the title or other fields
2. Modified (either in a specific time window or by a person)
3. Created by or in a specific time frame
4. File type
5. File size
6. ADVANCED Condition(Custom condition)
Figure 2
The action tasks for example are as follows:
1. Create task
2. Update task
3. Delete task
4. Send email
5. Prompt for values
6. Change Item Status
As a developer you also have the ability to publish your own custom actions through the use of Visual Studio and the published SDK for workflow and MOSS. So in practice what does this mean to you? Lets explore a popular workflow example I have seen. A popular use of MOSS and the surrounding workflow will be primarily document-centric. With that in mind let's say I am a knowledge worker who is responsible for a specific set of document libraries in side of a SharePoint site. I want to create a workflow attached to a document library that when initiated will perform certain actions such as copying that document to another library or sending an email to certain groups based on the type of document it is or values contained within the documents metadata.
So what I can do is use SPD to attach to the document library and create a workflow similar to the following
Conditions
Condition Create by = HRGroup
And
Condition words in Title = Human Resources
Action
Send Email to HR Policy Group
Assign Action to HR Policy Group
Copy Document from current Document Library to Policy Review Library
Else
If created by administrator
Email HR Group
Collect more information.
Figure 3
Some caveats on this workflow. Both document libraries must reside on the same site, and the metadata the workflow is trying to evaluate must be guaranteed to be present. So some careful planning and configuration needs to take place.
Microsoft is shipping several workflows that will be present "Out of the Box" They are tentatively as follows:
- Approval: Routes a document for approval. Approvers can approve or reject the document, reassign the approval task, or request changes to the document.
- Collect Feedback: Routes a document for review. Reviewers can provide feedback, which is compiled and sent to the document owner when the workflow has completed.
- Collect Signatures: Gathers signatures needed to complete an Office document. This workflow can be started only from within an Office client.
- Disposition Approval: Manages document expiration and retention by allowing participants to decide whether to retain or delete expired documents.
- Group Approval: Similar to the Approval workflow, but uses a designated document library and offers a personalized view of the approval process(es) in which a user is participating. This workflow provides a hierarchical organization chart from which to select the approvers and allows the approvers to use a stamp control instead of a signature. This solution was designed specifically for East Asian Markets.
- Translation Management: Manages document translation by creating copies of the document to be translated and assigning translation tasks to translators.
- Issue Tracking: Manages the issue tracking process by creating tasks for Active issues assigned to users who own to a given issue. When the task related to an issue is complete hence resolving the issue, the creator of the issue is assigned a review task so that the issue can be closed.
Benefits:
1. Pre-made workflows you can just configure and go.
2. Based solely in the office environment, no custom gui to learn or deploy.
3. Ability to change parameters during execution, such as add more approvers, redirect to a different approver, and request changes from the originator.
Drawbacks and limitations:
1. Each workflow is site bound, so no actions such as creating task or copying document can take place outside of the site that it is running on
2. These workflows cannot be extended or significantly modified since they are compiled DLLS on the SharePoint server.
I believe that organizations using SharePoint 2003 today will really like the collect feedback, issue tracking and Collect signatures workflow, they provide a simple yet effective workflow that automates some very common tasks found in corporate America. However with these workflows and how they assign manage and display tasks, even with the roll-up tasking, the task management of the workflow may be difficult to be truly applicable in larger more diverse deployments or in matrix organizations..
Many organizations with a more mature SharePoint deployment that is in high use will find adapting these OOB workflows as well as SPD workflows especially as the Work Flows themselves begin to cross organizational boundaries or groups. However organizations who are not afraid of development work and maintenance will be able to overcome this hurdle. Those with a Build mentality will find this a fresh approach to building applications on a good platform.
Workflow integration and Office client 2007
This really is the best feature area for how and when you want to leverage MOSS and workflow. Being able to store a office document in a document library and start and interact with that workflow right from the office application itself is a powerful tool in the workflow users and builders arsenal. Figure 4 represents the option from the new office menu for starting workflow. Figure 5 is a screenshot of how tasks will appear in the office application itself where there is one for that document. Figure 6 is how you are able to choose which workflow to start from within the office application.
Figure 4
Figure 5
Figure 6
Who will build it and will they come?
Who will build, deploy, and manage your workflow? Organizations planning on implementing not only MOSS with WF or any workflow applications need to seriously consider this among other questions. There are some serious design considerations with determining these roles. With SharePoint designer organizations must place the creation and deployment of workflow in the same role. There is no way that I am aware of to have one person go through and create the workflow then send that application to another for the actual deployment. With this being said there are some obvious security implications but more so than that there are some trust and cultural issues in many organizations that need to be overcome. However from a security perspective the IT risk should be minimal as was discussed, since the impact is constrained to a specific list and the actions being taken are restricted to a minimal set. Obviously this can be changed with IT creating and exposing additional actions to be surfaced in the designer. However from a default perspective this is not the case.
Many organizations today, are beginning to see the value in involving the business community in a more proactive role for application/process/workflow design. There is a tremendous amount of value in making a significant effort to do so. The values of which go beyond the scope of this article . However, if organizations are going to attempt to tap into this value they will need to seriously consider the basic technology skill set present in the users they are looking to involve. While SPD is not a developer experience where one needs knowledge of API sets and similar terminology it does however need in most cases more skill sets than the average end user possess. This is because it introduces workflows and the like in a manner that these types of users are not used to thinking of. There is terminology, ways of thinking and planning that make this effort slightly prohibitive. However as stated this can be overcome with some training. If this does not seem appealing to you, there are alternatives in the ISV community.
What does all this boil down to? Microsoft has made great leaps forward in adding value to those organizations that choose to invest in MOSS and already have investments in SharePoint 2003. Even if you take workflow out of the picture MOSS provides a huge amount of value. Organizations that choose to leverage the abilities of MOSS for workflow or choose to use it as a platform to develop their own applications will be pleasantly surprised at the plumbing provided. Before going down the path of workflow every organization will need to look carefully at their needs and what amount of effort they are ready to put forward into meeting those needs before moving forward into a workflow project.
If you have looked at MOSS, SPD, and WF and these do not meet your needs, please take a look at K2 which leverages these technologies but makes for a collbaborative environment for your business users and IT developers.
