File naming best practises

This is a topic which still crops up regularly so here's my take on it. As a very brief summary:

1. Only ever have one instance of a document, no copies.
2. Keep filenames short and descriptive, using spaces in-between words rather than _'s. No need for initials, 'draft'/'final', or dates (unless the document refers to a specific event).
3. Send links to files rather than attaching copies.
4. Let SharePoint / Teams manage the versions of the document as it's updated.
5. Multiple people can work on a single file at the same time - this avoids mistakes and saves a huge amount of time.
6. Don't forget to apply similar rules to your folders - keep them simple and not too many layers.
7. Plan your folders and file-naming conventions before starting any new work, and share the rules with everyone involved.

If you're interested in the logic behind the above, here's a bit more detail:

Versioning

If you store your files in a solution like SharePoint (or, if you must, OneDrive) then version control is built in - you should therefore use it to get the benefits.

Your goal should be one version of the truth. This means that, in general, there should only ever be one instance of a document and you let SharePoint track changes made by different people. Copying documents leads to duplication and mistakes as people may refer to, or update, the wrong copy; and there will invariably be time wasted with some poor soul having to collate updates from different places.

So, do NOT:

• Copy a file to make updates - update the original
• Add your initials, date you've made changes, or "draft" / "final" to the filename - SharePoint can do all this for you (and when did a "Final" version of a document ever stay final?)
• BAD: "Draft design doc - Oz comments - 3 10 23.docx"

Keeping a single source of the truth (i.e. one instance of any file) will mean that:

• Everyone will easily be able to refer to the latest version
• Any links to the file sent out will always lead to the latest version (not an old copy which has since been duplicated and updated)
• Everyone will have access to previous versions to see who changed what and when
• GOOD: "Octocopter technical design.docx" [SharePoint will provide the version, when it was created, creator, when it was last modified, and modifier]

To help with this, a SharePoint document library (or Teams Files tab, which is the same thing!) can be configured in just a few clicks to include simple Publishing functionality between minor (draft) and major (final) versions of a document.

Naming conventions

So what should we call our files? The filename should simply:

• Let anyone who sees it know exactly what they're going to find if they open the document
• Be as concise as possible, whilst achieving the point above

To underscore or not to underscore? - that is the question!

When we regularly had to work with the full URL (web address) of documents stored in SharePoint, replacing spaces in filenames with underscores was useful so we didn't see "%20" all over the place. However, given that we rarely see the document URL with the modern tools (SharePoint Online, Edge, and Office 365), it's best to keep things simple and just add a space between words.

What about dates?

Dates should generally only be added to a filename if the document relates to something on a specific date, such as meeting minutes or an event. When adding a date, it should be added in 'reverse chronological order'. Using a format of 'yyyy mm dd' will always show your files in chronological order. If you use 'd mm yyyy' it wouldn't (see the image at the top of the article!).

Co-authoring

By using a single file, we can also have multiple people work on a document at the same time - and others will see what you're typing almost as you type it! This is so much quicker and easier than different people working on different copies and someone having to collate all the changes into a 'master' document at the end.

Folders

It's important not to forget your folders when thinking about naming conventions. And here you have to consider structure and access as well. When kicking-off a new project, service, department, or anything else which is going to generate documentation, agree the following with key stakeholders before you start:

• Who will need access to the documents (internal & external users)?
• Where is it best to store them (e.g. a new Team, a new channel in an existing Team, or (rarely) somewhere else)?
• What channel / folder structure do you need? Keep it as simple as possible, whilst providing some structure. Try to stick to a maximum of 4 levels.
• Long folder names can cause issues so keep them short, but descriptive.
• Have you applied the same best practises to your folders as to your files?

In summary, this is not rocket science, but setting some standards and helping your whole team to adhere to them will make for a much easier life for everyone!