by Creating a SharePoint site is quite straightforward, but, if you’re not careful, you can create a lot of problems for yourself in the future. That’s why I’ve developed a series of SharePoint best practices that I’ve learned and found to be useful using SharePoint in various projects in the past.
Everything contained in this article is my personal opinion, so feel free to disagree and adapt any of them to your needs.
The point is not to have a standard that everyone will use, but for you to think and implement one that makes sense to your reality. I will improve it over time, so feel free to contact me and propose topics that are missing. Finally, this article can change over time since I’ll learn new stuff over time, so feel free to come back once in a while because there may be something new. Will all these disclaimers out of the way let’s get started.
Site
Take special care when naming it since it’s something that will be accessed directly by all users. A site’s name can be changed, but its URL cannot so take time to think about it. You need to understand by the URL what is the context of the site without making it too complicated.
Think twice save once
Do you know the purpose of the site? Who will use it? Is it a communication or team site? Created for a random team or a department? Part of a region, country or for everyone?
I recommend that you first know the scale of the company, like how many sites exist and will exist in the evolution of the company (roughly of course) before taking any decision. If it’s a small company, there’s no harm in letting things a little bit more fluent, but if you allow the users to be creative, you’ll have SharePoint sites called Team just because the sales team asked for it first. Having rules is essential, but defining them is a struggle between clarity and structure, so think about it carefully. If there are already some sites created, no worries, start implementing the rules and move or deprecate when possible.
Take the formulas below as examples and make them the SharePoint best practices for your organization.
Example 1 – Global company
[team/communication][country/region][department][objective]
For example:
team-holland-hr-recruitment
communication-global-management-messages
team-europe-sales-numbers
In a big company you can even think about a communication site with a theme being the name of the site, for example, GDPR. But if you don’t make it a little more specific, you’ll end up with questions like, “Is this for everyone in the company or just for people involved in the GDPR process?”. “How about the GDPR team site? Should we use this for both?”. The important thing is to avoid these questions hence having “communication-global-management-gdpr” makes things clear for everyone.
Example 2 – Tiny company
[team name][objective]
For example:
development-plan
hr-payroll
legal-patents
I like this example because it makes things more straightforward as well as organized. The objective can be a project, for example, where the development team has the aim of developing the Project and uses the site to coordinate work and propagate information.
Example 3 – No hierarchy
[team/communication][objective]
For example:
team-gdpr
team-offsite_event
communication-holidays
This example makes things a little bit flatter. The issue is that you don’t know where the source of information. Is the Offsite Event planned by the HR team or Management Team? It’s useful for companies where people organization is fluid, but not suitable for more prominent companies with multiple departments.
No special characters
SharePoint does an excellent job of showing you how it will the URL look like and removing the invalid characters from it.
I recommend that you don’t use special characters. Try making things simple like any other website. This rule can be extended to other areas of the company, so define in your internal SharePoint best practices to exclude them. Special characters don’t scale well in companies that operate in various countries due to regional settings, so keep things friendly and straightforward.
Pick a language and stick with it
I know that this may be tricky for many companies, but for the sake of consistency, you have to follow the company’s business language. If the company doesn’t have one, define one and implement it in your team by including in your team’s SharePoint best practices. Then used the defined one in the SharePoint sites and keep it. Think about navigating a website in English, with French lists and columns in German, and you’ll understand why consistency is essential.
Photo by Glenn Carstens-Peterson Unsplash
Lists
Lists are amazing and an excellent way to store information, but please never consider a group of Lists as a replacement for a database. They serve a different purpose, have limitations, and you need to use them within a reasonably low number of records.
Sacrifice a little bit more characters for clarity
The most important thing is to look at a list’s name and understand it’s usage. If you can’t, think further until you come up with one that makes sense. These names can be displayed in the navigation so creating ambiguity can be harmful to the overall user’s experience.
You can make the name a little bit bigger if it improves legeability.
Try to avoid abbreviations. Include in your SharePoint best practices the known business abbreviations and only use those. Abbreviations can have different meanings in different contexts and location/country. Also, prefer lists names in the singular form, since all lists have multiple records, so there’s no clear advantage indicating that they are multi-record by pluralizing them.
No special characters
Don’t use special characters in the names of the lists. Try to avoid special characters as most as possible. Include in your SharePoint best practices this rule since, when accessing information from other sources, you may encounter encoding issues or other problems that you can easily avoid if you keep the names friendly and straightforward.
Avoid using numbers
Unless you have a strong reason to name a column with a number, avoid it. Numbering may link people mentally to version numbers so if you have something like ‘Company1’ your main though is to think “Do I have a Company2” list? Known numbers are ok, like Office365Users for example, but try to stay away from numbers.
Lowercase is your friend; spaces are not
A list should always have a lowercase name with no spaces. If you prefer to replace spaces with “_” and separate words with “-“to separate each word or even go for camel case naming. Any of these solutions are fine as long as we avoid URLs like this:
https://<site>.sharepoint.com/sites/Test/Lists/Awesome%20List/AllItems.aspx
Much nicer to have
https://<site>.sharepoint.com/sites/MySite/Lists/MyList/AllItems.aspx
The main disadvantage is that the names will show up lowercased in navigation and other areas of the site.
We want our user to see something more helpful, so let’s change it. To do so open the list, click the gear at the top and click. List Settings
Go to the List name, description and navigation.
And change the name to something more helpful.
Save for propagating the changes.
The beautiful thing about this change is that the menu is changed, but the URL stays the same. It can be a blessing or a curse if you’re not aware of it. But now you know, so you’re okay :).
A list serves one purpose
Keep the list only for one purpose or context and try not to mix information. Mixing information under one List makes things harder to understand, so include this rule in your internal SharePoint best practices so that everyone follows the same pattern.
To demonstrate, let’s think about the case of a simple Employee. You’ll have a list with all the employee’s data, but you should have one with the Holidays and another list Payslips. The information is related to the employee, but they have different contexts. Use lookup fields to connect the Lists and data between them. Read a little bit about the separation of concerns and database normalization (again, Lists should not be confused with any databases concept, but you can apply some of the strategies successfully). With this separation, you can have a lot fewer records and avoid duplication of data.
If a list doesn’t serve a purpose anymore, don’t delete it
It can be counterintuitive, but not deleting Lists can prevent a lot of issues. When you delete a List SharePoint doesn’t warn if there are any references, so things break silently. Also, for large corporations, it is quite hard to know if someone is using the list for an app or link, so avoid deleting anything unless you’re sure that it’s not necessary anymore.
Keep the same language as the site
If you create the site in English, keep the Lists in English. It will create consistency in the navigation and the overall website’s look and feel. Having multiple languages may lead to confusion, especially if a user doesn’t speak one of them. It will also keep consistency with the SharePoint best practices described above for the site’s name.
Columns
Don’t use the same name as the list
Having a column with the same name as the List makes things confusing. We want lists and columns to be easily identifiable just by the name, so keeping the name different helps a lot. For example, having an Employee list with an Employee column won’t provide you with a lot of information. What information is in the Employee? The name? The number? The first name?
No Special Characters
Avoid using special characters. Keep names friendly and straightforward and don’t get creative. Keep consistency with the SharePoint best practices defined above for the Lists and Site names.
Avoid using numbers
Avoid using numbers, unless they bring clarity to the name. People tend to link them to sequences so unless you have a strong reason to number something, avoid it. A glaring exception is numbers like Office365, for example.
Sacrifice a little bit more characters for clarity
You have plenty of space to describe your column, so use it. Don’t abbreviate and make the name clear for everyone without the need to check the data contained in the column. For example, Employee can be his/her name, number, first name, or any combination. Naming EmployeeFirstName will make it much clear and unambiguous.
Avoid formula names or types
For example, don’t call the column Lookup or DateDif. Prefer more commonly used names like NumberOfPeople instead of PeopleCount. If you want to refer to the employee’s number, don’t call the column Number but EmployeeNumber. Make things as easy to understand as possible.
Singular and Plural matter
Singular or plural words can be a good indicator that the column supports only one (singular) or multiple (plural).
Aux Columns
Aux columns contain information that serves a purpose other than just storing and displaying data to the user. Use aux columns to make searches faster or to store information that is expensive to calculate. I go deep in this in my PowerApps Delegation article, so check it to see them in action. Contrarily to calculated fields, I prefix it with the usage for the column. It helps anyone understand right away that the column is not to display to the user and what it’s usage. Examples can be:
- search
- prepare
- help
Lookup Columns
Lookup columns get information from other Lists in SharePoint. To avoid confusion compose the name of the column with the name of the list and the value that you’re getting. For example, let’s say that you have a Person list and a Computer list. If you want to have a lookup column in Person that fetches the computer’s ID don’t call the column Computer but ComputerID. Then you’ll know, just looking at the name that you’re getting the information elsewhere and the information that you’re getting is the ID. Include this definition in your own defined best practices to propagate the information internally.
Calculated columns follow the same rules
No need to have a different naming convention for these columns. Name them as you would name any column. These are read-only columns and will allow for changes of its type without the need for significant refactoring of anything that fetches data from them.
Keep the same language as the site and the list
Don’t mix languages in the column’s names. Keep consistency even if the information in the column is in another language. Your defined best practices should be consistent everywhere so follow the same rules for the columns up as defined previously for the lists and the site name.
Prefer lowercase with no spaces
Create columns with the same rules defined for the Lists. SharePoint will generate the URL based on the name, so be aware of this since you won’t be able to change it in the future. If it contains some spaces, it becomes a nightmare of %20 to deal. So create the names in lowercase with no spaces and change it after to something more useful. To do so, follow these simple steps:
Start by going to the options and select List Settings.
Select the column you want to change.
Change the name
The new column name was changed, and it looks more useful than the previous one. Note that the column’s URL didn’t change, so we have a human-readable name and a simple URL.
And voila. Nice references and nice column names.
If a column doesn’t serve a purpose anymore, don’t delete it
Keeping columns that are not necessary is not ideal, but it’s difficult to ensure what will the impact of removing them. Would you break a lookup column? Are you sure that there aren’t any PowerApp using this column? Are there flows running with this column as a reference? If any of the questions was uncertainly don’t risk it. Only remove a column if you’re absolutely sure that there’s no reference to it. Define in your best practices and put some safeguards, like restricted deletion permissions, to avoid that someone deletes, even accidentally, columns.
Have a suggestion of your own or disagree with something I said? Leave a comment or interact on Twitter and be sure to check out my other SharePoint articles
