In this chapter, I provide an approach to determine which customization abilities are available, and to what degree you can decide to empower your end-users to make those customizations on their sites. I also provide considerations for planning safe isolated user containers that limit the fallout or global impact from suboptimal user site customizations. Throughout the chapter, I point out some of the different customization-related features available to you within SharePoint 2013.

After reading this chapter, you will know how to:

• Empower your users
• Enable end-users to apply custom site designs through Design Manager
• Plan an optimum default site experience
• Delegate access control and site management
• Plan for safe isolated user containers
• Limit the support demands with customizations
• Detect problems with site customizations
• Describe Apps for SharePoint and the role they play for site customizations

Predicting Doom

I am always silently amused when I start a new project and hear about how I need to lock things down to protect the users from some vaguely imagined disaster (well, not so silently any more I guess, thanks to this paragraph). The client seems to have a type of panic based on their speculation and imagined fears of all the things that could go wrong unless they work hard to prevent them. Their rash decisions lead to requirements to lock the environment down as they hope to protect the users from themselves. They try to rationalize this approach by assuring me that their users are different and they need to take this extra step.

“Our users just are not that technical” is a common thing I hear. “They need a lot of hand-holding.” You have no idea how often I hear this. Almost as often as I hear how unique a particular organization is. You are in your own unique place, I have no doubt, and with your own unique culture of users. This is what makes governance difficult, because otherwise you could simply carbon copy a solution. However, you are probably not as unique as you think. To start, I can honestly tell you that I almost never find that the users turn out to be as helpless as IT believes. They also do not usually go out of their way to break things on their sites or on your servers. They usually just want to do their jobs.

Sometimes in doing their jobs, users need to find creative ways to work around IT constraints that they feel make a process inefficient. In my experience, this is the reason behind why they change things and develop workarounds. They are trying to find creative solutions to the problems they face. They are probably not trying to be defiant toward IT (or at least not initially, but after a lot of us-versus-them cycles, their motives might degrade to this). Setting your users loose in a SharePoint collaboration site is not like setting a herd of cats loose in a yarn store.

I am trying to convince you that you do not need to spend your time predicting all the doom that can come if you empower your users. Your users can most likely handle it, and they might even appreciate some flexibility and freedom. Most users will probably not care and will not bother with doing much to their site, but some will. Those who do will unleash value and a positive impact with their SharePoint use. This can also benefit your SharePoint service through positive side effects, such as:

• Increased overall adoption as users can tailor their experiences to meet their needs
• Reduced burdens and bottlenecks on IT for changes and customizations
• Less demand for global applications as users can develop isolated solutions
• Improved user sense of empowerment and support from IT

Your fears may be well grounded, but do they outweigh the potential benefits to the value your SharePoint service can deliver with empowered users? They may do things that require a support ticket to help them back out of whatever they did; but do not let this potential support ticket cause a moral panic on your team. Without the ability to do things, different types of support tickets still come up, so locking down your users would not be saving much. This would only be an illusion in one’s support ticket moral panic, one that can lead everyone to convince themselves that if they do not lock things down then there will be an overwhelming tsunami of support requests. I hope I have succeeded in making you aware of some blinders that people can put on, and so you can now avoid making rash decisions based on moral panics, such as fears of support tickets.

I try to avoid predicting doom and thinking about how bad we expect users to mess up their sites. Instead, I try to focus on how I can empower the users in a safe and sustainable way. If you set up things well, you can steer users in the right direction and help facilitate how they manage their site with a minimal support impact. This chapter can give you some tips on how to balance the amount of control you put in the hands of your users with the ease of how supportable you can keep their sites. It all starts with deciding to what degree you will empower your users.

Empowering End-Users

SharePoint provides a rich tool that you can empower users with taking charge of their own sites. Microsoft designed SharePoint with this ideal of empowerment in mind. This means that if you follow the philosophical design of SharePoint, then your users can manage their own needs, and in their own time. Now, as much as I like to put the control of things into the hands of empowered users, I also recognize that this is not as easy as it sounds. Not only that, but I appreciate that this approach might not fit everyone’s situation. If it does not fit your situation, you might want to skip this section and jump right to the sidebar where I describe how to lock down your site.

Empowering your users can range from simple activities, such as creating new lists and libraries to manage their content in, all the way up to more complex aspects of managing a site, and everything in between. It is not a binary on or off, yes or no option. It does not have to be all or nothing; you can empower your users to whatever degree you feel comfortable with and to what you find appropriate for your organization. The following lists some of the different areas you may empower your users with, either in some of these areas or in a combination of them.

