You've built a controlled vocabulary in SharePoint's Term Store. Your team tags documents with the correct function, activity, and retention class. You assume those tags drive retention behavior. They don't.
This misconception persists because Microsoft offers two systems that look like they should connect but operate in complete isolation: SharePoint's managed metadata and Microsoft Purview retention labels. Records managers inherit both tools, assume they work together, and discover the gap only when building a compliance program or facing an audit.
Here's what the documentation won't tell you clearly.
Term Store Taxonomy Doesn't Control Retention
The Myth: If you tag a document with a retention class from your Business Classification Scheme in SharePoint's Term Store, that metadata will trigger the appropriate retention period.
The Reality: Term Store metadata is descriptive only. You can create a taxonomy that includes your entire records disposal schedule, apply those terms to documents, and display the full classification path in a library column. None of that applies retention controls. The metadata sits there, visible and searchable, but it won't prevent deletion, start a retention clock, or mark anything as a record.
Some organizations use third-party tools to read Term Store values and then apply corresponding Purview retention labels programmatically. That's a workaround, not native functionality.
File Plan Descriptors in Purview Labels Aren't Visible in SharePoint
The Myth: When you create a retention label in Purview's Records Management area and add File Plan descriptors (function, category, sub-category, citation), those terms will display alongside the label in SharePoint libraries so users can see the full classification.
The Reality: File Plan descriptors are not visible in SharePoint after the labels have been applied. You can add function, activity, authority citation, and event type to a label's metadata in Purview. Users never see those values in the library. The only thing that appears is the label name itself.
You can't create a column view that groups documents by the function descriptor embedded in their retention labels. You can't filter by citation. The descriptors exist only in Purview's administrative interface. For practical library management, they're invisible.
Term Store Taxonomy Can't Be Imported into Purview File Plan
The Myth: Since both systems handle classification hierarchies, you should be able to import your Term Store taxonomy into Purview's File Plan descriptors or link the two so changes propagate.
The Reality: There is no connection between the Term Store taxonomy and File Plan-based retention labels in Purview. You maintain two separate systems. If you update a function name or restructure your classification scheme, you update it twice. If you want consistent terminology, you enforce that manually through naming conventions and documentation.
Microsoft supplies some predefined descriptor values in Purview. You can add your own. But you're building a new list from scratch, not importing what already exists in SharePoint.
Retention Labels Don't Provide Enough Metadata for Compliance Reporting
The Myth: If you apply File Plan-based retention labels, you can query those labels to generate reports grouped by function, business unit, or retention authority for audit purposes.
The Reality: The only metadata elements accessible via PowerShell for retention labels are the label name, a compliance flag (a numeric code without clear documentation), the date the label was applied, and the user ID who applied it. The File Plan descriptors you carefully configured don't appear in any queryable property.
If you need to report "all records under Function 6.2 Fleet Management," you can't query the descriptor. You can only query the label name, which means your label naming convention must include the classification details you'd otherwise rely on metadata to carry.
Both Systems Are Necessary for Comprehensive Governance
The Myth: Microsoft designed these tools for different purposes, so the best approach is to pick one and ignore the other.
The Reality: Most defensible programs use both, because each does something the other can't. Term Store taxonomy gives you visible, searchable classification metadata that users can filter and group by. Purview retention labels give you enforceable retention controls, disposition workflows, and the ability to lock records during the retention period (a feature not available in labels created outside the File Plan area).
The practical approach: create your Business Classification Scheme or File Plan taxonomy in the Term Store and apply it via content types or library columns. Then create retention labels in Purview with names that map to your classification structure (e.g., "6.2.1 Fleet Contracts - PROS 07/01 - 7yr"). Apply both to the same content. The Term Store metadata makes the classification visible and reportable. The Purview label enforces the retention.
What to Do Instead
Start with your Records Control Schedule. Identify which functions and activities generate records that require retention controls versus those that just need classification for findability.
Build your classification taxonomy in the Term Store. Use the full hierarchy: function, activity, and retention class if you want that level of granularity displayed in libraries. This gives users a clear view of what they're looking at and supports filtering and reporting.
Create retention labels in Purview for each distinct retention requirement. Name them so the label itself communicates the classification and retention period, because the File Plan descriptors won't be visible. If you're managing a large schedule, map labels to function-activity pairs rather than individual retention classes to keep the label count manageable.
Apply both the Term Store metadata and the Purview retention label to the same content. Yes, you're maintaining two systems. Yes, it's redundant. But you get visible classification and enforceable retention, which you can't achieve with either system alone.
Document the mapping between your Term Store taxonomy and your retention labels. When someone updates the classification scheme, they need a reference showing which labels correspond to which taxonomy terms. Otherwise, the two systems drift and you lose consistency.
If you're building this program from scratch, push back on the assumption that classification and retention should be separate concerns. They shouldn't be. But until Microsoft connects these systems, you're managing the integration manually.
