SharePoint Workflow – What You Need to Know

The most powerful feature of SharePoint, at least the one most likely to cause a high return on investment (ROI), is the tight integration and high utilization of workflow.

In this short article, I will tell you what you need to know about SharePoint workflow in order to understand how to harness the power and potential economic benefit of business process management in SharePoint.

So, What Is a Workflow Anyway?

OK, you may have heard me use that exact phrase before, and you’d be right, as I explained this in a previous post on SharePoint Designer workflow. Rather than repeat what I wrote then, however, I’d like to offer a more descriptive… description.

A workflow is a formalized business process mapped to various executable activities on a computer. Think of a workflow as a highly adaptable and configurable program that performs a series of tasks. The program is adaptable in that it can be changed depending on business needs.

The ‘various’ part of the explanation is where you get the power of workflow. Compared to a traditional program, in which you often get a set of features and need to rewrite the program to extend that set of features, workflows allow you to pick and choose from activities.

Figure 55 

In short, you get a ‘pick and choose’ program that you can change as your needs change. Workflow is the Lego of programming, in a manner of speaking.

Wait, Programs? That Sounds Complicated and Unstable?

Yes, which is why I say ‘in a manner of speaking’.

You see, at least in the Windows Workflow Foundation that SharePoint uses, the framework handles most of the nitty-gritty details for you, and enables you, more or less, to just say what you want to happen when during a process. The stability and flexibility is also handled by the framework so you don’t need to worry as much about your workflows as you would normal programs. 

For example, if your server goes down, the framework will make sure that your workflow continues to run after the server comes back up. If you need to change your workflow, the framework and SharePoint will ensure that running workflows complete and that new instances of the workflow only use the new version of the workflow.

What Are Some Common SharePoint Workflow Examples?

Probably the most common example used is an approval workflow, in which some form of data requires approval from someone. The default SharePoint approval workflow is one such example, in which the author of the data requests approval for an item or document. This may be a request for expenses reimbursed, a vacation request, or any other request for which on user requires the approval of another user to complete some task.

Another common example is document management. Regardless of size, almost all organization have some form of document management, even if it’s as simple as telling a secretary to file a report in a certain file cabinet. Workflow can help automate document management, and the SharePoint document workflows offer some out-of-the-box functionality to cater to basic needs.

However, these are just two examples of scenarios in which workflow may help. The nature of workflow is that it can be customized to almost any business process, if nothing else than to track the progress of those processes or audit what happens during a process.

How Can I Create SharePoint Custom Workflows?

You have several options for creating and customizing workflow.

Out-of-the-box SharePoint Workflows

Granted, out-of-the-box doesn’t sound very customizable, but the truth is, many of these workflows are flexible enough to solve at least basic needs. For example, for the SharePoint approval workflow, you can customize who gets to approve an item or document, as well as deadlines for the approval tasks, and allow or disallow the approvers to reassign the workflow approval task.

If this still doesn’t meet your needs, you may want to take one step up.

SharePoint Designer Workflows

SharePoint Designer (SPD) offers a basic workflow authoring experience. With SharePoint Designer 2007, end users can create workflows without needing to learn complicated tools or adopt programming as a career.

Despite the perceived simplicity of SharePoint Designer workflows, however, you can accomplish fairly complex tasks using the built-in activities in SharePoint Designer. In addition, you can get or create additional activities to further customize your workflow and in essence create your own Lego pieces.

Figure 84 

SharePoint Designer is often scoffed at by developers as being a FrontPage bastard child. However, for designing one-off workflows with a very gentle learning curve, SharePoint Designer workflow is the way to go.

In addition, several of the limitations of SharePoint Designer 2007 are improved in SharePoint Designer 2010, as I have written previously in the first and second look at SharePoint Designer 2010 as well as the SharePoint Designer 2010 workflow features article.

You can learn all about SharePoint Designer workflows in issue 4 of Understanding SharePoint Journal.

Visual Studio SharePoint Workflows

The limitations of SharePoint Designer workflows become apparent when your needs become a bit more complex. That is when you may want to turn to Visual Studio.

Visual Studio offers the maximum amount of flexibility and power at the cost of a longer and more complex learning curve. If you want complete control and maximum power, however, that is the price to pay.

 Figure 84

However, while Visual Studio is traditionally considered a programmers tool, it is a myth that creating Visual Studio workflows require programming skills. You can get a lot more done if you do use some programming, but in essence, the same building-block paradigm is used in Visual Studio workflows as well.

You can get an introduction to Visual Studio workflows for SharePoint in issue 7 of Understanding SharePoint Journal.

Third-party Workflow Tools

If neither of these options are to your liking, you may want t
o turn to third-party workflow tools. Some well known tools are K2 BlackPoint and Nintex Workflow 2007.