• Manage site membership and permission levels
• Create content containers such as new lists and libraries
• Purchase Apps from the SharePoint Store
• Add Apps to the site homepage
• Close or delete the site
• Build custom workflows
• Construct custom design packages
• Deploy user solution packages
• Activate and deactivate site features
• Change the site theme, title, and logo

If you think of empowering users in a site as a continuum of options and combinations that you can make available, then you can also think of those options on a continuum as well. One example of this continuum is the site design and user interface look and feel. For the more advanced users who possess the relevant skills, they may want to thoroughly customize site pages using a tool such as SharePoint Designer or Adobe Dreamweaver to match a particular brand for their group. Meanwhile, for other more basic users, branding and HTML may not be within their skillset and it may be over their head. Some of those basic users probably would still enjoy the feeling of changing the look of their site. Figure 13-1 shows one option for changing the look of a site, which provides a simple interface where users can click on one of the visual previews to apply that design to their site.

Providing your users with these capabilities enables users to make their site feel as if it is their own. Whether this is as simple as selecting site themes from a finite list of branding options, or if you want to allow them to use the site Design Manager to create their own composed looks, empowering them with options can go a long way toward user adoption and overall satisfaction.

You have several choices about what you want to enable to empower your users. Again, this can be along a continuum, rather than simply on or off. For instance, you might allow them to add Apps to their site, but not allow them to purchase Apps from the SharePoint Store. You may allow them to purchase Apps from the SharePoint Store or add any from your internal catalog, but you may not allow them to upload and deploy user solution packages. On the other hand, you may allow them to do all of the above. There is no single correct answer.

How do you determine the right tolerance and balance for how much to empower your users? Let me first say that I generally default to wanting to empower my users with more freedom rather than restrict them. I then work my way back from this open and empowered default to add more restrictive settings based on a few considerations. I usually work through the following decision considerations when I am determining how much functionality to enable to empower the users:

• Is there a security or privacy requirement for a more restricted site?
• Does any other compliance or regulatory requirement depend on a more restricted site?
• Is there a lack of experience with SharePoint in the organization and a general desire to start with more restrictions until the SharePoint team feels more comfortable?
• Does the infrastructure have enough capacity to handle any additional load for customizations?
• Is the type of site one that does not lend itself well for ad hoc changes or customizations?
• Does the IT department have available resources to provide site management services?

You do not have to empower your users with all the capabilities available to a typical site collection administrator. However, you do have to decide and then take the actions to implement and govern your decision. I encourage you to consider it rather than simply dismiss the idea, but once you have thought it through then you are ready to put a box around what aspects of the site you will enable, and which ones you want to lock down and restrict.

Planning Default Site Experiences

Teams within Microsoft, and I am sure countless other software development companies, work hard to plan the optimum default experience for users — the out-of-the-box settings and layouts that will provide the starting point for users. These defaults translate into how the majority of users will use a product, and this is especially true for those users who are new to the product. As such, you need to set the default so it helps to make those users productive with the software by ensuring the core of the features are accessible and discoverable.

A default provides everyone with a consistent base, a common place to start from and a common way to meet the majority of your users’ needs. It also simplifies the process for creating the training materials that you need, because you can use processes and include screenshots based on the default experience. This offers the newer or less technical users detailed direction on how to accomplish tasks, while the more advanced users can translate the training to fit whatever customizations they have introduced to their sites. Notice that this is the same process that technical reference books take. For example, in this book, I have used screenshots from a default SharePoint 2013 team site. Even though I suspect that your site might not look the same as the default anymore, I know you at least started with the default and so I can be confident this will be familiar to you.

I find the trouble comes when teams blur these two different types of users when they try to make a policy about how much they will empower users with at the site level. Sometimes I see clients merge the two needs and go with a more restrictive policy where they lock down the site and enforce a basic experience. My approach is quite different from this, as I prefer to separate the two types of users and consider their needs independently. For the basic users, I focus on planning a default experience that will address the majority of their needs. If you get the default right, most users will not have any need to go beyond that, and so you will not need to worry about all the ways that you need to lock down things in the site. Hence, this why the default is so important and why it demands so much planning and thought.

For those advanced users, I like to leave the ability available for them to manage and adjust their sites as they see fit. I hold a general philosophy that IT operates best when it is in the business of providing value and acting as a strategic partner to the organization, rather than having IT get in the business of policing or restricting the organization. Your situation might be different, so I am not offering this as a golden rule, but I am stressing it because I find this philosophy works well and I want you to make an informed decision.

