Overview: Site governance, permission, and sharing for site owners

Subsite creation

You might want your team members to be able to create subsites under the team site for use on specific projects.

Being able to spontaneously create new subsites can be a great benefit to the group, but unrestricted site creation can get out of hand. When subsites proliferate freely, problems can arise. For example:

• It’s hard for users to find the right subsite, or be sure if they have.

• Information can be duplicated in several subsites, using up expensive storage space, and requiring duplicated effort to maintain.

• Out-of-date information can reside on subsites, potentially for years, showing up in search results. It can be hard to tell what version of information is correct.

• Managing permissions for a multitude of subsites can become a major chore, and users might inadvertently wind up with access to information they really shouldn’t have.

• As employees leave the group, the subsites they create may be abandoned, creating confusion and muddying search results for remaining site users.

You can save time and energy if you set some policies for site creation that address the following areas:

• Who is allowed to create subsites?

• Do new subsites need to be approved in advance? If so, what are the criteria for approval, and who grants the approval?

• Should new subsites use established templates and themes?

• How much information may be stored on a site? That is, how much server disk space can it take up?

• What are the rules for including navigation strategies on the site?

• How long should information be stored on subsites before it is deleted or archived?

See Create a site or subsite for more information.

Permissions management

The integrity, confidentiality, and privacy of your organization’s mission-critical information rests on how secure you make your site — specifically, to whom you choose to grant access to your site.

Granting and restricting access to your site is called managing permissions, and it’s one of your most important responsibilities as a site owner.

Here are some tips to keep in mind when you’re developing a permissions strategy.

• Follow the Principle of Least Privilege: Give people the lowest permission levels they need to perform their assigned tasks.

• Give people access by adding them to standard, default groups (such as Members, Visitors, and Owners). Make most people members of the Members or Visitors groups, and limit the number of people in the Owners group.

• Use permissions inheritance to create a clean, easy-to-visualize hierarchy. That is, avoid granting permissions to individuals, instead work with groups. Where possible, have subsites simply inherit permissions from your team site, rather than having unique permissions.

• Organize your content to take advantage of permissions inheritance: Consider segmenting your content by security level – create a site or a library specifically for sensitive documents, rather than having them scattered in a larger library and protected by unique permissions.

See Understanding permission levels in SharePoint or Edit permissions for a list, library, or individual item for information on setting permissions.

Information architecture

A site’s information architecture is like the table of contents for a book: It determines how the information in that site — its webpages, documents, lists, and data — is organized and presented to the site’s users. Information architecture is often recorded as a hierarchical list of site content, search keywords, data types, and other concepts.

To create an information architecture, you must analyze the information to be presented in the site. Here are some of the questions you can use to develop an information architecture:

• What kind of content will you have on the site? How will that translate into subsites, lists, libraries, and so on?

• How will information be presented in the site?

• How will site users navigate through the site?

• How will information be targeted at specific audiences?

• How will search will be configured and optimized?

Part of your information architecture might include classification of information.

If the information you’re dealing with has high value to the company, requires special security, or is covered by regulatory compliance rules, you might want to set up a classification scheme to identify specific types of content that need to be managed carefully.

After you’ve organized information into specific lists and libraries, you can use governance features to manage how the content is managed. For example:

Require check-out of files

When you require check-out of a file, you ensure that only one person can edit the file until it is checked in. Requiring documents to be checked out prevents multiple people from making changes at the same time, which can create editing conflicts and lead to confusion. Requiring check-out can also help to remind team members to add a comment when they check a file in, so that you can more easily track what has changed in each version. For more info, see Set up a library to require check-out of files.

Track versions

If you need to keep previous versions of files, libraries can help you track, store, and restore the files. You can choose to track all versions in the same way. Or you can choose to designate some versions as major, such as adding a new chapter to a manual, and some versions as minor, such as fixing a spelling error. To help manage storage space, you can choose the number of each type of version that you want to store. For more info on versioning, see How does versioning work in a list or library?.

Site lifecycle and retirement

Sites such as document worksites and discussion sites tend to hang around after they are no longer useful, using up valuable storage space and muddying search results. It’s a good idea to set a schedule for reviewing sites and their contents (at least once a year) to see if they are worth keeping.

It’s good to keep in mind, too, that your organization’s larger governance model might also be on the lookout for stale sites. For example, an administrator might automatically delete sites that have been untouched for 90 days. As a site owner, you would receive an email warning you this was going to happen. For more info on lifecycle and retirement policies, see Site closure policies.