Earlier this month, I put together an article originally planned for Mark Miller’s www.endusersharepont.com.  However, I instead used like Dustin Hoffman used a cross at the end of the The Graduate to fend off my (awesome! friendly!) editor at TechTarget.

This is another SharePoint Designer workflow article in the same vein as my more recent effort here: http://www.endusersharepoint.com/?p=1226 ("Use Control Lists to Create Flexible Workflow Solutions").

It starts like this:

HAVE YOU EVER wished you could temporarily disable a SharePoint Designer workflow? You may want to do this in order to mass-approve a large number of documents without setting off dozens — or possibly hundreds — of unnecessary workflows.

One way to accomplish this is to access the workflow using Share-Point Designer and disable it. To do that, you’ll need to open up SharePoint Designer, access the workflow, change its properties and re-save it. The problem with that method is that it’s a little messy and likely to ring lots of alarm bells at most companies.

In general, fiddling about with SharePoint Designer workflows is not a good practice in a production environment, nor is it part of a well controlled process.

The article then walks you through a solution to this problem that uses a custom list to turn the WF on or off as needs dictate.  Read the whole thing here (http://wp.bitpipe.com/resource/org_1127860336_240/SharePoint_vol5_v6%201_16.pdf). 

This article was inspired by a question asked on the forums here: http://www.endusersharepoint.com/STP/. Although I spend far more time on the MSDN forums, I strongly recommend that you have a peek at the EUSP forum as well, particularly for end user oriented questions.  It’s yet another source of good information and advice.

</end>

 Subscribe to my blog.

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

Last week, Mark Miller posted my latest SharePoint Designer workflow article for end users on his site (http://www.endusersharepoint.com/?p=1226).

It starts like this:

We technical types use a lot of jargon and acronyms in our daily routine such as “OOP” (object oriented programming), “CT” (Content Types), “SPD” (SharePoint Designer), “RTFM” (please read the manual), etc.  This article concerns itself with a particular bugaboo called “hard coding:” What it is, why it’s bad and how to avoid it in SharePoint designer workflow solutions.

I describe how we can use custom lists to store workflow control and configuration data.  Using this approach, we can avoid hard coding values such as approvers’ email addresses, approval dollar limits, etc. 

Check it out.

</end>

Subscribe to my blog.

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

I’m working at a client site and needed to install windows workflow foundation so that I could so some SharePoint Designer work.  (I didn’t know until today that SPD installs fine but really needs at least .NET 2.0 and Windows Workflow Foundation to be really usable; I always assumed these were installed along with SPD, but I was wrong).

The client has a proxy server.  No problem, I have credentials to get outside to the public Internets.  I go to the usual place to download WWF (SPD helpfully provided me with a link).  That download is really a bootstrap of sorts.  It runs and figures out what else it needs to download.  That second download process failed.  It either does not try at all, or is somehow prevented from asking for proxy server credentials.  It was a pretty hard crash, giving me the message:

Microsoft .NET Framework 3.0 has encountered a problem during setup.  Setup did not complete successfully.

I tried to reboot and spent 10 seconds trying to figure out if I could get it to ask me for proxy server credentials.  I gave up and went here instead: .NET Framework 3.5 Service Pack 1 (Full Package).

I downloaded that package, installed and this time, no problems.

</end>

Subscribe to my blog.

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