Auto-Applying a Contract Retention Label on an E3 Estate

Two likely causes, one licensing and one configuration - confirm both, in this order.

1. Licensing. Auto-apply label policies are not part of the E3 service plan; they require the higher compliance tier. Confirm by checking assigned service plans for the records management administrator account and for the users whose content would be labelled - the capability is evaluated against the acting/benefiting users, not the tenant name on the invoice.
2. The label is not yet in a usable state. Auto-apply is built on top of a published label policy. If the Contract label has never been included in a label policy for the relevant location, or the policy is still propagating, the option is greyed out. Confirm by opening the label's policy status and checking that publishing completed.
3. Location mismatch. Auto-apply to Exchange content and auto-apply to SharePoint/OneDrive files are separate configurations. If the label was configured only for one location, the other will not offer the option.

Do not accept 'it's greyed out' as a diagnosis. Each cause has a different remedy and only one of them costs money.

Reframe the problem: auto-apply was a delivery mechanism, not the requirement. The requirement is that contract drafts are retained 7 years from last modification and then deleted. Get there by making the location unambiguous instead of guessing at content.

Design:

• Isolate. Move contract drafts into dedicated document libraries (one per practice area) and close the general libraries to new contract uploads. This is the enabling step - nothing else works while contract drafts are mixed with everything else.
• Default label at the library. Set the Contract label as the library default so every new or uploaded file inherits it without user action. Manual labels are available in E3; this is the cheapest automation available.
• Location-scoped retention policy as backstop. Apply a retention policy to those libraries that retains 7 years from last modified, then deletes. A location policy cannot tell a contract from a memo, which is exactly why isolation had to happen first.
• Handle the backlog explicitly. A library default applies to new items only. The existing 20 percent carry the label; the rest need a one-off labelling pass or acceptance that the library policy governs them.

Audit narrative: 'Contracts live in designated libraries, are labelled by default, and are additionally governed by a location retention policy with the same duration.' That is defensible without auto-apply.

Retention and preservation are two different mechanisms, and the hold wins.

• While the item is preserved by an eDiscovery hold or litigation hold, expiry of the 7-year retention period does not permanently delete it. Preservation overrides the delete action; the item stays in the preservation location.
• When the hold is released, the item is re-evaluated against its retention settings. If the period has already expired, deletion proceeds at that point - not retroactively and not silently.
• Practical consequence for the label design: do not try to encode litigation in the label. Labels cannot know about a case. Keep the label focused on the business requirement and manage holds separately, so releasing a hold does not require editing a retention rule that affects thousands of unrelated files.
• Copilot: grounded content must be retrievable by the signed-in user. Items sitting in a preservation library are not visible to ordinary users, so Copilot will not summarise or cite them. Holding a document for legal reasons does not make it discoverable through Copilot - and that is the correct behaviour, not a gap.

Verification step: place a test item under a hold, let its retention expire in a test site, and confirm it is preserved; then release and confirm deletion. Never assume the interaction from documentation alone.