Automating business processes in SharePoint: SharePoint Designer Workflows (Part 1 of 3)

Right, here is the first part of a three-part series on automating business processes in SharePoint. We will explore three different methods of doing Business Process Management, or BPM, using SharePoint and available tools.

The scenario is a simple helpdesk application in which users should be able to send emails and have an issue be raised and sent to an appropriate agent for resolution. We will use an email enabled list to receive emails and then use automated processes to route that email into the issue tracking system. The system will make sure that the issue is tracked and escalated as appropriate.

Update: If you really want the inside scoop on SharePoint Designer workflows and learn far more than this short article will teach, check out issue 4 of Understanding SharePoint Journal, titled SharePoint Designer Workflows. For just $14.95 you get a full 100 page eBook and almost three hours of instructional videos.

 

Here are the links to the entire series:

Automating business processes in SharePoint: SharePoint Designer Workflows (Part 1 of 3)
Automating business processes in SharePoint: SharePoint Event Receivers (Part 2 of 3)
Automating business processes in SharePoint: Visual Studio Workflows (Part 3 of 3)

Oh, and make sure you subscribe to the feed to make sure you get updates and new articles as they become available.

A few things worth noticing. This series will not result in a production ready system. It is meant to show different aspects of process automation, not to create the best method of doing a specific task such as creating a help desk application. The series is meant to show the entire process of creating the application.

First of all, lets draw a simple diagram to explain how the system is supposed to work.

IssueFlow

So, in a few short sentences:

1. Receive a new email and start a new support issue (handled by SharePoint designer)

2. Escalate issue and find an available operative to handle the case (handled by an event receiver)

3. Update the issue, and if it is resolved, send a message to the customer. If not, go to step 2. (handled by a custom workflow in Visual Studio)

If you are going to do this in a production environment, don’t. Basically what we are doing here is demonstrating different aspects of business process management, not doing a best practice thing. In a production system you would likely want to do all of this in a state machine workflow, or at least not do three different approaches to automation in one single system.

Let’s get started with lesson one.

Solution walkthrough

Setup

Now, as you probably know, or will learn in about one second, SharePoint lists can receive email. This means that when someone sends an email to a certain address in the domain you set up, the email will be sent to a list which will then receive a new item containing that email.

There are problems, though, or at least quirks. Each list can only have one email address, meaning that if you want to have one system to handle multiple addresses you need to work around that and at the very least have multiple lists. We shall look at one option for doing this with a SharePoint Designer Workflow.

Also, only a certain number of list types can receive email, and sadly Custom lists are not on that list. The reason you cannot send email to a custom SharePoint list is that to enable email you need a very specific set up fields and properties set on the list. If there is public outcry for this I can create a new article later showing how to create a custom email enabled lists using features. Use furuknapgmail.com for your requests, as usual.

Before we actually look at how this will be done, we need a few things set up. We want to receive email so we need an email enabled list. I will not go through setting this up. Email setup is a complex thing and we would be spending the entire day just setting up email, and most likely it would not be usable in your scenario anyway.

Note, however, that the behavior of incoming email and especially email in conjunction with workflow has changed in various version of SharePoint v3.

At this point I will assume that you have set up an email enabled list and have that working. If you do not, I recommend Googling “email enable lists in sharepoint”, but be prepared to spend a little time setting this up.

Next, since we need to track issues, we likely want to have a SharePoint list containing the issues. Remember we can only have certain types of lists be email enabled? Well, that does not prevent us from creating a custom list to hold the actual issues. After all, the first step in our automation is to create an issue, and we might as well do that in a custom list.

So, go ahead and create a few lists. We need one list to hold our incoming emails that will be email enabled. I use an announcement list since it is fairly basic. Any basic announcement list will do. Email enable it in list settings and give it a useful email alias. I call my announcement list ‘support-receive’ use support@lab-s02 as the email alias. You will likely use something else 🙂

Second, create a custom list that will hold the issues. You need the following fields:

  • title (single line text)
  • message (multi line text)
  • sender (single line text)

We shall expand this list in both the next articles in the series, but for now this will be enough. I have called my list ‘Issues’. Use whatever name you like.

Ok, we should be ready to start working with the actual workflow.

SharePoint Designer workflow

Right, start SharePoint Designer and connect to your site.

Click File->New and select the SharePoint Content tab. Select Workflow in the left pane and Blank workflow (only option) in the right pane.

step-1

Next, click Ok to start the Workflow Designer wizard.

On the first screen of the Workflow Designer you only need to give your workflow a descriptive name and make sure you attach the workflow to the email enabled list (support-receive in my case).

You can leave the option to manually start the workflow. This means that when you want to start the workflow you do so manually by either opening the context menu on the item in the list or on the display form of the item.

step-2b

