Use SharePoint Worfklow Like Robots on a Conveyor Belt

The idea of automating a business process with SharePoint workflow to make things more efficient and consistent sounds like a novel concept and a way leverage a technology investment. However, if you examine any major business process from the top down, what you will find is that it is made up of several tasks (some linear, some not) as well as decisions which are based on a constantly changing environment and context. These decisions are not only in support of executing the process, but often times the process itself is being evaluated real time.

Take for instance, the beginning portion of a new hire process that a company might have. This might involve a series of human interactions between candidate and recruiter. An application is submitted and the recruiter would evaluate the application, comparing it to an open requisition. The recruiter would interpret the information on the application and ask for clarification. If a match is made, then an interview might occur, and so on.

When the people involved are attempting to execute a process such as this, it is only natural that the changing conditions of the work environment will prompt questions about what tasks need to be completed, who should complete the tasks, what information should be gathered, how should that information be evaluated, what laws exist, etc.

Although, it is possible to automate certain tasks in this process, SharePoint workflow is not designed for automating the entire business process. Where SharePoint workflow really comes in is making discrete tasks more efficient. For example, the workflow technology may be used to transfer an applicant's information into a database where it can be easily compared with open requisition criteria.

The technology is not going to do a human's work, though, and it is not practical to even try to make it. No, instead, a more appropriate approach to leveraging SharePoint workflow is for efficiency gains which target small steps or tasks; ones that are completely black and white, like modifying and loading records into a custom list or database, moving documents, or sending out an e-mail when a specific event occurs.

Portal site designs which help guide the human through a series of steps is essential to a workflow solution. The portal provides the framework to guide the user, while the workflow elements provide automation for specific tasks that occur during the process.

Whatever the application, the goal is usually to provide tools that allow the human to logically string each step together, flowing as if the site is a virtual conveyor belt and the workflow elements (conditions/actions) are specific robots that do stuff at each stage. The overall solution should help guide and progress the overall process in a consistent direction so that humans can participate, contribute, and derive the needed results.

Still, in an ever changing environment, it is only natural that the conveyor belt will need to be stopped and participants will ask each other whether the process is effective and efficient enough, and what might need to happen differently. The simple fact is, every business process is a work in progress.

SharePoint Designer Workflow: It's Just a Facilitator

SharePoint Designer workflow in general is best used as a facilitator of actions that make up a business process and it does not work well for automating or enforcing an entire, complex, human process. What I mean is that SharePoint Designer workflow is best used to automate certain actions that occur within a business process like assign a status of something, or email something, or copy something but its not going to replace human decision making and its not going to perform the entire business process for you.

Say, for example, that Company ABC's IT team is supporting 100 employees through email exchanges. When an employee has an issue, they email an IT distribution list then the IT staff responds to the issue. The IT team is finding that they are struggling to keep track of the support requests. They are considering using SharePoint to track support requests.

A solution to this business problem may be to use SharePoint to structure the metadata about support requests and use workflow to automate actions that occur during the process. Create a SharePoint custom list to track support requests with request id, requestor email, status, title, description, solution fields, and then use SharePoint Designer workflow to perform the following:

* Automatically generate request id for new support requests
* Automatically build and send email the requestor when status of items is changed

SharePoint Designer should not be used to implement rigid rules that contain deep branchings for how the support requests are resolved. You do not want to attempt to create a workflow that predicts and solves the support requests that you are tracking within SharePoint. Thining through and resolving support requests is a complex human process and it scales beyond practical limits of SharePoint Designer workflow.

Workflow can certainly improve processes, and it can simplify tasks that a person performs during a business process, such as the example above....just don't expect workflow to do somebody's job for them.

Copying a SharePoint Designer workflow

I am working on a SharePoint site that has multiple custom lists. Each list will have a SharePoint Designer workflow attached to it. The workflows are very similar to eachother. Each workflow is several branches long so it takes quite a bit of clicking to set one up.

I figured after I was done with the first workflow I would copy it, paste it, rename it, and point it to the second list, then change workflow conditions and actions accordingly. However, when I opened the workflow copy I discovered that the custom list assignment had become greyed-out and I am unable to point it to a different list.

This has got me wondering why Designer locks down the list name and if there is a way to work around this manually.