By default experience, I do not mean that you should create a template and add a bunch of web parts to the homepage. I also am not saying that you should create a document library with a bunch of empty folders that you want users to organize their content. Users do not need that much handholding, and this design strategy almost never works out. From my experience, a hierarchy of empty folders confuses users and makes a site difficult to use. A better solution is to focus on a metadata strategy rather than a folder structure, because this allows users to organize the content in whatever way that makes sense to them while also maintaining consistency through the content’s metadata.

In a similar fashion, I find that adding a bunch of web parts or Apps to the site template will only crowd a site and it can be equally as confusing for users. It can be too much for new users to take in all at once, and this can confuse them or leave them lost with how to use the site. Not only that, but it almost always leads to bloating the site with a lot of unused features that someone added to the template. I see people add features to a template because they think they will be helpful or add some level of consistency across the organization, which sounds nice in theory, but in practice, it rarely ends up being the case.

Forcing a bunch of Apps and features on every site template does not save time nor does it benefit your users. This way of thinking about site and template design is antiquated and limiting. I prefer to focus on providing the simplest experience with easy ways to activate different functional aspects that a user might need. I make these experiences available for the user to provision or activate on-demand, which means my users do not have a lot of empty folders or crowded pages with unused Apps. Instead, the result is simple, clean interfaces that users can build out and tailor to fit their needs.

SharePoint 2013 provides a wonderful example of this approach. If you look at the screenshot in Figure 13-2 of a default team site’s homepage, you can see how simple and clean the interface is. The product team did not over crowd it with different things as the SharePoint team site templates have in the past. The team site template used to include a Task list, a Shared Documents library, an Announcements list, and the like. This resulted in a majority of the sites containing an empty Task list, for example. As you can see in the SharePoint 2013 default team site, they made this option available as a sort of wizard or easy button in the Getting Started App, and as a result, all the sites do not end up polluted with unused containers, while users who do need a task list can easily add it to their site by clicking the “Working on a deadline?” tile.

I think the SharePoint 2013 team site template provides a great example to model for the default experience you design. Rather than bloating a site with a bunch of unused and useless things, keep it simple and expose an easy way for users to add or activate what they need. This keeps sites relevant and it offers a way to guide users into the available features of the site a little bit at a time, as they are ready to expand and add more capabilities. A SharePoint 2013 team site implements this strategy through the Getting Started App, which includes several tiles for different actions that site owners might be interested in to customize their sites. You can use the Promoted Links App to implement a similar concept with your own tiles, and you can link each to a different action to activate or enable an aspect of the site for your users.

With the right default site experience and a clear path of least resistance, you can balance the needs of both your basic users and your more advanced users. The basic users can use sites without being overwhelmed with functionality that they do not understand, while at the same time, you do not constrain and limit the advanced users from customizing the site to fit their specific needs. For both sets of users, you can provide a functional site that fits their needs. Part of how you provide a site to meet the needs of both types of users involves how you delegate management and control of the site.

Delegating Access Control and Site Management

SharePoint has always provided a site model where you can delegate the site management and access control to site administrators. When you create a new site, SharePoint requires that you identify one or two site collection administrators, and they become the ultimate authority for the site and any sub-sites they create within the site collection. SharePoint grants site collection administrators to have full control of every site in the site collection, including the ability to delegate site administration or other site management privileges to other users. This enables you to effectively delegate the security administration to site collection administrators, who can then also delegate security and management at a more granular level.

Just because you can, this does not always mean that you should. Delegating security management to ordinary business users can be both a blessing and a curse. It certainly puts the control within a click of their mouse and allows them to grant permissions to provide access when they need it. However, it also puts the control within a click of their mouse – within a click of a non-IT administrator who probably does not have much experience managing security groups and permissions in an enterprise setting. Now, all of a sudden, you are throwing a site at them and expecting them to manage the security in a way that experienced IT folks have been doing for years. SharePoint 2013 simplifies the process of managing site groups by using more common terms for regular users, such as sharing the site rather than managing permissions.

One problem with assigning a user as a site collection administrator is that they then have full control throughout the site collection. This means that they can perform a range of site management tasks from adding users to deploying customizations. You may have times when you want to delegate site collection administration to site owners, but you might not want to grant quite as much privilege as what a default site collection administrator role includes. In those cases, you can create a custom permission policy level at the web application level to deny the privileges you want to restrict, and then you can assign that policy to the site collection administrators.

For example, if you want to deny the ability to perform custom design tasks on a site for your site collection administrators, then you can create a custom permission policy level on the web application that denies these permissions. You can create this policy level by navigating to the page where you manage web applications in SharePoint Central Administration. On this page, select the web application for which you want to create the policy level, and click the Permission Policy button in the ribbon. This button pops up the Manage Permission Policy Levels modal window, which looks similar to the one shown in Figure 13-3. If you click the Add Permission Policy Level link at the top of this window, you can specify the details of the custom permission policy level. In this case, I named the permission level “Deny Design” and checked the Deny checkboxes next to the design-related permissions.