If you like you can also set the workflow to start automatically, when an item is added and/or when an item is changed. You can modify this setting later so I suggest you leave it off at the moment. Your window should look something along the lines of this:

step-2

Click Next to get to the second page of the Workflow Designer wizard. Don’t worry, we a soon done 🙂

We are basically only going to do one thing here, at least in the first implementation, which again illustrates the point that you probably do not want to develop a workflow like this in a production environment. I mean, there will be only one task performed, so hardly any ‘flow’. However, Windows Work Foundation sounds lame. But I digress.

One task to perform. First, write a descriptive name for this step, for instance ‘Create issue item’. Next, click the Actions button and find Create a list item.

step-3

Note that the list of available actions may be different in your case. The list is dynamic and lists your most recent actions on top. Note also that you have a ‘More actions…’ option at the bottom. You can use that option to see even more workflow actions that you can perform, and, if you are up for some coding, you can also create your own actions that will appear in the list.

But that’s another show.

Right. When you select Create List Item you will see that you get a text like in the screenshot below. This text, and similar texts for other workflow tasks, are used to configure the specific task. In our case we need to configure what item will be created and where. To do so, click the ‘this list’ link in the text next to the actions button.

Now, in the dialog that opens you get to configure the item that will be created. We want to create a new issue so make sure your issues list is selected. Next, you need to configure the fields of the new item. Any required fields in the list you select will automatically be populated for you, meaning at least Title and possibly others as well, depending on which fields are required.

step-4

Ok, now things get a bit hairy, but the following steps and dialogs are about as important to workflows in SharePoint Designer as breathing every few seconds. I will explain more about this a bit later, but for now, just follow the instructions, look at the screenshots and make sure you get it right. If you end up with a different result, delete the wrong fields and try again.

  1. In the Create New List Item dialog click the Title field and then Modify. A new mini dialog appears, called Value Assignment.
  2. Next to the ‘To this value’ text box, click the fx button to set the field title to a lookup field. Yet another mini dialog appears.
  3. Make sure you select Current item and in the Field, select E-Mail Subject.

Here’s a screenshot:

step-5

Ok, so what is actually going on here? The process is important but may be confusing the first time you see it, especially the lookup fields in step 3.

Now, the following paragraphs will go into some rather deep and perhaps confusing detail on how the dialogs work. I will explain as best I can, but if you feel you are in over your head, just skip to the final steps of setting up this workflow.

Value assignment dialog

First of all we decide we want to set a field, in this case on an item. In step 2, also a common dialog in SPD, we basically have two options to setting a text field. The […] button lets us set the value of a field to a text that you type in. The [fx] button lets us set the value of field by looking up another field in the site.

Before we look at what goes on there, though, note that different field types yield different input options. For text field you get a text box, but for a date/time field you get a calendar, while for a Yes/No field you get a drop-down and for a person field you get to look up a person in several different places, including the address book and SharePoint users. I have included some screen shots below.

step-5a step-5b step-5c

Ok, so we can set fields of our list item to a set value which is useful in a range of scenarios. What we want to do in our case, though, is to set different fields to the values of another object, namely the item that was created with the incoming email.

Define Workflow Lookup dialog

In step 3 of setting the value of the title field we got the Define Workflow Lookup dialog when we clicked the [fx] button. The dialog can be a bit confusing as well, but after a few paragraphs, things should be as clear as… something really clear.

The lookup dialog allows you to find other items in the SharePoint site to use to set the value of a field. There are basically two fields in the dialog, which item from which to use a value and what value of that item should be used.

For our example it was rather simple. Remember that the workflow is initiated by the item in the email enabled receiver list. thus, what is listed in the lookup dialog as ‘Current item’ is actually the item in the receiver list, not the item you are cu
rrently creating. Important distinction.

What makes the workflow lookup dialog a bit more complex is that you can work not only with the current item, but with any item in your site. Look at the screen shot below.

step-6a

As you can see we can work with but the current item, something called Workflow data, which we will cover later, as well as all lists in the site. If you select any list directly, i.e. not current item or workflow data, the workflow lookup changes to let you set up how you will find the relevant item in the lookup list.

step-6b

The new section of the dialog allows you to select which field you will use to find the new item. ID is often a good choice since it is unique for each item. However, you also need to select the value which the said field will have. And there you are with the [fx] button again. Clicking that will yield a new Define Workflow Lookup dialog.

Think it is confusing? It is. At this point you are doing multi level lookups across several lists. It can be really powerful but you need to wrap your head around it.

Final tasks

Ok, back to non-head-exploding land.

If you have set up the title field properly, here’s the good news. Do the same to the Message and Sender fields, mapping to the fields ‘Body’ and ‘E-mail From’ of the current item, and we are done.

