Last week at the SharePoint Information Worker Conference I gave a talk on SharePoint Designer. It was about when and how to use it. After the talk one of the attendees pointed out that I neglected a fairly important topic in the presentation. It’s one that I neglected in my article on the same topic. I was quite disturbed because the topic is so blatantly obvious to me as something I should have talked about that I’m mystified by how I missed it. It’s not like the topic of governance is a mystery to me. My articles (here and here) are a good checklist for the things you should consider when deploying SharePoint but they too are markedly absent of suggestions on SPD. So, here’s a quick discussion that I typically have with my clients.
The topic, as you may have guessed by the title of this post is SharePoint Designer Governance. I talked about what good users for SPD are and what bad uses for SPD are – but I never came right out and made any recommendations for how to put a governance framework around SPD in your organization. So here are my recommendations for SPD Governance:
1) No one is allowed to make master page or page layout changes with SPD in a production area. I’m not going to get into the customized/un-customized debate. Put simply, if you’re talking about publishing, you need repeatability. That is only accomplished by wrapping up SPD changes into Features and Solutions. If you’re going to wrap the changes up into Features and Solutions do it and test the results. Don’t try to make the changes in Dev and then promote the code that you didn’t use into QA.
2) Discourage the use of SPD as an editor for collaboration sites. With publishing sites it is easy to draw a hard line in the sand. However, what about situations where it’s just a collaborative site and the site will go away in a few months? Here you have to educate the user on the issues (for instance, no upgrades) with using SPD but ultimately allow them to do that if they believe it’s necessary.
3) End Users don’t get to create SPD workflows in a large organization, business analysts do. Most larger IT shops have the role of a business analyst or a liaison. These are the folks that are tasked with truly understanding the business and helping IT understand their needs. These folks are often burdened with the reality that there are a lot of issues that IT doesn’t have the time to fix and are closest to the users so therefore most likely to be inspired to fix the problem. Empowering them to make small solutions for their business units is a great idea. The problem with extending this functionality to the end users is that often the end user doesn’t know when something can be created in SPD and when it’s more appropriate to create a workflow template in Visual Studio. There are also training issues, and potential loop issues to be considered. In short, move this as close as you can to the users without directly giving them access.
4) DataView web parts get created on scratch pages or sites and then get exported and reimported. SharePoint Designer’s ability to create DataView web parts is awesome. Its ability to accidentally customize a page isn’t. By setting a policy that dataview web parts will be created and then moved to their production page homes you can minimize the chance that someone will accidentally customize a page and cause issues for upgrades later on.
The primary challenge when looking at SPD roll outs and governance, in my experience, has been a misunderstanding of what the tool does. It’s a data view web part creator, a workflow creator, and an HTML/CSS editor. Many folks think that it’s an enhanced editor for WCM content pages (it isn’t) or that SPD workflows are reusable (they’re not.) Once these two misconceptions are put to bed the perceived number of people who need SharePoint Designer drops dramatically.
SPD is a great prototyping tool and thus a great tool for business analysts. However, it’s not a tool that should necessarily be in the hands of every user.