Right off the bat I'm sure that I am rubbing some Visual Studio developers the wrong way, but hear me out.
SharePoint Designer is an amazingly powerful tool, and while products produced in SPD may not be as robust as solutions developed in VS, there are almost always adequate in getting the job done.
Let me start by explaining some of the core limitations of SPD workflows in contranst to VS workflows.
SharePoint designer workflows cannot…
1) Run steps in parallel – They can only run in sequence.
2) Run loops – although you can make loops happen, they are a bit finicky and not something standard.
3) Update a people or groups field on a list item – this is a standard action of SPD workflows that does not work properly.
4) Pause until date – this is also a standard action of SPD workflows that does not work properly.
5) Run under an impersonated account – SPD workflows always run under the identity of the user who initiated the workflow.
6) Access lists and libraries on other sites - SPD Workflows are deployed to a single list on a single site, although they can access and act off of other information in lists on the same site.
7) Be easily deployed to similar lists/libraries on other sites - This is possible, it is a matter of editing some of the XML code files that correspond to the workflow, as well as updating any references to lists in the workflow itself.
That may seem like a long list of roadblocks, but in my experience, more often than not these are null issues. Now that I've gotten that out of the way, let's focus on how we can use SPD workflows to our advantage.
1) SPD workflows can be created by anyone with an understanding of simple if/else/then logic.
2) SPD workflows can be created in a fraction of the time of the time that it takes to develop a VS workflow. Let's face it, given that the creation of workflows often involves taking a physical process and making it electronic, the process itself is usually changed along with the change in medium. This fact, more so than not, results in an iterative workflow creation process that looks something like this;
- set requirements
- develop
- test
- demo
- receive new requirements
- rinse
- repeat
So when you have to redevelop a workflow X number of times until the result is satisfactory, the time saved in SPD vs VS is exponential!
3) As we all know saving time is saving money, and why would you want to pay an expensive developer to work 5 times longer than an employee that can utilize the SPD workflows?
For those who might still be skeptical, here is a sampling of generic workflows I've created in SPD.
Vacation requests that routes to a mangaer for approval and also tracks the number of days an employee has taken and has left.
Expense Authorizations that require X levels of approval.
Help desk requests that route to the qualified member of the support staff based upon the nature of the request.