Depending on where you are at the moment, click back to the Create New List Item dialog, where, at present, you should have configured the title field. To add more fields to the new item, click Add. Select the field you want to set (Message and Sender in order) and map it to the correct field of the current item, as described in the last paragraph. Your final field setup for the new item should look something like this:

step-7

That’s it! We have create a new SharePoint Designer workflow. Just hit Ok and then Finish and SharePoint Designer will go off and do some configuration magic to attach the workflow to your list.

Testing

Now that you have your workflow set up, go ahead and test it by sending an email to your list. If you have your email enabled list set up properly you should get a new item in the receiving list. Open the list in the web interface.

When the item arrives, and it make take a minute or two, go ahead and click the item or open its context menu to find the Workflows available to that item. You should find your workflow under the ‘Start a New Workflow’ section. Click it and verify that it actually creates a new item in your Issues list.

More fun stuff!

Since we are using a receiver list to pipe our incoming email into an issues list we can surely use different receiver lists as well. Let’s up the complexity a bit.

We can now use two email enable lists, say one called support-receive and one called invoice-receive. Each can have a different email alias making it possible to pipe for instance support@example.com as well as invoice@example.com to the same issue list.

However, we have no method of differentiating the issues at present. So, in order to do this, add a new field to your issues list in SharePoint called ‘Issue Type’. The field will be a Choice field and the choices will be ‘Support’ and ‘Invoice’. You can add more if you have more email enabled lists.

Oh, and one thing. You may want to make this field a site column rather than just a list column. You will see why in the next article.

Go back to SharePoint designer and modify your workflow. To do this, open the Workflows tree node in the folder list, then open your workflow and then double-click the xoml file to open the Workflow Designer again. Note that you can click the Back button to change how the workflow is started, but you cannot change the list to which it is associated.

Back on the second step of the wizard, the one with ‘Conditions’ and ‘Actions’, click on the ‘Issues’ link in the text ‘Create item in Issues’. this will reopen the Create New List Item dialog.

Click to add a new field. You choices field ‘Issue Type’ should be there now. Since you are working on the support-receive list, select to set the field to Support. See screenshot for how it looks on my machine.

step-8

Great. Now, new items sent to the support-receive will be marked as being of type Support.

Repeat the entire process of creating the workflow for your invoice-receive list as well, but change the value of the issue type to ‘Invoice’. Repeat for any other receiving lists as well, and suddenly you have not only a way to receive emails to multiple addresses, but the beginning of a simple classification system as well.

Ending it all

Ok, so this may not have been incredibly impressive, but this is the start of some really cool stuff you can do. We shall explore this a bit further in the next article where we go into some more advanced things we can do with SPD and then head down into another cool aspect of business process automation: Event receivers.

Update: If you really want the inside scoop on SharePoint Designer workflows and learn far more than this short article will teach, check out issue 4 of Understanding SharePoint Journal, titled SharePoint Designer Workflows. For just $14.95 you get a full 100 page eBook and almost three hours of instructional videos.

Here are the links to the entire series:

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

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

5 thoughts on “Automating business processes in SharePoint: SharePoint Designer Workflows (Part 1 of 3)”

  1. Great Article – such little advice out there beyond the basics for SPD workflows.

    Wondering can I pose a question to you? When you click “Finish” after designing new or changed steps/actions, SPD should then validate the workflow and then save/publish the new/updated workflow against the list or document library.

    Mine doesn’t save/publish, ol dversion of workflow still runs on new list items.

    My problem, and looking at both Microsoft and non-Microsoft blogs/websites/forums, this is a commonly experienced problem.

    I can look at the list item specific instance of the workflow history, and quite clearly the old version of the workflow still being used.

    I have followed recommended work arounds by various bloggers when experiencing this before – such as deleting list/doc lib, rebuilding workflows by deleting actions/steps and retrying. These are VERY time consuming to delete work and rebuild, I do not see this as a feasible workaround and it seems crazy to have to undo changes to redo them merely so they take affect.

    My solution when I experienced this just last week was to remove existing instances of workflow against my list, and to stop any new instances of that version, then to delete all list and task items, then go back into SPD re click “Finish” to publish workflow changes and then retest adding item to list. This worked last week.

    I am using one workflow against a custom list, and a secondary workflow against the Task list to send customised email notifications, it is NOT a complex workflow.

    Any advice would be most gratefully recieved – Lucy. (sorry for the essay!)

  2. Hello, Lucy, and thanks for you comments.

    I haven’t experienced this exact behavior before, but I can see a range of places where we could start searching.

    Can you describe the simplest steps required to make this error appear? Or, if you have references to other people describing the same, provide me with the Url to such a description?

    I’ll be sure to look at a solution or to explain why this is happening.

    .b

Leave a Reply

Your email address will not be published.