Once you have created the desired permission policy levels, you can then click on the User Policy button in the ribbon to assign the policy to users or groups. Deny policies will override anything else for a permission, which will effectively enable you to fine-tune how much access and the degree of site management that you want to delegate to your site owners and site collection administrators. You can experiment with some combination of the different permission levels at the site level and through the web application’s user policies to find the best mix for your particular needs.

After the site collection administrator, a SharePoint site contains groups to organize users within to grant them the group’s permission level. By default, SharePoint provisions three groups for a site: the site owners, site members, and site visitors. These groups provide full control, contribute, and read-only permission levels, respectively. Site groups can provide an intuitive way for regular users to manage security without having to get involved with setting individual permissions. This simplifies the security administration while it also organizes users into different groups in the site, depending on their role.

By default, any child site you create in a site collection inherits the permission settings and site groups from its parent site. This default provides a clean and simplified way to manage security across a site collection. However, you may have times where you do not want to have a child site share the permissions of its parent site. For instance, if you create a team site to share information and collaborate across an entire team, you might then create a child site for a specific working group within the team. You might break permission inheritance for that site to grant contribute permissions only to that working group rather than the entire team. You might also want to create a child site only for the managers on the team, in which case you would break the security inheritance and grant permission only to a SharePoint site group for the managers.

Breaking site security inheritance can quickly become a mess and difficult to manage if your site hierarchy grows to any complexity within the site collection. I try to avoid these types of deep layers of sites within a site collection, but if you do need them, then I try to ensure that they will be manageable through a careful design of the SharePoint site groups you will need to manage the different sites. This can help keep the site permissions centralized and orderly throughout the site collection, but the site owners may need your help to think the group design through and to implement it in their site collection.

You do not have to use SharePoint site groups strictly to manage site permissions. You can use group membership to target content to a particular audience, such as if you only want to show an App on the homepage to a particular group of users. With these types of groups, you can configure them to allow users to self-join by adding a link to the homepage or some other way to allow users to easily manage the content they want to subscribe to or unsubscribe from being targeted to them. Delegating group membership to the individual group members themselves is another way that you can ease the administrative burden for managing a site’s membership, but this will not be appropriate for all sites.

One example of a site where you might want to delegate the administration of the site’s group members is a community site. For a community of practice, the site provides a collaboration environment for members interested in participating in the topic. A SharePoint 2013 community site provides community-based discussions for community members, but you might want to expose a self-forming and self-managing community site on a wiki or a team site instead. To enable users to join and leave the site, you can configure a site group with the option to automatically allow members to join and leave the group. Figure 13-4 provides an example of a group configured with these options.

SharePoint provides many options for delegating site management and it offers different levels of permissions that you can delegate. Because a site collection provides the main container for sites and their management that you then delegate to users, the security model also revolves around site collections. This allows you to delegate a range of administration duties at the site collection level for site collection administrators. These administrators can then further delegate management of individual sites within their site collection, but those sites will share common site collection resources that the site collection administrator will have to manage. Since site collections are isolating containers, they provide an effective way to delegate administration, but they also provide you with a way to isolate anything contained within those sites. In the next section, I look at how you can use site collections as a container to isolate any customizations from affecting the rest of your SharePoint service.

Planning Safe and Isolated End-User Containers

If you decide to empower your users by giving them the option to customize their sites, then you are going to want to ensure that you give them a safe and isolated area for their customizations. For instance, you do not want them to interrupt service for the entire farm by over consuming resources, and you certainly do not want them to make changes that conflict with other users. The answer to isolation is a site collection.

I prefer a site design that distributes users and content across many site collections rather than structuring a deep hierarchy of sites and child sites within just a few site collections. I like the design with many site collections for several reasons, and using a site collection as a container to isolate users and their customizations is one of those reasons. SharePoint uses site collections as the main boundary for content and security, so they serve as a natural container to use in planning your site designs for isolation and delegation.

A site collection provides an area to allow users to manage their site experience as they see fit. It allows them to do this without having to worry about overlapping with other users or experiences. This segregation of site customizations can take the form of site visual designs or custom applications such as workflows. It can also simply provide a space for how they organize Apps for content and how they want to display web parts on the welcome page. As I mentioned earlier, most users will be happy with whatever the default is, so for them the site collection is simply a container to help them organize their content. It will also help keep them safe from users in other site collections who want to customize their sites.

