0

We have a 2013 SharePoint environment for a mid-sized company. I was discussing the need to develop OOTB SharePoint workflows in QA vs directly on production and we disagreed on what was best practice or practical.

My take on the situation was that workflows should be created on QA if they are "complex", meaning multiple steps, anything that involves a custom web service, etc. If a workflow is a few simple steps, like copying an item, sending an email, and pulling in some info from another list, I didn't think it warranted creating the entire structure on QA then copying it over to production for every deployment or change.

I thought it kind of went against the spirit of how workflows are meant to be handled to bog them down with processes for even the smallest workflows.

My coworker felt that the best thing to do was to bear with the pain of recreating each set of lists and workflows even for very simple workflows (with the exception of maybe 1 action workflows).

What do you guys think? If you were in an environment that wasn't too time-pressured, what would you ideally do?

1

Unless you have to deploy a Farm solution or using a visual studio developed components on the SharePoint farm itself, then I would develop it directly on Production. You must have a recovery strategy, for example you backup the site collection (Backup-SPSite) or the entire Content Database (Via SQL).

I assume your production environment will have a Recovery Point Objective (Let us say for 24 hours), then you perform those backups every 24 hours.

  • Thanks for the input. Would love to hear some more opinions on this, too. – user11457 Feb 28 '15 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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