Third-party tools offer both competing and complementary features to the already mentioned workflow tools. For example, Nintex Workflow 2007 offers a combination of the ease of SharePoint Designer workflows with some of the power of Visual Studio.

While a complete description of all the available tools is a bit beyond the scope of this article, you should know that these third-party alternatives exist.
You can also get the free Using Nintex Workflow 2007 issue of, you guess it, Understanding SharePoint Journal, if you want to explore that product more.

Anything Else?

Yeah, don’t forget to brush your teeth and floss. Seriously, everything I have said here is just my personal opinion, but brushing your teeth and using dental floss is recommended based on hard, scientific proof. Proper dental care leads to healthier teeth, prevents bad breath, and can improve the whiteness of your teeth without damaging chemicals.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

I Love SharePoint – And Here’s Why (Part 2)

By now, regular readers have read my “SharePoint Sucks – And Here’s Why” series that I wrote just prior to SPC09, detailing, and you’re clever enough to deduce this, why I think SharePoint sucks. As was revealed in the final part, however, I don’t hate SharePoint, I love it. Now, it’s time to show you why I love SharePoint.

I’m doing this in step-by-step mode. I’ll tell you, in no particular order, of one thing I absolutely love about SharePoint. I’ll tell you why, and if you disagree, let me know. Send me an email at furuknap<[at]> or shoot off a comment to this or any other blog post.

So, without further ado, here’s the second thing I love about SharePoint.



I love you because you understand dear
Every single thing I try to do
You’re always there to lend a helping hand dear
I love you most of all because you’re you

With the king’s (I’m talking about Leon Payne here) words in mind, I’d like to draw attention to you, or more precisely the community of which you are a part.

The SharePoint community is absolutely brilliant. The amount of knowledge contained and shared is enormous and people genuinely seems to enjoy working together rather than being king of their own little hills.

Now, when you need to figure out something in SharePoint, you google it, right? You fire off some query and rely on Google to provide you with ignorance relief. In most cases you will likely find the answer right off the bat or at least get hints to where you should search further.

Here’s a thought to consider. It’s not SharePoint that provides you the answers. It is the community. Hundreds and thousands of people have dedicated their time and resources to tell you what you need to know to be a better SharePoint user, administrator, or developer. Even more people have added to the quality of that information with questions and answers.

Take, Mark Miller’s project. There is a massive amount of information there that he and his fellow authors share without charging a dime. Granted, he does have several for-pay workshops as well, but he has to make a living too, right? Besides, running a site like that costs money and rather than charge for general access, he’s providing premium content and training for a small fee.

Then, take a look at what Jeremy Thake does with SharePoint Dev Wiki. Out of the goodness of his heart, he’s built a brilliant site that helps developers collaborate on making information available to everyone.

And of course, no tribute to the community is complete without the Danish hero Carsten Keutmann. Through his generous donation of WSPBuilder and SharePoint Manager 2007 (and now SharePoint Manager 2010) Carsten has single-handedly saved SharePoint developers years of development time. I’m serious. Up until I discovered WSPBuilder, I probably spent about twice the amount of time building, deploying, and debugging applications in SharePoint.

However, in addition to these mammoth contributors to the community, I want to commend you. You, the readers and commenters, the question-askers, the (sometimes) complaining and whining crowd, the live-bloggers, the emailers, the forum participants whether you post questions or answers, the bloggers, the tweeters, the webcast authors, the conference or user group speakers…

I’ve had people apologizing for asking questions. Stop that! Not asking questions, but thinking that you are disturbing or asking too much. Through your questions, people can learn, just as I do, every time someone asks something.

Whoever you are, as part of the SharePoint community, silent or audible, you are a great resource, and you are truly valuable.

Thank you, thank you, thank you.


Pin It

SharePoint Configuration vs. Development

SharePoint’s greatest feature is the ease with which end users with little or no training can add or modify existing features to make SharePoint do what the user needs. However, there are downsides to this feature if you are not careful, and you cannot really expect to harness the full power of a platform such as SharePoint with nothing more than a cursory knowledge of clicking links on a web page.

In this short article, I’ll explain the differences between the configuration approach and the development approach. I’ll tell you about the benefits or each and also the downsides. This will help you understand the two approaches to making SharePoint do what you want.


The first approach is where users through the web interface or other tools create content and organization themselves. The user simply adds or modifies lists, content types, pages, activates or deactivates features, makes configuration changes, and boom, you have a fully customized solution, tailored to the user’s need.

This method of development is called customization or configuration. You don’t actually create anything, you simply utilize what is already there and customize new lists, pages, or other artifacts to create a solution. End users love this method. They are themselves empowered to utilize SharePoint features, and offers them a chance to get just the functionality they need.

Taking everything up one notch, users can use SharePoint Designer to get even more power. With little or no training, users can create new pages and workflows, set permissions and options, customize forms for individual lists, libraries, or content types, and generally go bananas much to the concern of administrators and developers.

