We have built a SP 2010 workflow solution in SP designer. Very basically, there are 10 steps in the workflow. Before and after each step, there are some custom elements, which we have coded in visual studio. Each step produces tasks for one or more users and on completion, moves the workflow on, after any custom activities.

We are experiencing so many issues with this solution that we can’t replicate as the issues occur somewhere inside the SP engine. We then have to hunt for the error in the ULS logs and, if it’s descriptive enough, we may be able to find a workaround. Other times the issue is just so random, often due to timing, we think.

I’m looking for someone to advise on a better architecture. My gut feeling is that the workflow engine itself should be coded entirely, and the code should just produce the sharepoint tasks (we can’t move away from the tasks needing to be SP tasks). At least then, we can catch and deal with any errors as opposed to them disappearing into the SP ether.

Am I going to be better off coding an entire workflow engine?

2 Answers 2


The short answer to your question is "No"

Since 2010 is not the most current version out there, and you ask about architecture advice, I would suggest you try to already get rid of your custom actions. There wont be a way for you to upgrade them for the coming Versions.

Instead of those I would suggest that you implement custom web services which will allow you to do the stuff you need. They can be called from the newer versions of the workflow engine also.

For more detailed suggestions your issues are to general and this questions looks like its aimed to start a discussion, which is not the goal of this site, but feel free to ask about the concrete issues you have in your workflows... ;)


I like Heiko's answer, but I'll give a different one: Perhaps. It completely depends on what your workflow is doing. I've seen many shops setup workflows and rig them to run once a night, and process all items in a library. I've had good success converting those sorts of workflows to powershell scripts that are then scheduled. IMO, much easier to create, maintain, troubleshoot, etc. (And these solutions are much easier to migrate to SharePoint online, as well).

But if the issue is "timing", then someone needs to sit down and document the whole process, including what specific things are happening and when, as well as what account each item is running under, etc., to figure out the timing issue. After all, if you take something with a bad logical design and put it in a different language, you just moved your problems, you didn't solve them.

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.