Best practices for file-naming conventions?


  • Our company is considering the institution of a standard convention for filenames for all documents posted to our SharePoint document libraries.  (SharePoint is being used as our Intranet.)

    For example, we might require the file name to mimic a portion of the path, such as Americas_HumanResourcesDept_Forms_AnnualVacationRequest.doc.

    Answers to any of these questions would be useful:
    1. Does your company/organization have a preferred file-naming convention?  If so, what are some important components of the file name?

    2. Have you been successful in getting users to follow the file-naming conventions?
    3. What are some benefits of having a convention?  For example, do properly named files result in better ability to Search?
    4. What are some best practices related to file names.  For example, users should avoid the use of spaces in their filenames.

    Thanks in advance for your advice.
    Friday, October 17, 2008 3:02 PM

All replies

  • Hi,

    The key to searchability and ease of retrieval is the use of attributes-Metadata (WSS columns); the filename per say is not really a useful way. That's the added value of WSS; the ability to add data about the document.

    If I take your example: Americas_HumanResourcesDept_Forms_AnnualVacationRequest.doc, this is how I would map this to WSS strenghts.

    Americas - Probably a Region column
    HumanResourcesDept - Probably a Department column
    Forms - A document library
    AnnualVacationRequests - Requests could be a sub-folder or Forms, Annual Vacation can be a Content Type that holds the Region and Department columns (plus additional standard info such as Date Created, Last Modified, etc.). Content Type could also be at the Requests level (if there is more than one) or even at the Forms level.

    Hope this helps,

    DJ Lordee

    Friday, October 17, 2008 9:28 PM
  • I'll back up DJ Lordee.  Putting intelligence into a file name is more likely an anti-practice.

    To capture that information, look into content types.  I can post some good links on that subject if you want.

    --Paul Galvin of www.Conchango.com @ http://feeds.feedburner.com/PaulGalvinsSharepointSpace
    Friday, October 17, 2008 9:55 PM
  • DJ and Paul:
    Thank you for your prompt responses.

    1. Paul, yes, can you please provide links to information on content types that's relevant to my situation?
    I have read a number of your posts and replies to other threads, and I value your feedback.

    2.  Yes, we have created a document library that is standard company-wide with metadata columns, similar to what DJ suggests.  We have 5 mandatory fields of metadata (type of doc, subject/keywords, description, market area, reviewed by) and about 12 more optional fields (author, contacts, created date, etc.)

    3.  Does the SharePoint search tool give any relevancy weight to finding a search string in a document file name? (for example, "Annual Vacation" in the doc name ...AnnualVacationRequest.doc  )

    4.  And how heavily does the search tool weight strings that it finds in metadata (as opposed to in the text of the document itself)?

    5.  I like the phrase "anti-practice," I think I'll use that term myself ...

    Tuesday, October 21, 2008 9:11 PM
  • Has anyone since 2008 proposed an answer to this question?

    The use content types and columns to provide meta data is common but these files also, at times, live outside of SharePoint and in file shares or my document folders so a professional file naming convention is needed. Is it true that Microsoft Search (FAST I think it's called) prefers files with spaces rather than underscores or hyphens. I've also read Google search finds documents easier when they have hyphens rather than underscores. How do search engines do with spaces in names?

    > 4.  And how heavily does the search tool weight strings that it finds in metadata (as opposed to in the text of the document itself)?

    Is this a common naming practice: company, department, What the document is using proper case, Draft (for Draft files) and date:



    Does MicroSoft have an opinion on this? How concerned should we be towards older operating systems, browsers, servers, people?

    Saturday, December 10, 2011 3:25 AM
  • Using naming conventions is extremely important, so I think you made the right decision. The main reason for using them is that if naming conventions are in place, a user does not have to open a document to see what it is about - they can figure it out from the document name. Naming conventions would also give consistency to your content and the ability to easily find it. 

    To answer your questions: 

    1. The best naming conventions are those that are simple and yet very clear. They should be set up based on a document or content type. For example, you would not have the same naming convention for an article and for a specification or for a drawing even though they may have common parts. Important components of a file name would the name of the document (for example "Building Plan"), document or content type (for example specification), document date. As an example, the naming convention would look like: Building Plan Specification February 14, 2012.

    2. I recommend my clients to get users feedback for as many steps in the content management process as possible. This includes naming conventions. Many users themselves advocate using naming conventions. And if you explain to them why they are important and ask for their feedback and input for naming conventions, they will cooperate more freely with you. So, the answer to this question is yes, I have been successful in getting users to follow naming conventions.

    3. The main benefit is that documents can be found much more easily. Users don't have to open each document to see what it is. Users name documents something like "bp1234". How can one know what that is without opening it? A lot of time is wasted when users browse documents if naming conventions are not set up.

    4. Best practices are: keep them as simple as possible, intuitive as much as possible, consider using users feedback for their construction, they should describe what the document is about.

    • Edited by Mike Walsh FIN Tuesday, February 14, 2012 11:01 PM Old thread (2008) is being locked so "You can contact me if you have further questions." is removed. (Wrong anyway should be "reply here if ...")
    Tuesday, February 14, 2012 10:58 PM