On several of my recent projects, the question has come up about the appropriate use of SharePoint Designer 2007 (or SPD) within an organization’s SharePoint installation. The question is sometimes around its role and scope; other times, it’s point-blank: should we use SharePoint Designer? And the question will only get asked more with licensing changes in the offing.
But as every good consultant knows, the answer to any clear yes-or-no question is “it depends.” 🙂
In this case, it really does depend. It depends on how rigid an organization wants to be with its usage policies, how granular it wants to be with its permissions, and how its overall SharePoint install is governed. This post isn’t meant to be a comprehensive up or down answer to the question; rather, I’m simply sharing some of the things we often discuss with our clients when making a decision about the role SPD will have within their SharePoint implementations. If you have experience to share, please feel free to add it within the comments below.
The sections below offer some ideas to consider as you make a choice for your organization or client.
Branding
Everyone wants SharePoint – but they don’t want it to look like SharePoint, or at least not without a personal touch. And the easiest way to modify how SharePoint looks is to crack open SPD and start making changes to master pages, page layouts, etc.
This approach works well in small implementations where a small group (or one!) of SharePoint admins have access to SPD and control the entire environment. However, my suggestion is that it doesn’t scale very well to large enterprises. (It’s not just my idea: see best practice #9 in this MSDN article.) In large environments, there’s often a desire to have some visual consistency throughout the SharePoint site, and the best way to maintain this is through a limited set of predefined master pages and page layouts – items that site owners throughout the organization are not allowed to modify. The best way NOT to maintain visual consistency is to deploy SharePoint Designer to numerous individuals and watch them exercise their powers of design.
In addition to consistency concerns, you should consider the ramifications of customizing (unghosting, if you prefer – the explanation of both is here) pages for your specific situation.
Workflow
Another of the very useful features of SharePoint Designer is its ability to create no-code workflows. These workflows can be attached to a document library and provide a great deal of flexibility. The primary constraints of SPD workflows are that they may only be attached to a single document library and that the author is limited to functionality provided by the available activities. (Note: it is possible to augment the activities available for SPD workflow, and there are some pretty useful CodePlex projects out there – like this one.) (Another note: there’s another less well-understood constraint of SPD workflows around user context. Take a look at this post for details. Thanks, Travis!)
The limitation around attachment to a specific document library is not huge in small organizations, but in large ones it can present a challenge. SharePoint use tends to be viral and usage patterns spread between teams and workgroups as colleagues are exposed to how others are solving business problems. In these cases, there’s no great way for other teams to leverage someone else’s SPD-authored workflow, so multiple copies end up being created all throughout a SharePoint farm – which is fine until something needs to be updated.
My own recommendation for mid- to large-sized organizations when it comes to workflow is to take a careful look at the products offered by K2 and Nintex. These products are reasonably-priced and offer the same ability for users in the community to create their own workflows. However, they also allow the workflows to be managed at a higher level and to be shared across sites, document libraries, etc.
(Note: yes, I know you could write a workflow in Visual Studio, too. However, most people turn to SharePoint Designer because they don’t want to undertake the hassle or cost of development.)
Data Integration
SharePoint Designer has the ability to create web parts that can’t be created using the SharePoint user interface, namely data form web parts. These web parts allow customized presentation of the data from SharePoint lists (or other data sources, e.g. SQL Server). (This site has a nice write-up on the configuration of a data form web part.) In my opinion, this is one of the most useful features of SharePoint Designer.
There are alternatives, however. Products from Bamboo, CorasWorks, and Lightning Tools (just to name a few) provide means for pulling information from outside data sources and presenting it in SharePoint. In Bamboo’s solution, you can actually configure a data form web part without using SharePoint Designer.
Summary
It’s difficult to summarize a product as large as SharePoint Designer (and SharePoint) in a few paragraphs. The issues I’ve presented here are the ones that I end up talking about the most often, but they are certainly not a thorough treatment. However, hopefully I’ve shared something that’s helpful for your situation and provides some context for my recommendations below.
Generally-speaking, my personal recommendation is that small to mid-sized organizations (e.g. those with one or a few SharePoint administrators and a handful or fewer site collections) use SharePoint Designer in a very limited capacity. SharePoint admins can make good use of it, but the organization would be well-served to get them some training first.
For large-sized organizations, my recommendation is that SharePoint Designer not be used in a production environment and that the company ought to rely on other means for putting enhanced functionality in the hands of their users. This means good master page and page layout options for publishing sites and consideration of third-party tools for workflow and data integration.
Those are my thoughts. What are yours?