The true beauty, however, is that those who know how they need to work are the ones who are empowered to model SharePoint into exactly what they want. Department managers can create workflows that are unique to them, or set up reports to display exactly the kind of data that the department needs. End users can customize the workflow when it starts or tailor their own view of the reports, and no one needs to write a single line of code.

Regardless of how good a developer is, he or she cannot possibly know everything about how every employee wants or needs to work.

What’s the Downside?

First of all, it is very difficult to maintain a coherent solution in the long run if users are given free reigns to do whatever they please. Without control, many argue, it is impossible to support a SharePoint solution as you do not know what you will face when a user calls for help. If you’re a developer, ask yourself: How will you upgrade a solution if you have no idea what is in that solution?

Second, the options available for configuration are limited by nature. Someone has to create the lists that the user will then customize. True, SharePoint does offer a wide variety of lists, content types, and other elements out-of-the-box, but users more often than not end up wanting more. Something as simple as a customer list or a list of products does not come out of the box and will have to be created.

Third, changes made using the configuration method are not easily reproduced. If one department creates an excellent solution, you can’t just take those components and reuse in other parts of your SharePoint farm. To some extent, you can create templates as an end user, but these templates are ‘locked’ once you create them, and even if you can create new templates in a flash, there’s no way to affect existing sites or list when you update a template.

Paul Culmsee wrote a very nice article on SharePoint templates vs. definitions, by the way. I absolutely love that guy’s writing style.

Finally, some options are simply left out of the configuration method altogether. You cannot add new application pages using configuration, for example, nor can you add new functionality that requires the use of compiled .NET assemblies, such as web parts, event receivers, or some types of workflows.

Professional SharePoint developers and administrators often shun this configuration approach and as a result often attempt to reduce the number of options available for the end user. Some go as far as locking everything completely down, effectively killing one of SharePoint’s strongest features.


This is where development comes in to save the day, at least from the point of view of the developer. The power developers have is far beyond that of configuration. Developers can do anything you can do with configuration and then far more. Want to add behavior to your solution using workflows and event receivers? No problem. Want to create new web parts or controls on a page? You can do that. Need to create a completely custom provider for the navigation of a solution? Well, with code you can, whereas for configuration, you can’t.

Not just can SharePoint developers do a wider array of tasks, but they can also affect entire SharePoint farms in a single swoop, where web interface or SharePoint Designer configuration may take days of manual work. With a few lines of code, a SharePoint developer can add a new column to every content type or list in a site collection, and just as easily change the name or configuration of a web part throughout the organization.

The maintenance and reuse aspect is also a breeze for the SharePoint developer. Not only can they easily reapply their solutions anywhere in the farm, they can also upgrade existing solutions so that they can fix minor issues rather than having to recreate everything. There are certain things that cannot be upgraded, but compared to configuration where you cannot widely upgrade almost anything, this is a major benefit.

With all that power, it is not strange that many developers feel a bit like gods; they have the power to do anything, and looking down on ‘mere end users’ is sadly an often practiced sport.

What’s the Downside?

However, developers trade time and ease for that power, for developing SharePoint solutions takes a lot more work than simply hitting Create every once in a while. Of course, with that added time and complexity, you may not want to do much development work at all, or at least the cost will be prohibitive for any small updates. There is always a certain overhead in starting a new development project, and you need to either employ or hire people with the right skill set.

Of course, if you have a lot of experience or use the right methodology, you can greatly decrease the effort of SharePoint solution development. The answer is 42, by the way, and in a later blog post, I’ll tell you more about the 42 lines of code that will save your SharePoint development projects.

Then, there is the battle of working around certain limitations of SharePoint. For example, if you have deployed a solution, you cannot add new features of files during an upgrade. This won’t change in SharePoint 2010 either, so in order to build on your solution, you need to deploy new solutions and ensure that you activate the features of that solution throughout the farm.

Neither can you change a site definition after you have made it the first time. This is a great problem for many; you may be working on a huge project in which there are dozens of site definitions. You need to get them all right the first time around or you need to maintain dozens of configuration files, two per site definition in fact. Regardless, you can make no mistakes, or you need to start over with a new site definition, even if you do something as simple as misspelling the name of a list.

Is There a Point to All This?

We seem to have two very powerful methods for making
SharePoint behave, but they are seemingly incompatible. An end user wants a quick result with minimal effort using configuration and can whip up a new solution within minutes, while the developer wants to think ahead and make sure the changes are reusable and that they can be recreated or maintained using best-practices method for development, source-control, testing, and such.

The point here is that you need to find a balance between what power you afford the end users and what must be created using development to ensure reusability and upgradability.

The sad fact, though, is that if you are to have any chance of going beyond these limitations of SharePoint, you need to use code. Creativity using configuration will only get you so far.


Pin It