You do not have to set limitless boundaries and allow the site to go in whatever direction the users want to take it. A quota can help set boundaries for overall resource usage — from the amount of disk space the site consumes for its content to the amount of server resources a user solution can consume each day with its processing. Quotas transfer any enforcement of the site’s boundary for SharePoint to manage and monitor. When a site reaches a quota limit, SharePoint can lock the site and alert a site owner that their site has reached its quota threshold.

Using quotas allows a SharePoint administrator to provide space in a site collection container without having to consume him or herself with the details of the site’s implementation or to consume him or herself with micromanaging how users use their site. I do not consider quotas as a tool to limit or restrict users; instead, I prefer to think of them as a tool to manage growth. Rather than letting a site grow aimlessly unbound, a quota offers a system-enforced point to review the site and decide whether to apply a new quota or not.

Quotas can offer you a checkpoint when you or your team can review a site and its usage. During this review, you can confirm the users are using the site appropriately and offer any coaching for areas that you find the users could be more efficient. I try to set a quota threshold so it is big enough to give users some freedom to do things with their site without having to constantly burden IT with requests to increase their quota through insignificant quota levels. I want a threshold where I do not have to care how efficient users are being with their sites—they may not set things up as perfect as I might prefer, but below a certain level I am not concerned about their overall efficiency.

For lower usage and smaller sites, they will consume little total resources, even though they may not be efficient with the marginal resources that the sites do consume. As their overall resource impact is minimal, I generally find they are just not worth my time until they grow to a certain size — usually the same size that I set the default quotas to. I usually adopt the philosophy that I cannot scale if I get caught up in the details of every little site and that I will be most effective as a SharePoint administrator if I focus my efforts on the largest or most heavily used sites. By using quotas, SharePoint can let me know once a site reaches a size that interests me (if a site ever does actually grow to a size of interest, since most sites probably will not).

You can set quotas directly on an individual site collection, but this approach will prove unmanageable once the number of site collections grows to any significant number. A more manageable approach is to create quota templates and assign those to site collections. With a quota template, you can adjust the quota size and it will automatically change for all the site collections. As you increase the size of a quota for an individual site collection, you can assign a different quota template with a larger quota size to continue linking all site collections to a quota template. Figure 13-5 shows a screenshot of the Quota Templates page that you can find in the Application Management area within SharePoint Central Administration.

Site collections can also exist in their own content database, which helps you isolate it even further. For example, when you allocate a site collection in a dedicated content database, you can set a schedule of frequent database backups for just that site. This dedicated database option might offer a handy solution for a site that end-users are prone to breaking, because then you can offer a range of point-in-time options to restore their database and rollback their site. It will also give you the option to implement any other unique database configuration or schedule requirements for a particular site.

In short, site collections provide a level of isolation between groups of users and their customizations. Quotas provide boundaries for those site collections so that they do not grow excessively and over consume significant amounts of system resources without you noticing them or at least being able to contain them. This can help you to provide a SharePoint service to diverse sets of users without having them conflict with or affect each other. Nevertheless, even after isolating sites and setting quotas, you may still need to take further actions to limit the support demands from user customizations.

Limiting the Support Demands of Customizations

The biggest objection I hear against allowing user customizations relates to a fear of a perceived tsunami of support calls. As a result, I find the first, and probably the default for most SharePoint teams, is to look at how you can restrict your users to protect them from themselves. The logic seems to follow the idea that if they let users customize things, then those users will mess everything up and overwhelm support with requests to repair the damage. These fears may be true, so it is not for me to quash. Even still, I usually find that the support burden does not have to be gigantic, and you can manage this by setting the right expectations about what you will support.

Just because users make a mess of things does not mean you need to help them continue on whatever path that they were heading before things became so unmanageable. In fact, I suggest the opposite, and here’s why: if you constrain your users too much, then they will either find a workaround that circumvents your restrictions, or they will take their business elsewhere, such as by using a free cloud solution. Either way, this could end up causing you more grief in the long-run than good. One can quickly go crazy trying to predict all the ways they need to lock down and constrain their users.

Imagine a dam with a reservoir of water behind it that just wants to flow through, water that is even starting to leak through in spots. Rather than look at all the ways you can plug each of the holes in the dam, look at how you can let the water flow in a controlled way to relieve the pressure on the dam. Similarly, I look for ways to enable users and their customization needs to flow through the system in a sustainable way. This approach helps you avoid sweating the small stuff, and it allows you to focus your attention instead on the more important or strategic stuff.

