Category Archives: SharePoint Workflow

My Workflow Book is Available to Purchase

I first started talking with my original co-authors over two years ago.  They eventually abandoned the project, but late this summer, with the help of several new co-authors, I was finally able to bring this across the finish line. 

Professional Workflow in SharePoint 2010: Real World Business Solutions hit Amazon and the Barnes and Noble web site some time in the last 10 days.  It’s available in paperback and Kindle/Nook and all of that, just in time for a great Christmas present. Smile

This book is about two things: 1) empowering end users so that they can solve their own business problems using SP 2010 workflow capabilities and 2) helping IT staff (developers in particular) do the same.  About two thirds of the book are targeted at what I call “Activist Users” (highly skilled but non-technical and motivated end users).  It tries to explain how to craft solutions in SharePoint 2010 using SharePoint Designer workflow and a number of additional SharePoint features.

The last third is aimed squarely at the developer.  However, unlike some of the purely technical books on the market, these chapters explain how SharePoint developers can create functionality that further empowers those activist users by means of custom SharePoint Designer activities and other technical bits.  By empowering the activist users in your organization, you free up your development team (or just yourself) to do the really hard (and typically more technically interesting) stuff that end users can never do and never should try on their own.

Over the coming weeks, I’ll write up more about the book, including fluffy stuff like “how is it like to write a book” that I know a lot of people are interested in knowing about.  First up – I’ll introduce my co-authors without whom this book would never have survived to see the light of day.

Read more about the book on the Amazon web site.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

CodePlex Project Update: SharePoint Designer Workflow Extensions

A while ago, I wrote that I was trying to resurrect my old CodePlex project, SharePoint Designer Workflow Extensions.  That CodePlex project was developed for WSS/MOSS and adds a handful of utility type functions, such as “ToLower()”, “ToUpper()”, “Substring()” and so forth.  It even has a general purpose “call web service” style function.  You can read more about it here: http://paulgalvinsoldblog.wordpress.com/2007/10/28/sharepoint-designer-custom-activity-to-execute-user-defined-c-functions/.

I more or less abandoned it quite a while ago.  Ever since SharePoint 2010 came out, however, I’ve been meaning to look back at it and make it work in SP 2010.  Well, today, I did just that.  I haven’t updated the code to CodePlex yet. I want to educate myself on CodePlex conventions before I do that, but I did update the home page wiki for the project.

The wider and more interesting implication is that custom activities from WSS and MOSS seem to port over pretty easily, which is a (welcome) surprise to me.

Here’s what it looks like in SharePoint Designer when it’s working:

image

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Manually Edit SPD XOML File to Clean Up Variables

In this post here (“Getting Answers Back from the Start Approval Process Activity”), I mentioned that you can accidentally add a whole slew of workflow variables to your SharePoint Designer workflow.  Things can quickly become cluttered and hard to read.  Specifically, if you add the “Start Approval Process Activity” action to your workflow, delete it and add it again, you end up with all of that activity’s workflow variables twice. 

It’s a real pain to go through and delete all of those manually, so I though I would try to remove them directly from the XOML file.  This proved to be easy enough to do. 

First, you need to locate the actual XOML file.  I wrote about that topic here: http://www.mstechblogs.com/paul/how-to-find-and-edit-spd-2010-workflow-xoml-files.  Once found, open up the XOML file and locate a variable you want to remove.  In this case, I added the "Start Approval Process” activity to my workflow twice.  I want to remove a workflow variable named “isItemApproved” since it’s no longer used and there is a duplicate variable named “isItemApproved1”. 

Simply do a text search for the variable.  My screen looks like this:

image 

If you search around in the XOML file, you’ll see that “IsItemApproved1” is used in many different places while the original "IsItemApproved” is simply defined once and never used.

Delete it and then save the file.

The only tricky part is that I had to actually close out SPD altogether and re-open it before SPD acknowledged that the field deleted.

Of course, deleting fields isn’t the only thing you can do with the XOML and I may blog about other topics like this in future.

You want to be very careful about what you do here and take backups of your work.  You can make a seemingly minor / subtle change here that trashes the workflow as far as SPD is concerned and you could lose hours of effort while you rebuild it.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

How to Find and Edit SPD 2010 Workflow XOML Files

I was researching an easy way to remove a bunch of workflow variables without having to spend my afternoon in a full blown SPD click torture session.  My thought was to edit the XOML directly, which is the XML file underlying SPD’s declarative workflows.  This is how I found it.

First, go to the All Files option under Site Objects in Navigation.  You need appropriate permissions to see this, so if it’s missing for you, appeal to the right admin person to grant you the priv.  This is what it looks like:

image

 

All Files shows a list of … all the files:

image

Select the Workflows folder and you see a list of folders for each workflow:

image

Click into the correct folder and  you see a listing of all the interesting goodies that make up an SPD declarative workflow.  Right click on the .xoml file and select “Open With –> SharePoint Designer (Open as XML)” to edit the XOML directly:

image

You may want to do a manual backup before you fiddle with things.  A regular copy/paste of the file directly in SPD is probably good enough, or you can copy paste the entire XML text and save it onto your desktop or whatever is your wont in these cases.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Getting Answers Back from the Start Approval Process Activity

