Forum Discussion
New SharePoint implementation, but have we gone wrong? Your help and advice would be welcomed!
We've generally got some of the traditional teams in site collections that generally will remain the same - finance, legal, technology - but there are some that are questionable and they are the ones I'm concerned about the future when another shuffle happens... perhaps these could reside in O365 groups or possibly sit in a flat structure as you describe hanging, say, from our 'root' site collection?
Think about using Communication Sites for your publishing/broadcast content (intranet) and Groups (team sites) for your collaboration activity. All of these site collections should be "flat" - nothing hanging off of anything. If you use navigation to connect the sites, re-orgs will not matter. If you want every document to have two special columns, create a content type called [Company]-Document and use the out of the box Document as its parent. Add your two custom columns to that Content Type. You will then have to associate that content type with each of your document libraries. You can then associate a Word template with that content type - so that if a user goes to a library and says + New Word doc, they will have your template. (Most people don't do that, by the way, so there's that! I understand what you are trying to do, but from a practical perspective, my guess is that you will not get the outcome you want. An alternative approach would be to make all of your templates available in a Brand Central type site collection and then train your staff to use these templates - whether they create a document from Word or from SharePoint.)
Once you have [Company]-Document associated with all of your document libraries, ANY type of document (Word, PDF, PPT, etc.) uploaded to a library will have those two attributes. If they are required, then users will be prompted to enter them no matter what type of document they are actually uploading.
As Rob Ellis says, you should think about using content types for a functional document like a Project Charter or an Expense Report, not for a format (type) of document like Word or PPT. Your "base" corporate document doesn't care about the format of the document (though you can associate one and only one template with it). However, your base document can include any enterprise-wide required metadata that you want to include. Note that you will not necessariliy be able to easily force the custom content type in to document libraries set up by your users but you can probably use code or training to encourage its use. I never recommend trying to force metadata into Team Sites. It tends to discourage users from storing documents there. However, on Communication Sites, with limited publishers and lots of readers, this is much easier to govern.
- An interesting approach with a centralised set of document templates is to point the content types to those centralised templates, so you get the best of both worlds.
That way, whoever manages your templates doesn't have to know about editing content types, either in specific sites, or in a content type hub.Totally agree. Definitely how I would do it if needed. Just trying not to over-complicate! :-)
Did you try putting all the templates in the Content Tyoe Hub Site Collection? Not that I am recommending doing that, to be honest because I am still not convinced that it is going to get you your desired outcomes. I think I am trying to get you to really think about whether you need the templates at all and whether they will add value. It is so hard to get users to start a Word document from SharePoint (except in fit for purpose solutions) that you really could be over-planning and not getting the outcomes you want - and it may or not work technically or consistently. I think it is important to balance what is maybe technically possible with what is practical and truly adds business value. Some practices are more easily implemented with training (I know, hard to believe) than trying to use every technically possible feature of SharePoint.