If you are worried about the volume of support that allowing customizations will generate, then perhaps you should revisit your support policies. You can limit the fallout and support burden by limiting what you support. For example, an approach that I prefer is to set a support policy such as a Service Level Agreement that defines the extent and limitations of support your users can expect for any of their customizations. If a user messes up their site, your support policy might be to reset the site to its default state and reapply the default master page. This would return them to a workable and supported state, which is usually a state where users can be productive collaborating on their site.

Users may not like a support policy that simply undoes any changes that broke a site. They may not be satisfied with a site restore to an earlier point-in-time or reverting any customizations to the default site template. Their frustration probably comes from wanting to do something but they lack the skills or knowledge required to accomplish the customization they desire. They may express this frustration to you if you only offer to undo whatever progress they feel they have made. In this case, I find the ideal solution is to offer a chargeback service to troubleshoot and rework their design or developments to help them reach the customization solution they require.

As an alternative to providing the chargeback service from your team directly, then you might consider offering the site owner a list of preferred SharePoint professional services vendors that they could contract and work with to redevelop their customizations. This is an especially useful option if your organization is not set up for chargebacks. I would avoid taking ownership of the problem without a funding sponsor, such as those that I considered in Chapter 12, since this would effectively circumvent your sponsorship requirements and introduce a loophole in your demand funnel for customization projects.

As long as their customizations are contained, the support demands will be relatively contained. A special challenge presents itself with user solution packages, also referred to as sandboxed solutions. These can contain code that executes within the SharePoint farm, and if you enable the option, users can deploy them unchecked and untested to their site collections. The risk can amplify if the users begin to share these solutions to other site collections. It is only an issue for poorly developed solutions and does not mean that you should simply disable the entire option for user solutions. Most solutions will probably work just fine, and so it might be an overreaction to disable the option for everyone just because a few may cause issues.

If a user develops and deploys a poor solution that constantly consumes their available daily quota because they coded their solution with inefficient code, you can choose to block and disallow the solution from executing. This can be a particularly valuable option when one group develops an inefficient solution and then tries to distribute it to several other groups. You can set the solution as blocked, which will prevent sites within the farm from activating and using that specific solution. It may seem like a drastic step, but it can be a necessary one sometimes. You may want to block a poorly built solution to force a group to improve it before they start spreading it around the farm. Figure 13-6 shows a screenshot of the Sandboxed Solution Management page found in the System Settings area of SharePoint Central Administration where you can block a user solution.

Of course, you can go the route of locking down all these options and steering your users toward creating or purchasing SharePoint Apps instead. Disabling and restricting options can be prove difficult in many cases, because Microsoft designed SharePoint with a distributed and delegated model in mind. They provided several options to disable features on sites, but it is still not perfect, especially at the granular level. I generally find taking an approach of setting restrictions can lead to complications and it will add complexity to your SharePoint service. My best advice is to start slow rather than overreact, and where possible, implement the restrictions through permission policies on web applications or through service application permissions. However, even with the best plans and restrictions, problems may still arise.

Understanding Apps for SharePoint

An App for SharePoint is a self-contained piece of functionality that end-users can add to their site. Site owners can discover Apps through different catalogs, depending on the type of App and its source. SharePoint sites come with a number of default Apps, such as a document library or survey. In this case, the App provides the list or library definition, and you can see which are available to add to a site by navigating to the Site Contents page and then clicking to add an App. You can also add additional Apps for different types of lists and libraries by activating the appropriate SharePoint site features.

You can find Apps in other areas as well. This is where I find the concept of Apps may seem a little confusing at first. An App can be more than simply a list or library; an App can provide functionality and it can even integrate with another system. You can find these other types of Apps in different catalogs, such as by activating a feature and adding it to the site catalog. The other possible catalogs for Apps include your organizational catalog and the SharePoint Store.

Your organizational catalog enables you to provide a catalog of any custom Apps you make available to the entire SharePoint farm and any other farm that shares the catalog. This offers a central and well-known directory location for users to discover relevant Apps that are available for them to add to their site. Typically, these will include those custom Apps that address needs or fit with processes specific to your organization. This catalog also tracks licenses and requests for Apps that site owners have requested for purchase from the SharePoint Store for their site.

The SharePoint Store is the public marketplace hosted by Microsoft, and it contains Apps from different vendors. This provides a convenient way to purchase add-ins to enhance or extend sites in your SharePoint deployment. It simplifies the entire procurement, development, and deployment process with a low-risk approach to adding new functionality to SharePoint. It also puts a range of different custom Apps in the same directory to make it easy for site owners and SharePoint administrators to discover what custom functionality is available.