I’ve been playing around with SharePoint Designer workflow’s fancy new “Start Approval Process” activity and was quickly stymied because I couldn’t right away answer the question, “was it approved or not?”. 

The short answer is that it’s quite easy to get the answer.  When you add this activity to your main workflow, SPD adds a bazillion variables to the Workflow Variables and Parameters data source, as you can see here:

SNAGHTML2350fe72

You’ll also note that if you add more than one of these, SPD appends a “1” and so forth to all of the variables. 

I found that when I deleted the first “Start Approval Process” activity, the first set of associated workflow variables remained (sadly).  So, be careful how you use this because otherwise, you’ll end up with  a very cluttered list of workflow variables.

I give Microsoft credit for following the “is” naming convention for a Boolean variable.  This convention makes it pretty clear what kind of data is supposed to be there.

In researching, I found this helpful article: http://office.microsoft.com/en-us/sharepoint-designer-help/workflow-actions-in-sharepoint-designer-2010-a-quick-reference-guide-HA010376961.aspx.  It doesn’t really address this specific issue, but has some good information on the topic so I’d go there if you want to learn more about this specific activity and its siblings.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

SharePoint Designer 2010 MOD function

I am working out some log where employees can request vacation, sick time, etc. One validation rule requires that you must always request time off in 4 hour intervals.  This is easy enough to do – use a modulo function.  Modulo function tells you the remainder in division.  If there is no remainder, modulo is zero, otherwise, it’s whatever is left.  For instance, 8 mod 4 = 0 (8 / 4 = 2 with no fraction).  On the other hand, 8 mod 5 is 3.

I needed to do this once with SPD 2007 once upon a time and I actually ended up using an InfoPath form to solve, so it was handled on the front end at the time.  In the current case, there may be an InfoPath form in the picture, but that’s not clear yet.  So, I was working out a technique to ensure that time requests are always in 4 hour increments.  I was going to do the math, save it in a string and then do some substring stuff. 

I pull up SPD 2010 and to my surprise (and a little embarrassment) there is a modulo function already:

image

I am once again pleasantly surprised that something I needed is already there out of the box.  It does seem like a weird function for Microsoft to include in the mix.  It has a sort of “this is easy, so let’s throw it in” feel to it.  I sympathize with that, as I do it myself all the time.  This CodePlex project has a bunch of little functions that result from the ItsEasy principle.  At the same time, Microsoft continues to support evidence the “95% of the way” effect with the product.  They implement the Mod function, but not the round function, for instance.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

SharePoint Designer 2007 Workflow Extensions CodePlex Project

I am putting together my second CodePlex project (details to be announced on Wednesday this week, plus or minus) and I had a look at my first project, “SharePoint Designer Workflow Extensions”.  I was shocked and embarrassed to see that that it’s been downloaded over 4,800 times:

image

I basically forgot about this project in the last 12 months.  I’m embarrassed because I have essentially abandoned it.

I’m going to have another look and remind myself of what it’s all about. 

If anyone is interested in working on this, let me know and we’ll see about collaborating on it.  4,800 downloads isn’t a giant amount, but it’s more than I ever realized and it’s probably worth some effort picking it up and carrying it forward.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Create, Update and Delete Patterns with SPD Workflow

I recently wrote an article for the good people at ShaerPointBriefing.com on a general pattern for implemented CRUD in SharePoint Designer.  Here’s a teaser:

image

Full article here:  http://sharepointbriefing.com/features/article.php/3889486/Create-Update-Delete-Patterns-with-SharePoint-Designer-Workflow.htm

Check it out!

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Use Custom Lists for More Effective Workflow Auditing

I’ve reorganized my life a bit and found some time to submit an article to www.endusersharepoint.com.  My latest article is up here: Use Custom Lists for More Effective Workflow Auditing (http://www.endusersharepoint.com/?p=1658).

This is the opening ‘graph:

SharePoint Designer workflow doesn’t give us a lot of visibility into what’s happening with our workflow solutions.  And, the visibility that we do get is hampered by a relatively poor interface and 60 day time window.  This 60 day window can be a major disappointment to new SharePoint Designer users because it’s not advertised by the tool itself.  It’s not at all uncommon for someone to fire up SharePoint Designer, create a workflow solution that leverages the “Log To History List” action…

The problem is that after 60 days, any messages that you create this way are deleted from the workflow history list!  After a bit of teeth gnashing and “what were they thinking?” arguments, the bottom line is this: it happens and it needs to happen.  The question is, how can we get around it?

The official answer is to rely upon SharePoint’s built-in auditing feature.  From an end user’s point of view, however, that’s very weak in WSS and not much better in MOSS.  Fortunately, we can still leverage the familiar SharePoint Designer tool to create a durable workflow history and audit trail which is an order of magnitude more useful to boot.  Here’s how.

I describe how to create a more friendly and useful audit solution for declarative workflow created in SPD. 

I was inspired to write this article from a recent project for a client that had developed nine technical SPD workflows in support of one logical business process.  Assuming for now that nine is a reasonable number, it was certainly a challenge to debug it or view the overall status of the process in one simple view.  Each of these separate technical workflows has its own independent workflow history list and that’s just not manageable.  I was able to combine all of them into a single audit list using the technique I describe on the site.

Check it out.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin