I'm currently in the process of defining how workflow development should look like in my company and how the different environments (development, integration, qa and productive) are being updated.

  • SP Designer 2013 has become a really powerful tool. However we do not just yet see it as a tool we want to put into the hands of non-IT departments. Also using SPD means you either have to work with the live system directly or work on a qa environment where you save your workflow as a template ( -> wsp) which you then have to deploy on the live system. Is this feasible? Does anyone have any experiences with that approach?
  • Visual Studio 201x workflows are declarative too now. The advantage here is source control integration and debugging capabilities. The tool set is way more complex to use though. And at the end of the day you have .wsp files as well. But of course these files could also bring along columns, content types, list templates and instances, ... things the SPD doesn't offer.

I can see opportunities where SPD might be the right choice. Low business impact, trivial workflow scenario... for anything else I'd go with VS based workflows.

What is your take on the subject?

1 Answer 1


For company level / mission critical workflows, I agree with you about SPD. But, for a team site that is being used by a smaller group? Why not let them have access to build their own SPD workflows? Power Users will be able to build out their own processes which provide benefits to the group. Without it, they are missing out on some of the huge benefits of using SharePoint. (I don't suggest you give permissions for SPD to everyone, but I do think it is a great tool for power users.) (And, no, I don't use test systems. If they build the workflow incorrectly, then delete it. No harm done.)

VS workflows are their own skill set. If you want to use them, then developers will need to spend time ramping up on that skill set. There are benefits to this, but don't underestimate that cost.

Another option: Nintex Workflows (or other 3rd party?). It's more money, but in my experience, folks who have gotten access to it are always thrilled. Just last week I was talking with folks who just got access to it and they were talking excitedly about the different processes they could build out. The things they were talking about would be difficult/impossible with a SPD workflow. And, the folks talking were business users, not developers. (No, I don't work for Nintex.)

  • So when you (as a developer) design a new application with serveral artifacts (columns, content types, lists, ...) including a workflow - you go with SPD? No source control? No test environments? As for non-developers and my dislikes about SPD.. we are too few persons to support any "why is my self designed mission critical workflow not working anymore" scenarios...
    – lapsus
    Commented May 17, 2014 at 15:03
  • There's a difference between using SharePoint as a platform for custom app development, and business users customizing sharepoint to meet requirements. Yes, custom built apps are via VS. But, in my experience, team sites that support a smaller group are almost always built by a member of the group, or by some other power user. Also, I have heard many users describe custom solutions as a failure when they later found out they couldn't make minor changes, such as adding a field, or customizing some small aspect of the business process.
    – Mike2500
    Commented May 17, 2014 at 21:31
  • Though, I shouldn't have agreed to the VS workflow so casually. I've been avoiding the VS 2013 based workflows as much as possible, as the tooling was designed by someone who was being attacked by a cat. So, I'm also looking forward to the answers from others. For me, larger apps with other components will be VS. But when the app is being designed for one particular site and won't be deployed on a larger scale, then we still use SPD.
    – Mike2500
    Commented May 17, 2014 at 21:42
  • Being able to make minor changes to the project yourself (as a power user) is a valid point. I'll keep that in mind! (backdraw: No version control. Disaster recovery is a somewhat more complex task to manage). I'm not sure I get the meaning of "him being attacked by a cat"...
    – lapsus
    Commented May 19, 2014 at 6:23
  • I agree about the source control issues, but as an end user tool, they don't know about source control anyway (just like Excel doesn't have source control). Re the cat comment, sorry just trying to be funny. In my experience, the UI of the VS workflow tool is a hard to use, disoraganized mess of a tool that was created in the absence of people knowledgeable in the study of usability or design. I've seen power users excitedly create complicated workflows using Nintex, and I've seen very experienced people look at the VS workflow tool with frustration and dismay.
    – Mike2500
    Commented May 19, 2014 at 12:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.