Apps allow site owners to add functionality to their site without any IT involvement or intervention (although, you can configure the SharePoint Store so that site owners can only request Apps rather than purchase them directly). These Apps empower the site owner with controlling the life cycle of the App where they can add, remove, or upgrade it on their site. This can provide a convenient way to delegate the decision-making of what functionality a site needs to the site owner, while also isolating the change to just their site and minimizing any compatibility risks.

Consultant Comrade

For me, the most challenging aspect of end-user customizations from a consultant’s perspective has been in helping my client get past any mental block against the idea of empowering their end-users. Sometimes this is a non-starter and they do not even want to discuss the idea. Their support staff or their SharePoint team is often too lean and is spread too thin, and so they do not want to risk allowing anything that will end up being a further drain on their scarce IT resources. They may have other reasons, such as wanting to maintain some abstract idea of a consistency across sites, but the end result is the same: they do not even want to discuss the idea of empowering their users.

Unfortunately, locking down their SharePoint implementation just might be the direction things will have to go. I say unfortunately because there is always a danger of lost opportunities or overreacting in making such overarching decisions if they have not thought them through. They could be limiting themselves and their users without even realizing it. Be that as it may, in the end I still support their decision and help them achieve the implementation they want, even if that means constraining their SharePoint service when I think they have a greater opportunity to take a more open approach. In these cases, I tend to note my recommendations to take a different approach, but I accept that they are the ones who have to live with their SharePoint environment.

I must admit that it can be difficult to accept and support a client’s decision when I suspect they are heading in the wrong direction. As their consultant and the expert they brought in to guide them, I feel a responsibility to always steer them on the correct path. However, they own the decision and I am merely there to advise. It can be easy for me to embrace the idea of empowering end-users and creating a user experience that allows them to manage their own needs, but I am also an expert with SharePoint. My clients may not have the same confidence-level in their ability to manage an environment such as how comfortable I would feel, and so they may not be able to see the same opportunities that I see.

Sometimes the idea of putting control in the hands of end-users is simply too big of a culture shift; it would lead to what I refer to as a breakthrough improvement rather than an incremental improvement. A breakthrough improvement occurs where you attempt to make a major change all at once, whereas an incremental improvement seeks to make continuous improvements in smaller yet frequent steps over time. I first mentioned this idea of continuous improvements in Chapter 7 when I looked at creating a roadmap for your SharePoint service. Then, as now, I prefer to make a series of smaller steps that continuously make or introduce an improvement in a system, but I hold the same idea when it comes to changing a culture. Rather than try to make a giant change all at once, I look for ways to introduce a series of smaller changes and continuous improvements that will take the culture in the intended direction.

Accordingly, if you are trying to guide your client toward empowering their users and you find your client is resisting, then perhaps you are trying to introduce too big of a change. Perhaps you are trying to make a breakthrough improvement in their culture and instead you should consider introducing an incremental improvement. The following lists a few areas that I have found can provide a start in a more empowering and delegated direction:

• Allowing users to manage the membership and permissions for their site
• Allowing users to control the layout of their site
• Allowing users to change their site’s visual theme and apply composite designs
• Allowing users to provision built in SharePoint Apps, such as lists and libraries
• Allowing users to purchase Apps from the SharePoint Store
• Allowing users to design and build their own workflows

Each of the items in the preceding list might be a big enough step for your client. I may take them all and more for granted as simply being a part of SharePoint. However, for someone new to the SharePoint paradigm, they may need to start smaller and build their comfort-level with the culture-shift this may entail. I try to step away from focusing on wide-reaching implementation constraints that seek to lock down everything and focus instead on individual capabilities that we can provide users. This strategy usually helps move stakeholders away from making blanket decisions based on a fear of the unknown.

The other strategy I use to try to break down some of these barriers and mental blocks is to deploy a pilot environment of SharePoint as soon as possible. I find that the sooner we get working software in the hands of users and stakeholders, the better. For me, this always seems to help them work through their perceptions and fears better than a series of meetings debating the details. It also provides an opportunity for actual end-user feedback on their experience and what they find valuable. We can monitor how they handle any empowerment and their overall ability to manage their own site, and this can help to resolve misconceptions or false perceptions. Ultimately, by putting working software in the hands of users, I find we can consider actual usage and feedback, and this can provide a balance to those more theoretical meetings.

Inside Story: Notes from the Field

Some time ago, I worked for a company where the majority of my users were software engineers — developers who built software for a living and who wanted to have the ability to develop and customize anything in their SharePoint site to fit their needs. You might not face quite the same degree of demand for site customizations, and I have not faced it since. Having so many developers form such a large proportion of the company, and thus my user base, presented an interesting scenario: I wanted to leverage their skills and potential to customize the SharePoint experience to whatever opportunity they imagined, but at the same time, I needed to protect and ensure the long-term stability of the SharePoint service.

