These days, I’m perpetually playing catch-up with my blog reading and I just came across this post: http://sharepointsolutions.blogspot.com/2009/02/give-blood-to-your-workflow.html
It’s as solid and detailed a SharePoint Designer workflow tutorial (plus more!) that you’ll see anywhere on the interwebs. I’d check it out, even if you’re a scarred SPD veteran.
It’s a great SharePoint tutorial for both InfoPath and workflow.
</end>
Follow me on Twitter at http://www.twitter.com/pagalvin
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>
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>
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>
Follow me on Twitter at http://www.twitter.com/pagalvin
In what appears to be his inaugural blog posting, chiqnlips has delved into the madness that is a calculated column and described a solution to a common SharePoint Designer workflow email activity problem: How to display a person’s real name in an email instead of "domain\username."
I haven’t tested it myself, but it looks promising. Check it out.
</end>
Follow me on Twitter at http://www.twitter.com/pagalvin
Mark Miller over at www.endusersharepoint.com posted my latest article on SharePoint Designer workflow here (http://www.endusersharepoint.com/?p=1037).
I describe the basic approach for moving a workflow you create in one list to another list. The other list can be in the same site, same site collection or an entirely different farm (e.g. from development to production).
This is a complicated subject so I only covered a very basic scenario. Next week, I’ll write up a more useful real world example.
Check it out and share any comments there.
<end>
Follow me on Twitter at http://www.twitter.com/pagalvin
Mark Miller has posted my latest End User oriented SharePoint Designer Workflow article up on his site here: http://www.endusersharepoint.com/?p=1008
I attempt to provide a straight-forward answer to the question, "Why can’t I easily port a SharePoint designer workflow from development to test?" In the process, I also give some insight into what SPD is actually doing behind the scenes when we use it to create a workflow solution.
Next week, I describe an End User friendly way to port SPD workflow from one server to another, or at least as End User friendly a solution as is possible given the state of the tool set.
</end>
Follow me on Twitter at http://www.twitter.com/pagalvin
Here’s another common SharePoint Designer workflow question:
"Can I access (read/write) SharePoint lists via workflows which do not reside on the same site as the list itself?"
The simple answer is: No.
As in so many ways, however, we have to qualify that (which is a good thing in this case). The platform lets us create extensions to the produce in many ways, including a custom action (see my little codeplex project here for an example). A custom action lets us do basically anything we want from SharePoint designer workflow. I’m a big fan of this, in fact, since it gives us the best of both worlds — a declarative end-user friendly designer with the full depth of the .NET framework at our finger tips.
Sadly, if you’re using SPD, there’s a good chance you’re doing that because you can’t use visual studio (due to the fact that visual studio requires a deep developer background). I don’t have any good answer to that problem except that you should prevail upon one of your technical co-workers to create the kind of custom action you need. Alternatively, work with management to hire or contract that kind of resource.
</end>
Follow me on Twitter at http://www.twitter.com/pagalvin
Sadly, it is not to be. We cannot send an email with attachments from a SharePoint Designer workflow using out of the box features. This wish comes up with increasing regularity on the MSDN forums.
However, the SharePoint platform, as with so many things, does offer us a path forward. We can create custom actions which we then incorporate into our workflows. Once installed, a custom action looks and feels like any other action (e.g. Collect Data, Log a Message, etc).
Creating a custom action is a big mountain to climb, however, for End Users. This codeplex project provides this functionality: http://www.codeplex.com/SPDActivities. Pulling that down and installing it is also beyond the skills of typical End Users. However, it’s quite simple for a SharePoint admin to do it, so if you find yourself needing to develop a workflow with this capability, work with your SharePoint admin to get it done.
</end>
Follow me on Twitter at http://www.twitter.com/pagalvin
We have a set of SharePoint designer workflows that "communicate" with an event receiver on the list via changes to site column values. For example, if a site column "SetDuedate" is set to true by the workflow, the event receiver detects that change, calculates a due date and assigns that date to another site column, "Due Date." We split things up like this because the event receiver can calculate a due date using complex business rules (taking weekends and company holidays into account) while SPD really can not.
In one specific instance, we ran into a problem with this trick. Debugging all this is pretty difficult, but we came to the definite conclusion that in one case (at least), the event receiver was not running all the time. In one step of the workflow, we would change the value of a site column and the event receiver didn’t appear to run. However, it was running consistently in a different step of the workflow.
After reviewing it, I noticed that the happy workflow step used the "Update List Item" while the other step used "Set Field in Current Item." Update List Item was updating the "current item." I’m not sure why we picked one over the other since they would seem to be doing the same thing.
So … the Update List Item action did cause the event to fire. On the other hand, the Set Field in Current Item action did not.
I used Update List Item in both places and viola! It worked. [[ Total aside, I played the violin for on a daily basis for almost 15 years ]]
From this, I tentatively believe that the "Set Field" action does not cause event receivers to fire, at least some of the time.
This issue bedeviled us for weeks.
This is one of those "observed behavior" posts. I observed this happen once in a specific environment and I’m making some guesses as to why things happened as they did. If you have any insight into this one, please share in the comments.
</end>
