Forum Discussion
New SharePoint implementation, but have we gone wrong? Your help and advice would be welcomed!
This guards against the inevitable re-orgs in most cases, because HR is pretty much always going to be HR, Finance is Finance, etc.
Each department / function, or in some cases, team, would get a site collection (either a 'classic' SP site collection, or an Office 365 Group (with associated SP site).
This gives you a security boundary (and keeps the list of users and groups neater) for each site collection, as well as the option of a storage quota (if you set storage management to manual at the tenant level).
For your content types, it sounds like you've created more 'file types' rather than 'content types' - e.g. Word is a file type, not a content type. Something like 'Expenses form', or 'High level design' would be a content type - perhaps with a template associated, so if you create a new High level design, it uses the template, but if you upload a high level design from elsewhere, you can select the correct content type, and it prompts for the relevant metadata, etc.
- many thanks for this reply. I guess with the content types we wanted to enforce a company standard mandatory requirement for each document which are two custom columns 'protective marking' and 'document type' ... also we wanted to encourage people to use a standard/default template for Word documents for example, using our branding etc.
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.