Primarily, I did not want to get in their way or limit them. My company included a lot of software engineers, and most of whom had much more expertise and practice in software development than me, especially when it came to certain low-level areas deep within the system. After all, not only was I involved in less development activities, but most of my software development in recent years involved C# and Microsoft .NET, which abstracts away many of those low-level implementation details. I wanted to take advantage of this creativity and expertise so that they could tailor their own experiences to fit with how they wanted to work and not feel constrained by the default.

My objective was to empower developers to build whatever utility they wanted and to try my best to not constrain or limit them. This strategy would help me for two reasons: it could take the pressure off my scarcely resourced team from having to process enhancement requests, and it could drive user adoption. My team simply did not have the available capacity to offer any sort of enhancement, particularly at the individual site level, because we were already spread too thin. I wanted to leverage these developers throughout the company who had availability capacity and who wanted to build enhancements. Through this approach, I had the idea that empowering developers would help drive the overall adoption in a similar fashion to how Microsoft leverages developers in the community to enhance and drive adoption for their products.

Historically, Microsoft has had success in overall market adoption with many of their products because they empower independent software developers to build on and enhance a product. Of course, much of Microsoft’s success for a particular product comes from providing a great product, but by allowing and even encouraging developers to build solutions on top of those products, then these solutions made Microsoft’s products even more compelling. Microsoft is not able to efficiently scale to tailor each of their products to fit every customer’s way of working; instead, they provide a generic product and Microsoft partners can specialize and build solutions to meet individual needs. By following this model, I wanted to focus my team on providing the core SharePoint service, and allow other developers and groups to customize discrete sites to meet needs that are more individualized.

The key was to enable customizations at the site collection level, and to do so without causing an impact on the rest of the service. I needed to use the site collection as a container—one that I could delegate to a group to manage and customize as they saw fit. The challenge was that we were using an earlier version of SharePoint, one which did not have the capabilities of SharePoint 2013 that I mentioned in this chapter. User solutions, also referred to as sandboxed solutions, were not yet invented and available. User solutions later formed the essence of how I achieved this goal, and they continue to provide an excellent solution to empower developers to customize individual site experiences with rich features and functionality.

In those early days on SharePoint, before user solutions became available, an easy option was to encourage developers to find ways to use the Content Editor web part to wrap another HTML page in a frame they could embed on the page. I had to encourage these types of workarounds to limit the number of customizations and components I had to deploy globally on a farm. When embedding the functionality in a frame on their site page would not achieve what they needed, then I would work with them to design a solution we could deploy in the Windows IIS directory rather than to the Global Assembly Cache (GAC), and this would allow me to apply a restrictive .NET Code Access Security Policy (CASPOL). Essentially, with this approach, I could restrict and contain a customization to some degree, but user solutions later superseded this implementation complexity.

The reason I am so fond of user solution packages is that they encompass all the complexity of isolating and restricting code execution. As I mentioned earlier, they also have a quota system that you can use to set boundaries around the amount of server resources that you will allow a given site’s user solutions to consume. This is all great stuff, but my personal favorite feature is the ability to select the servers on which to execute the code within user solution packages. You can dedicate one or more servers for this role by starting the “Microsoft SharePoint Foundation Sandboxed Code Service” on the Services on Server page in SharePoint Central Administration. You can then stop this service on other servers and effectively isolate where this code executes and you can contain the available server resources for code in user solution packages to consume on specific servers.

SharePoint Apps are wonderful; and I think with SharePoint 2013 introducing them, they will augment and provide additional ways for users to customize their sites. User solution packages (and farm solution packages for that matter) will still play a vital role in adding and extending functionality in a SharePoint farm. As long as the SharePoint team maintains user solution packages in the product, I will continue to enable them when I need to empower my end-users with abilities to develop their own solutions for their site.

Wrapping Up

In this chapter, I discussed how you can facilitate end-user customizations and how you can isolate those customizations so they do not have a negative impact on the performance of your SharePoint service for other users. I looked at how to empower your users in a safe and contained environment so that they can adapt and tailor the service to meet their needs without introducing an unnecessary burden on support.

Although you can enable your users to customize much of their experiences and capabilities in their SharePoint sites, at times they will require a more extensive solution that will extend beyond the safe containers of their SharePoint site. This may include developing and deploying custom components that you need to make available across the entire SharePoint farm. In the next chapter, I discuss how you can design development standards and testing processes to help reduce the risk involved with deploying custom components.