Are you asking a question or suggesting that one is better than the other? In my opinion it depends entirely on the situation and how you might want to use, find, and surface the content later. Less is more, and you need to balance the data entry experience with a benefit analysis. If there's no benefit to complicating things by having the same metadata but with multiple content types then don't, but if there's a use case for being able to filter on certain content types or search for certain content types even if the metadata is all the same then in that case the content type is metadata and it can be useful to have different ones. Lots of room for nuance here. We often say Information Architecture is as much art as it is science, and this is why.
Great question. I would say it depends on the technical maturity of the organization. For a more mature organization, they are going to have the expectation to be able to search and filter based on more defined criteria (ex, department policies, claim forms, benefit overviews, etc.). This requires individual content types. For a lower maturity level organization, a general search for Benefits documents would suffice for a less technical mature organization. This would be a more generic content type like Benefits Document. Ideally, we like to help our clients move up the maturity model, but it is important to recognize where the client is at while providing room to grow.
@@dontthroworanges No, a "content type" doesn't replace a managed metadata column outright, content types have the power to define the metadata (fields) associated with a piece of content. It also has the power to be used as a way to query documents as a set and or a related set, through content type inheritance. Managed Metadata fields can be added to content types or just to the base list/library content type (keep in mind everything in SharePoint has a content type) and that then provides a way to tag content with a global term set. So, there are different use cases for them they can work together, and they can be used separately but they're not a replacement for each other.
Pro/Con of using separate content-types for each document type vs more generalized content-type with managed metadata for document type.
Are you asking a question or suggesting that one is better than the other? In my opinion it depends entirely on the situation and how you might want to use, find, and surface the content later. Less is more, and you need to balance the data entry experience with a benefit analysis. If there's no benefit to complicating things by having the same metadata but with multiple content types then don't, but if there's a use case for being able to filter on certain content types or search for certain content types even if the metadata is all the same then in that case the content type is metadata and it can be useful to have different ones. Lots of room for nuance here. We often say Information Architecture is as much art as it is science, and this is why.
Great question. I would say it depends on the technical maturity of the organization. For a more mature organization, they are going to have the expectation to be able to search and filter based on more defined criteria (ex, department policies, claim forms, benefit overviews, etc.). This requires individual content types.
For a lower maturity level organization, a general search for Benefits documents would suffice for a less technical mature organization. This would be a more generic content type like Benefits Document.
Ideally, we like to help our clients move up the maturity model, but it is important to recognize where the client is at while providing room to grow.
@@patc-p9497 Ok great! So it sounds like it's best to have "content type" stand in for a managed metadata column to tag a document.
@@dontthroworanges No, a "content type" doesn't replace a managed metadata column outright, content types have the power to define the metadata (fields) associated with a piece of content. It also has the power to be used as a way to query documents as a set and or a related set, through content type inheritance. Managed Metadata fields can be added to content types or just to the base list/library content type (keep in mind everything in SharePoint has a content type) and that then provides a way to tag content with a global term set. So, there are different use cases for them they can work together, and they can be used separately but they're not a replacement for each other.