Aug. 2, 2026
Data Lifecycle Management - Simply Explained
Microsoft Purview Data Lifecycle Management helps organizations control how long information should be kept, when it should be reviewed, and when it should be securely deleted. Instead of allowing emails, Teams chats, SharePoint documents, OneDrive files, and other Microsoft 365 content to accumulate indefinitely, lifecycle management ensures every piece of information follows a defined business, legal, or regulatory process. This reduces storage costs, minimizes compliance risks, improves search efficiency, and ensures outdated or unnecessary information is removed in a controlled manner rather than remaining in the environment forever.
UNDERSTANDING THE DATA LIFECYCLE
Every piece of business information follows a natural lifecycle. It is created, actively used, retained for business or legal purposes, reviewed when necessary, and eventually disposed of once it no longer provides value. Microsoft Purview supports this complete journey through retention settings that prevent premature deletion while also ensuring content is not kept longer than necessary. Organizations can choose to retain content, delete content after a defined period, or combine both approaches by retaining information first and automatically deleting it later. A successful lifecycle strategy always begins by understanding why information exists before deciding how long it should remain.
RETENTION POLICIES VS. RETENTION LABELS
Retention Policies provide organization-wide rules that apply to entire Microsoft 365 locations such as Exchange Online mailboxes, SharePoint sites, OneDrive accounts, or Microsoft Teams chats. They are ideal when large amounts of similar content require identical retention behavior. Retention Labels, on the other hand, apply directly to individual emails or documents. This allows important business records, such as signed contracts or official agreements, to receive different retention periods than drafts or everyday working documents stored in the same location. Labels may be applied manually by users or automatically by Microsoft Purview based on predefined conditions, creating much more granular control over business-critical information.
SCOPES, CONFLICT RESOLUTION, AND RETENTION LOGIC
Microsoft Purview determines where retention rules apply by using either static scopes or adaptive scopes. Static scopes target specific users, mailboxes, or SharePoint sites, making them suitable for stable environments. Adaptive scopes automatically include users or locations based on Microsoft Entra ID attributes such as department or job title, significantly reducing administration in large organizations. When multiple retention rules overlap, Purview follows predictable conflict rules. Retention requirements always take priority over deletion, longer retention periods override shorter ones, and item-level retention labels can override broader location-based policies. This ensures organizations never delete information that must legally or operationally remain available.
HOW ALL THE COMPONENTS WORK TOGETHER
Data Lifecycle Management works by combining policies, labels, scopes, and automated retention into one consistent governance framework. A general retention policy can protect everyday content across Microsoft 365 while retention labels provide special treatment for important records. Adaptive scopes ensure policies automatically follow organizational changes, and retention continues to protect required content even if users accidentally delete files or emails. It is also important to understand that lifecycle management only controls how long information exists. It does not determine who can access content or how it is is shared. Those responsibilities belong to Microsoft Purview Sensitivity Labels and Data Loss Prevention (DLP), which complement lifecycle management as part of a complete Microsoft Purview governance strategy.
BEST PRACTICES FOR BUILDING A RETENTION STRATEGY
A successful Data Lifecycle Management implementation starts with understanding where information is stored across Exchange Online, SharePoint, OneDrive, Microsoft Teams, and AI-generated content. Business owners should define why each type of information exists, how long it must be retained, and what should happen when that retention period expires. Begin with broad, low-risk retention policies before introducing more granular retention labels for specialized records. Use adaptive scopes where organizational structures frequently change, clearly document every retention policy, carefully test automatic deletion before enabling it in production, and regularly review overlapping rules with compliance, legal, records management, and business stakeholders. By following this structured approach, organizations can reduce compliance risk while ensuring information remains available for exactly as long as it is needed—and no longer.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:04,600
Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365.
2
00:00:04,600 --> 00:00:06,420
FM, I'm your host, Mirko Peters.
3
00:00:06,420 --> 00:00:09,080
Imagine someone asks, "How long do we keep this email?"
4
00:00:09,080 --> 00:00:13,320
Then someone else asks the same question about a team's chat, a file in one drive,
5
00:00:13,320 --> 00:00:16,280
a shared document in SharePoint and a signed contract.
6
00:00:16,280 --> 00:00:19,760
For years, many organizations treated each one as a separate problem.
7
00:00:19,760 --> 00:00:23,040
Email had its own set of rules, shared files followed another.
8
00:00:23,040 --> 00:00:26,320
Personal files stayed somewhere else, chats just kept growing,
9
00:00:26,320 --> 00:00:30,080
and records often ended up in a folder called "Final Final Archive".
10
00:00:30,080 --> 00:00:32,440
It feels safer to keep everything forever, right?
11
00:00:32,440 --> 00:00:34,920
Nothing can disappear by mistake, but here's the catch.
12
00:00:34,920 --> 00:00:36,880
Keeping everything creates a different problem.
13
00:00:36,880 --> 00:00:40,360
Old content piles up, people struggle to find the current version.
14
00:00:40,360 --> 00:00:43,280
Sensitive information sticks around long after anyone needs it,
15
00:00:43,280 --> 00:00:45,720
and if a legal request or security incident happens,
16
00:00:45,720 --> 00:00:48,520
you've got far more data to search, review, and protect it.
17
00:00:48,520 --> 00:00:51,840
That's where Microsoft purview data lifecycle management steps in.
18
00:00:51,840 --> 00:00:55,560
In plain English, it helps your organization decide how long content should stay,
19
00:00:55,560 --> 00:00:57,320
what happens when someone deletes it early,
20
00:00:57,320 --> 00:00:59,440
and what should happen when its useful life ends.
21
00:00:59,440 --> 00:01:02,240
Think of Microsoft 365 like a modern office building.
22
00:01:02,240 --> 00:01:05,480
Exchange online is the mail room where your email and calendar live.
23
00:01:05,480 --> 00:01:07,160
SharePoint is the team filing room.
24
00:01:07,160 --> 00:01:09,080
One drive is your personal desk drawer.
25
00:01:09,080 --> 00:01:11,960
Teams is the conference room where conversations happen all day.
26
00:01:11,960 --> 00:01:15,000
And now AI interactions can generate even more business content.
27
00:01:15,000 --> 00:01:18,440
Every email, file, chat, and record enters that building at some point.
28
00:01:18,440 --> 00:01:20,440
It gets used, it may need to stay for a while,
29
00:01:20,440 --> 00:01:22,360
then eventually it needs a clear decision.
30
00:01:22,360 --> 00:01:24,360
Keep it, review it, or remove it.
31
00:01:24,360 --> 00:01:26,920
Without rules, the building fills up with boxes, nobody owns,
32
00:01:26,920 --> 00:01:28,560
and files, nobody understands.
33
00:01:28,560 --> 00:01:32,360
By the end of this episode, you'll understand what data lifecycle management controls,
34
00:01:32,360 --> 00:01:34,600
where it works across Microsoft 365,
35
00:01:34,600 --> 00:01:36,520
and how the major pieces fit together.
36
00:01:36,520 --> 00:01:37,680
We'll keep this simple.
37
00:01:37,680 --> 00:01:40,920
First, we need to answer the question behind every retention rule.
38
00:01:40,920 --> 00:01:43,480
How long should this data exist?
39
00:01:43,480 --> 00:01:47,040
Building block one, the data lifecycle from creation to disposal.
40
00:01:47,040 --> 00:01:50,240
Data lifecycle management sounds like a big phrase, but the idea is simple.
41
00:01:50,240 --> 00:01:53,520
It means setting rules to keep data for the right amount of time,
42
00:01:53,520 --> 00:01:56,160
then reviewing or deleting it when that time ends.
43
00:01:56,160 --> 00:01:59,760
A file doesn't need the same treatment forever just because it was useful once.
44
00:01:59,760 --> 00:02:02,400
Think about the normal life of a piece of business content.
45
00:02:02,400 --> 00:02:04,320
Someone creates it, people use it.
46
00:02:04,320 --> 00:02:08,520
The organization keeps it because it has a business, legal, or regulatory reason to stay.
47
00:02:08,520 --> 00:02:11,120
Later, someone may need to review it before it goes.
48
00:02:11,120 --> 00:02:14,440
Then if the organization approves, the content is disposed of.
49
00:02:14,440 --> 00:02:15,920
That's the lifecycle in a nutshell.
50
00:02:15,920 --> 00:02:18,800
Created, used, retained, reviewed, and disposed of.
51
00:02:18,800 --> 00:02:22,640
Now, disposed of doesn't mean somebody randomly cleans up a folder on a Friday afternoon.
52
00:02:22,640 --> 00:02:25,400
It means the organization made a decision ahead of time.
53
00:02:25,400 --> 00:02:28,480
It knows why the content can be removed when that moment arrives
54
00:02:28,480 --> 00:02:30,840
and who should check it if a human decision is needed.
55
00:02:30,840 --> 00:02:32,720
Let's use a customer contract as an example.
56
00:02:32,720 --> 00:02:35,480
At the start, someone creates a draft in a word document.
57
00:02:35,480 --> 00:02:37,880
That draft may move back and forth through email.
58
00:02:37,880 --> 00:02:39,960
A few people discuss changes in teams.
59
00:02:39,960 --> 00:02:41,960
Then the customer signs the final version
60
00:02:41,960 --> 00:02:45,920
and the organization stores that signed contract with the rest of the project files.
61
00:02:45,920 --> 00:02:49,240
Those things are related, but they may not all need to live for the same amount of time.
62
00:02:49,240 --> 00:02:52,720
An early draft might only matter while people negotiate the deal.
63
00:02:52,720 --> 00:02:56,360
A casual team's message like "I've added the latest pricing" may have a short life.
64
00:02:56,360 --> 00:02:58,560
The final signed contract may need to stay much longer
65
00:02:58,560 --> 00:03:00,720
because it proves what both sides agreed to.
66
00:03:00,720 --> 00:03:03,440
This is why one rule for everything rarely works well.
67
00:03:03,440 --> 00:03:06,880
Pervue gives you three basic choices for how content should behave.
68
00:03:06,880 --> 00:03:10,440
The first choice is "keep only", "you keep the content for a set time"
69
00:03:10,440 --> 00:03:12,640
or "you keep it until someone makes another decision".
70
00:03:12,640 --> 00:03:15,480
The point is to prevent it from disappearing too early.
71
00:03:15,480 --> 00:03:17,320
The second choice is "delete only".
72
00:03:17,320 --> 00:03:22,000
Content can stay while people need it, but when it reaches a certain age, Pervue removes it.
73
00:03:22,000 --> 00:03:24,200
This often fits content with a short-use for life
74
00:03:24,200 --> 00:03:27,280
where the organization doesn't need to preserve it against early deletion.
75
00:03:27,280 --> 00:03:29,480
The third choice is "keep first" then delete later.
76
00:03:29,480 --> 00:03:32,880
This is the pattern many organizations need for normal business records
77
00:03:32,880 --> 00:03:35,000
keep the content for the required period.
78
00:03:35,000 --> 00:03:38,400
When that period ends, remove it automatically or send it for review.
79
00:03:38,400 --> 00:03:40,120
Each choice answers a different question.
80
00:03:40,120 --> 00:03:41,880
Do we need to guarantee this stays?
81
00:03:41,880 --> 00:03:43,920
Do we need to make sure this doesn't stay too long?
82
00:03:43,920 --> 00:03:45,160
Or do we need both?
83
00:03:45,160 --> 00:03:50,920
Keeping everything forever can sound like the safest choice, especially when people worry about losing a file they might need later.
84
00:03:50,920 --> 00:03:52,760
But all data brings its own risk.
85
00:03:52,760 --> 00:03:55,880
Old customer details may still exist in forgotten folders.
86
00:03:55,880 --> 00:03:58,840
Old drafts may confuse people trying to find the real agreement.
87
00:03:58,840 --> 00:04:02,120
Old chats and emails can become part of a search during an investigation,
88
00:04:02,120 --> 00:04:04,400
even when nobody has looked at them in years.
89
00:04:04,400 --> 00:04:08,600
And if an account or location is compromised, more retained data means more data exposed.
90
00:04:08,600 --> 00:04:10,760
So retention isn't only about keeping content,
91
00:04:10,760 --> 00:04:14,080
it's also about removing content when there's no reason to keep it.
92
00:04:14,080 --> 00:04:15,360
There's an important difference here.
93
00:04:15,360 --> 00:04:16,880
Accidental deletion is a mistake.
94
00:04:16,880 --> 00:04:18,440
A user deletes the wrong email.
95
00:04:18,440 --> 00:04:19,760
Someone overrides the document.
96
00:04:19,760 --> 00:04:23,120
A team removes a folder without realizing what sits inside it.
97
00:04:23,120 --> 00:04:24,840
Life cycle disposal is different.
98
00:04:24,840 --> 00:04:27,600
That happens because the organization agreed on a rule.
99
00:04:27,600 --> 00:04:31,960
The content reached the end of its approved lifespan and purview followed that instruction.
100
00:04:31,960 --> 00:04:32,920
One is an error.
101
00:04:32,920 --> 00:04:34,520
The other is planned housekeeping.
102
00:04:34,520 --> 00:04:38,680
For you, the starting point isn't a random number like three years, five years or seven years.
103
00:04:38,680 --> 00:04:39,600
Start with the reason.
104
00:04:39,600 --> 00:04:40,880
Why does this content exist?
105
00:04:40,880 --> 00:04:44,960
Who needs it? Is there a legal, regulatory, financial or business reason to keep it?
106
00:04:44,960 --> 00:04:48,720
And when that reason ends, should the content disappear or should someone review it first?
107
00:04:48,720 --> 00:04:50,320
Those answers create the rule.
108
00:04:50,320 --> 00:04:52,000
The number of years comes after that.
109
00:04:52,000 --> 00:04:54,120
Deciding the time is only half the job, though,
110
00:04:54,120 --> 00:04:57,320
because purview also needs to know where that rule belongs.
111
00:04:57,320 --> 00:05:00,400
Building block two, retention policies, the building wide rules.
112
00:05:00,400 --> 00:05:03,720
Once you know how long content should stay, the next question is simple.
113
00:05:03,720 --> 00:05:05,120
Where should that rule apply?
114
00:05:05,120 --> 00:05:06,840
Retention policies answer that question.
115
00:05:06,840 --> 00:05:11,760
A retention policy acts as a broad rule for a whole location in Microsoft 365, covering
116
00:05:11,760 --> 00:05:16,960
mailboxes in exchange online, a sharepoint site, one drive accounts or team's messages.
117
00:05:16,960 --> 00:05:20,800
Think of it like a rule posted at the entrance to one floor of your office building, and everyone
118
00:05:20,800 --> 00:05:24,160
on that floor follows the same rule because the space has one shared purpose.
119
00:05:24,160 --> 00:05:27,840
You don't need each person to stop, read every file and decide how long it should stay.
120
00:05:27,840 --> 00:05:30,480
The rule already applies because the content lives there.
121
00:05:30,480 --> 00:05:31,480
That saves a lot of guesswork.
122
00:05:31,480 --> 00:05:35,560
Imagine a company wants to keep all teams chat messages for two years, then remove them
123
00:05:35,560 --> 00:05:37,440
after those two years pass.
124
00:05:37,440 --> 00:05:40,640
Nobody should need to tag every message or remember whether a chat from Tuesday needs
125
00:05:40,640 --> 00:05:42,040
two years or two months.
126
00:05:42,040 --> 00:05:46,400
The organization creates one retention policy for teams chat messages, and purview applies
127
00:05:46,400 --> 00:05:49,000
that rule across the chosen people or locations.
128
00:05:49,000 --> 00:05:51,480
So every covered message follows the same lifespan.
129
00:05:51,480 --> 00:05:54,360
That's a good fit for broad, repeatable content.
130
00:05:54,360 --> 00:05:57,880
Teams chats are high volume and move fast, so most people don't stop mid-complication
131
00:05:57,880 --> 00:06:00,680
to think about what records category a message belongs to.
132
00:06:00,680 --> 00:06:03,800
A building wide rule handles that common content in the background.
133
00:06:03,800 --> 00:06:06,440
The same idea works for a department sharepoint site.
134
00:06:06,440 --> 00:06:10,800
Say the operations team has one sharepoint site for its working documents, containing meeting
135
00:06:10,800 --> 00:06:14,760
notes, process guides, planning files, and day-to-day team documents.
136
00:06:14,760 --> 00:06:18,600
If that whole site meets the same retention period, a policy can cover the site and its
137
00:06:18,600 --> 00:06:19,600
connected files.
138
00:06:19,600 --> 00:06:23,600
People can still create, edit, move, and delete their working files as part of normal work.
139
00:06:23,600 --> 00:06:27,400
But when the policy requires content to stay, a user deleting a file doesn't necessarily
140
00:06:27,400 --> 00:06:29,360
end that retention requirement.
141
00:06:29,360 --> 00:06:32,840
Purview can preserve the content behind the scenes for the required period.
142
00:06:32,840 --> 00:06:34,200
That part often surprises people.
143
00:06:34,200 --> 00:06:38,800
A user may think they deleted that email last month or that file is gone from the team site
144
00:06:38,800 --> 00:06:42,760
and from the user's point of view, it may be gone, but from the organization's retention
145
00:06:42,760 --> 00:06:48,680
point of view, purview can still keep a preserved copy while the required period continues.
146
00:06:48,680 --> 00:06:52,120
This isn't meant to turn every deleted file into something users can see forever.
147
00:06:52,120 --> 00:06:56,120
It means an organization can meet its agreed rule even when people clean up, make mistakes,
148
00:06:56,120 --> 00:06:57,120
or leave the company.
149
00:06:57,120 --> 00:07:00,840
That makes retention policies useful for content where consistency matters more than individual
150
00:07:00,840 --> 00:07:02,040
choices.
151
00:07:02,040 --> 00:07:06,720
A company may decide that all mailboxes in a certain department need the same rule because
152
00:07:06,720 --> 00:07:10,640
that department handles the same kind of work, so the policy applies to those mailboxes
153
00:07:10,640 --> 00:07:11,640
as a group.
154
00:07:11,640 --> 00:07:15,600
Or perhaps the business wants one common rule for AI interactions because those interactions
155
00:07:15,600 --> 00:07:19,800
can arrive in large numbers and users shouldn't need to decide the lifespan of every prompt
156
00:07:19,800 --> 00:07:20,800
or response.
157
00:07:20,800 --> 00:07:22,480
Again, that's a policy job.
158
00:07:22,480 --> 00:07:26,320
The rule applies based on location, not because a person made a choice for each item.
159
00:07:26,320 --> 00:07:27,440
There is a limit though.
160
00:07:27,440 --> 00:07:31,200
A retention policy looks at the place where content lives, not the business meaning of every
161
00:07:31,200 --> 00:07:32,880
individual file inside that place.
162
00:07:32,880 --> 00:07:37,440
A SharePoint site might contain an early contract draft, a final signed contract, a meeting
163
00:07:37,440 --> 00:07:39,080
agenda, and a lunch menu.
164
00:07:39,080 --> 00:07:43,480
A broad policy can apply one baseline rule across that site, but it can't naturally tell
165
00:07:43,480 --> 00:07:47,520
the final signed contract apart from the draft just because both documents sit in the same
166
00:07:47,520 --> 00:07:51,800
library that would be like giving every folder in one filing cabinet the exact same disposal
167
00:07:51,800 --> 00:07:56,120
date even though some folders contain rough notes and others contain binding agreements.
168
00:07:56,120 --> 00:07:58,560
Sometimes that's fine and often it's exactly what you want.
169
00:07:58,560 --> 00:08:03,160
Use retention policies when you have a clear repeatable rule for a whole location especially
170
00:08:03,160 --> 00:08:07,160
for high volume content such as chat messages or AI interactions.
171
00:08:07,160 --> 00:08:11,400
They reduce user effort, create consistent outcomes, and help keep common content under
172
00:08:11,400 --> 00:08:15,400
one shared rule, but when one file needs a different life from everything around it,
173
00:08:15,400 --> 00:08:18,440
the container-wide approach becomes too blunt.
174
00:08:18,440 --> 00:08:19,800
Building block three.
175
00:08:19,800 --> 00:08:20,800
Retention labels.
176
00:08:20,800 --> 00:08:22,120
The files own filing card.
177
00:08:22,120 --> 00:08:26,200
A retention policy works well when the location tells you what to do, but sometimes the
178
00:08:26,200 --> 00:08:28,520
location tells you almost nothing.
179
00:08:28,520 --> 00:08:33,320
One SharePoint library can hold drafts, final agreements, meeting notes, invoices, and documents
180
00:08:33,320 --> 00:08:34,840
people no longer need.
181
00:08:34,840 --> 00:08:39,360
And one mailbox can hold casual conversations right next to an email that confirms a major
182
00:08:39,360 --> 00:08:40,360
business decision.
183
00:08:40,360 --> 00:08:41,800
That's when retention labels help.
184
00:08:41,800 --> 00:08:45,840
A retention label is an item-level rule attached to one specific piece of content such as
185
00:08:45,840 --> 00:08:47,280
an email or a document.
186
00:08:47,280 --> 00:08:49,040
Think of a filing cabinet.
187
00:08:49,040 --> 00:08:53,400
Every folder inside it has a small card on the front that tells you what the folder contains,
188
00:08:53,400 --> 00:08:58,400
how long it stays in the cabinet, and what should happen when that time ends.
189
00:08:58,400 --> 00:09:02,400
The cabinet itself may contain hundreds of folders, yet not every folder follows the same
190
00:09:02,400 --> 00:09:03,400
schedule.
191
00:09:03,400 --> 00:09:05,000
That's the difference a label creates.
192
00:09:05,000 --> 00:09:07,920
The instruction belongs to the item, not just the place where it sits.
193
00:09:07,920 --> 00:09:09,480
Let's go back to the contract example.
194
00:09:09,480 --> 00:09:13,640
During a negotiation, a team creates several drafts, revising the wording, comparing versions
195
00:09:13,640 --> 00:09:15,200
and sending comments back and forth.
196
00:09:15,200 --> 00:09:18,840
Those drafts matter, while the deal is active, but they may not need the same long term
197
00:09:18,840 --> 00:09:21,000
treatment as the sign agreement.
198
00:09:21,000 --> 00:09:24,880
Once both sides sign, that final contract becomes a different kind of content because
199
00:09:24,880 --> 00:09:29,480
it proves the agreement, so the organization might apply one retention label to drafts,
200
00:09:29,480 --> 00:09:33,120
with a shorter lifespan and another label to sign contracts with a longer one.
201
00:09:33,120 --> 00:09:37,200
Both files might live in the same sharepoint site, or even sit in the same document library,
202
00:09:37,200 --> 00:09:40,200
but their labels tell per view that they have different business meanings and different
203
00:09:40,200 --> 00:09:41,200
instructions.
204
00:09:41,200 --> 00:09:45,280
That makes labels useful when the type of content matters more than its storage location.
205
00:09:45,280 --> 00:09:46,960
How does the label get onto the content?
206
00:09:46,960 --> 00:09:50,000
Sometimes a person applies it manually, which works when someone understands the business
207
00:09:50,000 --> 00:09:51,000
meaning of the item.
208
00:09:51,000 --> 00:09:54,680
A legal team member might know that an email confirms a final decision or a contract manager
209
00:09:54,680 --> 00:09:58,320
might know the document has moved from draft to sign agreement, and they choose the right
210
00:09:58,320 --> 00:10:00,240
label as part of their normal work.
211
00:10:00,240 --> 00:10:04,600
Still, people are busy and may forget or not know which label applies, and some organizations
212
00:10:04,600 --> 00:10:08,680
have far too much content for users to sort every item by hand.
213
00:10:08,680 --> 00:10:12,760
Per view can also auto-apply labels when it can identify content through defined conditions,
214
00:10:12,760 --> 00:10:16,680
such as matching a known type of information, words used in a document, or another condition
215
00:10:16,680 --> 00:10:18,360
the organization has set up.
216
00:10:18,360 --> 00:10:19,360
The point is simple.
217
00:10:19,360 --> 00:10:23,640
When Per view can reliably recognize a content type, it can apply the label without asking
218
00:10:23,640 --> 00:10:25,400
a user to remember every rule.
219
00:10:25,400 --> 00:10:29,200
But before relying on automatic labels, test them carefully because a label with the wrong
220
00:10:29,200 --> 00:10:34,080
condition can classify the wrong items, and a retention rule can affect content long after
221
00:10:34,080 --> 00:10:36,800
people forget why it was applied.
222
00:10:36,800 --> 00:10:38,320
Labels can also support records.
223
00:10:38,320 --> 00:10:42,400
A record needs stronger control because the organization must treat it as an official version,
224
00:10:42,400 --> 00:10:43,840
not just another working file.
225
00:10:43,840 --> 00:10:48,000
For example, the final sign contract may need to stay put, and people shouldn't casually
226
00:10:48,000 --> 00:10:51,760
edit it, replace it, or delete it because they want a cleaner folder.
227
00:10:51,760 --> 00:10:55,000
Using content as a record gives it that tighter treatment.
228
00:10:55,000 --> 00:10:58,840
It tells the organization that this item has reached a point where normal day-to-day editing
229
00:10:58,840 --> 00:10:59,840
should stop.
230
00:10:59,840 --> 00:11:03,560
When a label's retention period ends, Per view can follow different next steps.
231
00:11:03,560 --> 00:11:07,160
Some content can be deleted automatically because the business already agreed it no longer
232
00:11:07,160 --> 00:11:09,960
needs it, while other content needs a human check first.
233
00:11:09,960 --> 00:11:13,720
That's where disposition review comes in, rather than deleting the item immediately,
234
00:11:13,720 --> 00:11:17,400
the system can send it to the right people for review, and they can decide whether it should
235
00:11:17,400 --> 00:11:20,920
be removed, or whether there is a reason to keep it longer.
236
00:11:20,920 --> 00:11:22,920
The right choice depends on the content.
237
00:11:22,920 --> 00:11:26,640
Routine drafts may be safe for automatic deletion, while a former record may need someone
238
00:11:26,640 --> 00:11:28,400
to look at it before it goes.
239
00:11:28,400 --> 00:11:32,480
So use retention labels when you need the rule to follow the content itself, especially
240
00:11:32,480 --> 00:11:37,440
when two items in the same mailbox or SharePoint site have different jobs, different life spans,
241
00:11:37,440 --> 00:11:39,840
or different end-of-life steps.
242
00:11:39,840 --> 00:11:41,120
One complication remains.
243
00:11:41,120 --> 00:11:45,240
A labeled item can also sit inside a location covered by a broader retention policy, so
244
00:11:45,240 --> 00:11:49,120
Per view needs clear rules for deciding which instruction wins.
245
00:11:49,120 --> 00:11:52,440
In blog 4, scope and conflict rules, who gets which rule?
246
00:11:52,440 --> 00:11:54,760
A retention rule also needs an audience.
247
00:11:54,760 --> 00:11:58,480
You might know that finance content needs one schedule and HR content needs another, but
248
00:11:58,480 --> 00:12:02,720
Per view still needs a way to identify the right people, mailboxes and sites.
249
00:12:02,720 --> 00:12:03,880
That job is called scope.
250
00:12:03,880 --> 00:12:05,960
A static scope is the simple option.
251
00:12:05,960 --> 00:12:10,480
When you create the policy, you choose named users, mailboxes, SharePoint sites, OneDrive
252
00:12:10,480 --> 00:12:12,120
accounts, or other locations.
253
00:12:12,120 --> 00:12:15,280
You pointed the exact target and say, "This rule applies here."
254
00:12:15,280 --> 00:12:17,760
That works well when the target won't change much.
255
00:12:17,760 --> 00:12:20,760
Maybe you have one dedicated SharePoint site for a project.
256
00:12:20,760 --> 00:12:24,440
Maybe a small legal team has a known group of mailboxes, or perhaps a fixed list of
257
00:12:24,440 --> 00:12:27,120
executive accounts needs one common rule.
258
00:12:27,120 --> 00:12:28,360
Static scope is direct.
259
00:12:28,360 --> 00:12:32,480
You choose the targets, and the policy stays with those targets until an administrator changes
260
00:12:32,480 --> 00:12:33,480
it.
261
00:12:33,480 --> 00:12:34,480
But organizations change all the time.
262
00:12:34,480 --> 00:12:37,960
People join, people change jobs, departments grow, teams reorganize.
263
00:12:37,960 --> 00:12:41,640
If someone moves from sales into finance, do you want an administrator to remember every
264
00:12:41,640 --> 00:12:45,160
rule that should now apply to that person's email files and messages?
265
00:12:45,160 --> 00:12:46,160
Probably not.
266
00:12:46,160 --> 00:12:47,480
That is where adaptive scopes help.
267
00:12:47,480 --> 00:12:52,360
An adaptive scope uses details about people, groups, or sites to decide who belongs under
268
00:12:52,360 --> 00:12:53,360
a rule.
269
00:12:53,360 --> 00:12:56,520
Those details can include a department, job role, or location.
270
00:12:56,520 --> 00:12:59,240
Think of Entra ID as the reception desk for your digital office.
271
00:12:59,240 --> 00:13:02,480
When someone arrives, the reception desk knows who they are and where they belong.
272
00:13:02,480 --> 00:13:05,360
It can see details such as their department or job title.
273
00:13:05,360 --> 00:13:09,520
Per view can use those details to place the person under the right retention rule.
274
00:13:09,520 --> 00:13:12,120
Imagine an employee moves into the finance department.
275
00:13:12,120 --> 00:13:15,000
Their account changes to show finance as their department.
276
00:13:15,000 --> 00:13:19,240
An adaptive scope that looks for finance staff can recognize that change, so the finance retention
277
00:13:19,240 --> 00:13:20,800
policy can follow their account.
278
00:13:20,800 --> 00:13:24,720
Nobody needs to rebuild a list by hand every time a person changes roles.
279
00:13:24,720 --> 00:13:28,360
That makes adaptive scopes a good choice for larger organizations where membership moves
280
00:13:28,360 --> 00:13:29,360
often.
281
00:13:29,360 --> 00:13:33,520
They reduce the ongoing admin work because the rule follows the organization's own details.
282
00:13:33,520 --> 00:13:36,520
Still, adaptive isn't automatically the better choice every time.
283
00:13:36,520 --> 00:13:39,000
A fixed project site doesn't need a moving target.
284
00:13:39,000 --> 00:13:42,960
A short list of named mailboxes may be easier to manage as a static scope.
285
00:13:42,960 --> 00:13:45,640
Use static scope when the target is simple and stable.
286
00:13:45,640 --> 00:13:50,160
Use adaptive scope when the target should move as people, groups or sites change.
287
00:13:50,160 --> 00:13:53,880
Then there is the harder question, what happens when more than one rule applies to the same
288
00:13:53,880 --> 00:13:54,880
content?
289
00:13:54,880 --> 00:13:56,480
Per view has conflict rules for that.
290
00:13:56,480 --> 00:13:58,200
Start with the safest idea.
291
00:13:58,200 --> 00:14:00,040
Retention beats deletion.
292
00:14:00,040 --> 00:14:04,720
If one rule says content must stay and another rule says content should be deleted,
293
00:14:04,720 --> 00:14:08,320
Per view won't delete the content while the retention requirements still applies.
294
00:14:08,320 --> 00:14:12,920
When two retention rules apply for different lengths of time, the longer retention period wins.
295
00:14:12,920 --> 00:14:16,760
If one policy keeps content for three years and another needs it for seven, Per view keeps
296
00:14:16,760 --> 00:14:17,760
it for seven.
297
00:14:17,760 --> 00:14:19,880
The stronger obligation stays in place.
298
00:14:19,880 --> 00:14:23,520
Labels can also take priority over a broad policy because a label gives Per view a more
299
00:14:23,520 --> 00:14:26,120
specific instruction for that individual item.
300
00:14:26,120 --> 00:14:30,160
The site may have a general rule while one document inside that site carries its own label
301
00:14:30,160 --> 00:14:32,200
because it needs different treatment.
302
00:14:32,200 --> 00:14:34,720
Per view can follow that item level instruction.
303
00:14:34,720 --> 00:14:37,320
Deletion rules work differently when deletion is all that remains.
304
00:14:37,320 --> 00:14:41,360
If multiple deletion instructions apply, the shortest deletion period wins.
305
00:14:41,360 --> 00:14:44,720
That sounds complicated at first, but the pattern is sensible.
306
00:14:44,720 --> 00:14:46,400
Keep content when any rule requires it.
307
00:14:46,400 --> 00:14:48,320
Keep it for the longest required time.
308
00:14:48,320 --> 00:14:52,000
Then once no retention requirement remains, don't keep it longer than the deletion rules
309
00:14:52,000 --> 00:14:53,000
allowed.
310
00:14:53,000 --> 00:14:55,520
This is exactly why overlapping rules need planning.
311
00:14:55,520 --> 00:14:58,480
Don't create policies because a number of years sounds reasonable.
312
00:14:58,480 --> 00:15:03,440
Write down why the rule exists, who it covers, where it applies, how long it lasts, and
313
00:15:03,440 --> 00:15:05,120
what should happen at the end.
314
00:15:05,120 --> 00:15:06,880
Give every policy a clear name too.
315
00:15:06,880 --> 00:15:11,360
A name that tells you the audience, location, duration, and final action is far easier to
316
00:15:11,360 --> 00:15:15,080
understand than something vague like retention policy for.
317
00:15:15,080 --> 00:15:18,000
Before you create the settings, map three things.
318
00:15:18,000 --> 00:15:21,240
Map your people, map your locations, map your content types.
319
00:15:21,240 --> 00:15:25,200
Once those maps are clear, life cycle management starts to look less like a pile of settings
320
00:15:25,200 --> 00:15:27,320
and more like a connected system.
321
00:15:27,320 --> 00:15:28,640
How the parts connect?
322
00:15:28,640 --> 00:15:30,440
One rule book for your digital office.
323
00:15:30,440 --> 00:15:35,800
Put the pieces together and you get one rule book for your Microsoft 365 content.
324
00:15:35,800 --> 00:15:38,280
You set the normal rules for broad areas.
325
00:15:38,280 --> 00:15:40,880
Labels deal with the individual items that need special treatment.
326
00:15:40,880 --> 00:15:44,760
Scopes decide which people, sites, and groups enter each policy.
327
00:15:44,760 --> 00:15:47,240
Imagine an employee starts a contract draft in one drive.
328
00:15:47,240 --> 00:15:50,600
They share it with co-workers through teams where the team discusses changes.
329
00:15:50,600 --> 00:15:55,240
Later, the final signed version moves into a share point site where the project files belong.
330
00:15:55,240 --> 00:15:59,240
The draft and the final contract may travel through different places, but the organization
331
00:15:59,240 --> 00:16:02,040
can still apply clear instructions at each stage.
332
00:16:02,040 --> 00:16:05,880
A broad retention policy can set a baseline for the employee's working area.
333
00:16:05,880 --> 00:16:10,480
That baseline covers ordinary content, without asking the employee to make a records decision
334
00:16:10,480 --> 00:16:12,880
every time they save a file or send a message.
335
00:16:12,880 --> 00:16:16,200
Once the contract becomes the final signed version, a retention label can give that one
336
00:16:16,200 --> 00:16:17,800
document a longer lifespan.
337
00:16:17,800 --> 00:16:19,280
The location has its normal rule.
338
00:16:19,280 --> 00:16:21,320
The special document has its own instruction.
339
00:16:21,320 --> 00:16:25,120
If the employee changes department or moves to another location, an adaptive scope can update
340
00:16:25,120 --> 00:16:29,320
the baseline rule that applies to their account, based on the details held in Enter ID.
341
00:16:29,320 --> 00:16:33,160
The policy follows the person's role instead of relying on an old list that someone forgot
342
00:16:33,160 --> 00:16:34,160
to update.
343
00:16:34,160 --> 00:16:37,360
Retention also protects required content when a user deletes it early.
344
00:16:37,360 --> 00:16:41,760
The user may remove an email, file, or message from their view, but the retention requirement
345
00:16:41,760 --> 00:16:45,400
can continue behind the scenes until its time ends.
346
00:16:45,400 --> 00:16:47,160
Recovery tools handle a different problem.
347
00:16:47,160 --> 00:16:51,200
They help restore content after accidental deletion or unwanted changes.
348
00:16:51,200 --> 00:16:55,280
Version history, recycle bins, and other recovery options are about getting work back after
349
00:16:55,280 --> 00:16:56,800
something goes wrong.
350
00:16:56,800 --> 00:16:59,040
Retention is about meeting an agreed lifespan.
351
00:16:59,040 --> 00:17:00,360
Retention is about undoing a mistake.
352
00:17:00,360 --> 00:17:03,920
It also helps to know what data lifecycle management does not control.
353
00:17:03,920 --> 00:17:06,240
Retention decides how long content must remain.
354
00:17:06,240 --> 00:17:08,160
It doesn't decide who can open the document.
355
00:17:08,160 --> 00:17:11,600
It doesn't decide whether someone can share it with an outside person.
356
00:17:11,600 --> 00:17:16,080
Sensitivity labels and data loss prevention, often called DLP, handle those kinds of protection
357
00:17:16,080 --> 00:17:17,320
and sharing controls.
358
00:17:17,320 --> 00:17:20,600
A sensitivity label can mark content and apply protection.
359
00:17:20,600 --> 00:17:23,320
DLP can monitor or block risky sharing.
360
00:17:23,320 --> 00:17:25,800
Data lifecycle management handles the time question.
361
00:17:25,800 --> 00:17:29,200
How long does this content stay and what happens when that time ends?
362
00:17:29,200 --> 00:17:30,200
That is the full picture.
363
00:17:30,200 --> 00:17:31,480
You're not trying to keep everything.
364
00:17:31,480 --> 00:17:32,880
You're not trying to delete everything.
365
00:17:32,880 --> 00:17:36,920
You're deciding what should stay, why it should stay, and when it can leave on purpose.
366
00:17:36,920 --> 00:17:41,120
From there, you can build a safe first plan without jumping straight into a wide deletion
367
00:17:41,120 --> 00:17:43,120
rule.
368
00:17:43,120 --> 00:17:44,400
Actionable takeaways.
369
00:17:44,400 --> 00:17:47,480
Start by mapping out where your content actually lives.
370
00:17:47,480 --> 00:17:51,440
Exchange online, SharePoint, OneDrive, Teams, and even AI interactions if you're using
371
00:17:51,440 --> 00:17:52,440
them.
372
00:17:52,440 --> 00:17:56,000
The locations go to each business owner and ask for simple questions.
373
00:17:56,000 --> 00:17:59,520
What data exists, why keep it, how long should it stay, and what happens when that time's
374
00:17:59,520 --> 00:18:00,520
up.
375
00:18:00,520 --> 00:18:01,520
Keep it small at first.
376
00:18:01,520 --> 00:18:05,240
Pick one low risk, broad policy, and don't try to create dozens of exceptions on day
377
00:18:05,240 --> 00:18:06,240
one.
378
00:18:06,240 --> 00:18:07,920
Here's a quick test to keep things straight.
379
00:18:07,920 --> 00:18:11,880
If a rule applies to a location that's a policy, if it applies to one special item, that's
380
00:18:11,880 --> 00:18:12,880
a label.
381
00:18:12,880 --> 00:18:15,840
And if it follows changing stuff, that's an adaptive scope.
382
00:18:15,840 --> 00:18:20,400
Always agree on deletion before you enable it and use review where a human needs to decide.
383
00:18:20,400 --> 00:18:25,080
From every policy clearly, test older content carefully and check overlaps with legal, records,
384
00:18:25,080 --> 00:18:26,720
compliance, and the business owners.
385
00:18:26,720 --> 00:18:28,560
Pick one content type this week.
386
00:18:28,560 --> 00:18:31,880
Define its lifespan in plain English, then build the rule around that decision.
00:00:00,000 --> 00:00:04,600
Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365.
2
00:00:04,600 --> 00:00:06,420
FM, I'm your host, Mirko Peters.
3
00:00:06,420 --> 00:00:09,080
Imagine someone asks, "How long do we keep this email?"
4
00:00:09,080 --> 00:00:13,320
Then someone else asks the same question about a team's chat, a file in one drive,
5
00:00:13,320 --> 00:00:16,280
a shared document in SharePoint and a signed contract.
6
00:00:16,280 --> 00:00:19,760
For years, many organizations treated each one as a separate problem.
7
00:00:19,760 --> 00:00:23,040
Email had its own set of rules, shared files followed another.
8
00:00:23,040 --> 00:00:26,320
Personal files stayed somewhere else, chats just kept growing,
9
00:00:26,320 --> 00:00:30,080
and records often ended up in a folder called "Final Final Archive".
10
00:00:30,080 --> 00:00:32,440
It feels safer to keep everything forever, right?
11
00:00:32,440 --> 00:00:34,920
Nothing can disappear by mistake, but here's the catch.
12
00:00:34,920 --> 00:00:36,880
Keeping everything creates a different problem.
13
00:00:36,880 --> 00:00:40,360
Old content piles up, people struggle to find the current version.
14
00:00:40,360 --> 00:00:43,280
Sensitive information sticks around long after anyone needs it,
15
00:00:43,280 --> 00:00:45,720
and if a legal request or security incident happens,
16
00:00:45,720 --> 00:00:48,520
you've got far more data to search, review, and protect it.
17
00:00:48,520 --> 00:00:51,840
That's where Microsoft purview data lifecycle management steps in.
18
00:00:51,840 --> 00:00:55,560
In plain English, it helps your organization decide how long content should stay,
19
00:00:55,560 --> 00:00:57,320
what happens when someone deletes it early,
20
00:00:57,320 --> 00:00:59,440
and what should happen when its useful life ends.
21
00:00:59,440 --> 00:01:02,240
Think of Microsoft 365 like a modern office building.
22
00:01:02,240 --> 00:01:05,480
Exchange online is the mail room where your email and calendar live.
23
00:01:05,480 --> 00:01:07,160
SharePoint is the team filing room.
24
00:01:07,160 --> 00:01:09,080
One drive is your personal desk drawer.
25
00:01:09,080 --> 00:01:11,960
Teams is the conference room where conversations happen all day.
26
00:01:11,960 --> 00:01:15,000
And now AI interactions can generate even more business content.
27
00:01:15,000 --> 00:01:18,440
Every email, file, chat, and record enters that building at some point.
28
00:01:18,440 --> 00:01:20,440
It gets used, it may need to stay for a while,
29
00:01:20,440 --> 00:01:22,360
then eventually it needs a clear decision.
30
00:01:22,360 --> 00:01:24,360
Keep it, review it, or remove it.
31
00:01:24,360 --> 00:01:26,920
Without rules, the building fills up with boxes, nobody owns,
32
00:01:26,920 --> 00:01:28,560
and files, nobody understands.
33
00:01:28,560 --> 00:01:32,360
By the end of this episode, you'll understand what data lifecycle management controls,
34
00:01:32,360 --> 00:01:34,600
where it works across Microsoft 365,
35
00:01:34,600 --> 00:01:36,520
and how the major pieces fit together.
36
00:01:36,520 --> 00:01:37,680
We'll keep this simple.
37
00:01:37,680 --> 00:01:40,920
First, we need to answer the question behind every retention rule.
38
00:01:40,920 --> 00:01:43,480
How long should this data exist?
39
00:01:43,480 --> 00:01:47,040
Building block one, the data lifecycle from creation to disposal.
40
00:01:47,040 --> 00:01:50,240
Data lifecycle management sounds like a big phrase, but the idea is simple.
41
00:01:50,240 --> 00:01:53,520
It means setting rules to keep data for the right amount of time,
42
00:01:53,520 --> 00:01:56,160
then reviewing or deleting it when that time ends.
43
00:01:56,160 --> 00:01:59,760
A file doesn't need the same treatment forever just because it was useful once.
44
00:01:59,760 --> 00:02:02,400
Think about the normal life of a piece of business content.
45
00:02:02,400 --> 00:02:04,320
Someone creates it, people use it.
46
00:02:04,320 --> 00:02:08,520
The organization keeps it because it has a business, legal, or regulatory reason to stay.
47
00:02:08,520 --> 00:02:11,120
Later, someone may need to review it before it goes.
48
00:02:11,120 --> 00:02:14,440
Then if the organization approves, the content is disposed of.
49
00:02:14,440 --> 00:02:15,920
That's the lifecycle in a nutshell.
50
00:02:15,920 --> 00:02:18,800
Created, used, retained, reviewed, and disposed of.
51
00:02:18,800 --> 00:02:22,640
Now, disposed of doesn't mean somebody randomly cleans up a folder on a Friday afternoon.
52
00:02:22,640 --> 00:02:25,400
It means the organization made a decision ahead of time.
53
00:02:25,400 --> 00:02:28,480
It knows why the content can be removed when that moment arrives
54
00:02:28,480 --> 00:02:30,840
and who should check it if a human decision is needed.
55
00:02:30,840 --> 00:02:32,720
Let's use a customer contract as an example.
56
00:02:32,720 --> 00:02:35,480
At the start, someone creates a draft in a word document.
57
00:02:35,480 --> 00:02:37,880
That draft may move back and forth through email.
58
00:02:37,880 --> 00:02:39,960
A few people discuss changes in teams.
59
00:02:39,960 --> 00:02:41,960
Then the customer signs the final version
60
00:02:41,960 --> 00:02:45,920
and the organization stores that signed contract with the rest of the project files.
61
00:02:45,920 --> 00:02:49,240
Those things are related, but they may not all need to live for the same amount of time.
62
00:02:49,240 --> 00:02:52,720
An early draft might only matter while people negotiate the deal.
63
00:02:52,720 --> 00:02:56,360
A casual team's message like "I've added the latest pricing" may have a short life.
64
00:02:56,360 --> 00:02:58,560
The final signed contract may need to stay much longer
65
00:02:58,560 --> 00:03:00,720
because it proves what both sides agreed to.
66
00:03:00,720 --> 00:03:03,440
This is why one rule for everything rarely works well.
67
00:03:03,440 --> 00:03:06,880
Pervue gives you three basic choices for how content should behave.
68
00:03:06,880 --> 00:03:10,440
The first choice is "keep only", "you keep the content for a set time"
69
00:03:10,440 --> 00:03:12,640
or "you keep it until someone makes another decision".
70
00:03:12,640 --> 00:03:15,480
The point is to prevent it from disappearing too early.
71
00:03:15,480 --> 00:03:17,320
The second choice is "delete only".
72
00:03:17,320 --> 00:03:22,000
Content can stay while people need it, but when it reaches a certain age, Pervue removes it.
73
00:03:22,000 --> 00:03:24,200
This often fits content with a short-use for life
74
00:03:24,200 --> 00:03:27,280
where the organization doesn't need to preserve it against early deletion.
75
00:03:27,280 --> 00:03:29,480
The third choice is "keep first" then delete later.
76
00:03:29,480 --> 00:03:32,880
This is the pattern many organizations need for normal business records
77
00:03:32,880 --> 00:03:35,000
keep the content for the required period.
78
00:03:35,000 --> 00:03:38,400
When that period ends, remove it automatically or send it for review.
79
00:03:38,400 --> 00:03:40,120
Each choice answers a different question.
80
00:03:40,120 --> 00:03:41,880
Do we need to guarantee this stays?
81
00:03:41,880 --> 00:03:43,920
Do we need to make sure this doesn't stay too long?
82
00:03:43,920 --> 00:03:45,160
Or do we need both?
83
00:03:45,160 --> 00:03:50,920
Keeping everything forever can sound like the safest choice, especially when people worry about losing a file they might need later.
84
00:03:50,920 --> 00:03:52,760
But all data brings its own risk.
85
00:03:52,760 --> 00:03:55,880
Old customer details may still exist in forgotten folders.
86
00:03:55,880 --> 00:03:58,840
Old drafts may confuse people trying to find the real agreement.
87
00:03:58,840 --> 00:04:02,120
Old chats and emails can become part of a search during an investigation,
88
00:04:02,120 --> 00:04:04,400
even when nobody has looked at them in years.
89
00:04:04,400 --> 00:04:08,600
And if an account or location is compromised, more retained data means more data exposed.
90
00:04:08,600 --> 00:04:10,760
So retention isn't only about keeping content,
91
00:04:10,760 --> 00:04:14,080
it's also about removing content when there's no reason to keep it.
92
00:04:14,080 --> 00:04:15,360
There's an important difference here.
93
00:04:15,360 --> 00:04:16,880
Accidental deletion is a mistake.
94
00:04:16,880 --> 00:04:18,440
A user deletes the wrong email.
95
00:04:18,440 --> 00:04:19,760
Someone overrides the document.
96
00:04:19,760 --> 00:04:23,120
A team removes a folder without realizing what sits inside it.
97
00:04:23,120 --> 00:04:24,840
Life cycle disposal is different.
98
00:04:24,840 --> 00:04:27,600
That happens because the organization agreed on a rule.
99
00:04:27,600 --> 00:04:31,960
The content reached the end of its approved lifespan and purview followed that instruction.
100
00:04:31,960 --> 00:04:32,920
One is an error.
101
00:04:32,920 --> 00:04:34,520
The other is planned housekeeping.
102
00:04:34,520 --> 00:04:38,680
For you, the starting point isn't a random number like three years, five years or seven years.
103
00:04:38,680 --> 00:04:39,600
Start with the reason.
104
00:04:39,600 --> 00:04:40,880
Why does this content exist?
105
00:04:40,880 --> 00:04:44,960
Who needs it? Is there a legal, regulatory, financial or business reason to keep it?
106
00:04:44,960 --> 00:04:48,720
And when that reason ends, should the content disappear or should someone review it first?
107
00:04:48,720 --> 00:04:50,320
Those answers create the rule.
108
00:04:50,320 --> 00:04:52,000
The number of years comes after that.
109
00:04:52,000 --> 00:04:54,120
Deciding the time is only half the job, though,
110
00:04:54,120 --> 00:04:57,320
because purview also needs to know where that rule belongs.
111
00:04:57,320 --> 00:05:00,400
Building block two, retention policies, the building wide rules.
112
00:05:00,400 --> 00:05:03,720
Once you know how long content should stay, the next question is simple.
113
00:05:03,720 --> 00:05:05,120
Where should that rule apply?
114
00:05:05,120 --> 00:05:06,840
Retention policies answer that question.
115
00:05:06,840 --> 00:05:11,760
A retention policy acts as a broad rule for a whole location in Microsoft 365, covering
116
00:05:11,760 --> 00:05:16,960
mailboxes in exchange online, a sharepoint site, one drive accounts or team's messages.
117
00:05:16,960 --> 00:05:20,800
Think of it like a rule posted at the entrance to one floor of your office building, and everyone
118
00:05:20,800 --> 00:05:24,160
on that floor follows the same rule because the space has one shared purpose.
119
00:05:24,160 --> 00:05:27,840
You don't need each person to stop, read every file and decide how long it should stay.
120
00:05:27,840 --> 00:05:30,480
The rule already applies because the content lives there.
121
00:05:30,480 --> 00:05:31,480
That saves a lot of guesswork.
122
00:05:31,480 --> 00:05:35,560
Imagine a company wants to keep all teams chat messages for two years, then remove them
123
00:05:35,560 --> 00:05:37,440
after those two years pass.
124
00:05:37,440 --> 00:05:40,640
Nobody should need to tag every message or remember whether a chat from Tuesday needs
125
00:05:40,640 --> 00:05:42,040
two years or two months.
126
00:05:42,040 --> 00:05:46,400
The organization creates one retention policy for teams chat messages, and purview applies
127
00:05:46,400 --> 00:05:49,000
that rule across the chosen people or locations.
128
00:05:49,000 --> 00:05:51,480
So every covered message follows the same lifespan.
129
00:05:51,480 --> 00:05:54,360
That's a good fit for broad, repeatable content.
130
00:05:54,360 --> 00:05:57,880
Teams chats are high volume and move fast, so most people don't stop mid-complication
131
00:05:57,880 --> 00:06:00,680
to think about what records category a message belongs to.
132
00:06:00,680 --> 00:06:03,800
A building wide rule handles that common content in the background.
133
00:06:03,800 --> 00:06:06,440
The same idea works for a department sharepoint site.
134
00:06:06,440 --> 00:06:10,800
Say the operations team has one sharepoint site for its working documents, containing meeting
135
00:06:10,800 --> 00:06:14,760
notes, process guides, planning files, and day-to-day team documents.
136
00:06:14,760 --> 00:06:18,600
If that whole site meets the same retention period, a policy can cover the site and its
137
00:06:18,600 --> 00:06:19,600
connected files.
138
00:06:19,600 --> 00:06:23,600
People can still create, edit, move, and delete their working files as part of normal work.
139
00:06:23,600 --> 00:06:27,400
But when the policy requires content to stay, a user deleting a file doesn't necessarily
140
00:06:27,400 --> 00:06:29,360
end that retention requirement.
141
00:06:29,360 --> 00:06:32,840
Purview can preserve the content behind the scenes for the required period.
142
00:06:32,840 --> 00:06:34,200
That part often surprises people.
143
00:06:34,200 --> 00:06:38,800
A user may think they deleted that email last month or that file is gone from the team site
144
00:06:38,800 --> 00:06:42,760
and from the user's point of view, it may be gone, but from the organization's retention
145
00:06:42,760 --> 00:06:48,680
point of view, purview can still keep a preserved copy while the required period continues.
146
00:06:48,680 --> 00:06:52,120
This isn't meant to turn every deleted file into something users can see forever.
147
00:06:52,120 --> 00:06:56,120
It means an organization can meet its agreed rule even when people clean up, make mistakes,
148
00:06:56,120 --> 00:06:57,120
or leave the company.
149
00:06:57,120 --> 00:07:00,840
That makes retention policies useful for content where consistency matters more than individual
150
00:07:00,840 --> 00:07:02,040
choices.
151
00:07:02,040 --> 00:07:06,720
A company may decide that all mailboxes in a certain department need the same rule because
152
00:07:06,720 --> 00:07:10,640
that department handles the same kind of work, so the policy applies to those mailboxes
153
00:07:10,640 --> 00:07:11,640
as a group.
154
00:07:11,640 --> 00:07:15,600
Or perhaps the business wants one common rule for AI interactions because those interactions
155
00:07:15,600 --> 00:07:19,800
can arrive in large numbers and users shouldn't need to decide the lifespan of every prompt
156
00:07:19,800 --> 00:07:20,800
or response.
157
00:07:20,800 --> 00:07:22,480
Again, that's a policy job.
158
00:07:22,480 --> 00:07:26,320
The rule applies based on location, not because a person made a choice for each item.
159
00:07:26,320 --> 00:07:27,440
There is a limit though.
160
00:07:27,440 --> 00:07:31,200
A retention policy looks at the place where content lives, not the business meaning of every
161
00:07:31,200 --> 00:07:32,880
individual file inside that place.
162
00:07:32,880 --> 00:07:37,440
A SharePoint site might contain an early contract draft, a final signed contract, a meeting
163
00:07:37,440 --> 00:07:39,080
agenda, and a lunch menu.
164
00:07:39,080 --> 00:07:43,480
A broad policy can apply one baseline rule across that site, but it can't naturally tell
165
00:07:43,480 --> 00:07:47,520
the final signed contract apart from the draft just because both documents sit in the same
166
00:07:47,520 --> 00:07:51,800
library that would be like giving every folder in one filing cabinet the exact same disposal
167
00:07:51,800 --> 00:07:56,120
date even though some folders contain rough notes and others contain binding agreements.
168
00:07:56,120 --> 00:07:58,560
Sometimes that's fine and often it's exactly what you want.
169
00:07:58,560 --> 00:08:03,160
Use retention policies when you have a clear repeatable rule for a whole location especially
170
00:08:03,160 --> 00:08:07,160
for high volume content such as chat messages or AI interactions.
171
00:08:07,160 --> 00:08:11,400
They reduce user effort, create consistent outcomes, and help keep common content under
172
00:08:11,400 --> 00:08:15,400
one shared rule, but when one file needs a different life from everything around it,
173
00:08:15,400 --> 00:08:18,440
the container-wide approach becomes too blunt.
174
00:08:18,440 --> 00:08:19,800
Building block three.
175
00:08:19,800 --> 00:08:20,800
Retention labels.
176
00:08:20,800 --> 00:08:22,120
The files own filing card.
177
00:08:22,120 --> 00:08:26,200
A retention policy works well when the location tells you what to do, but sometimes the
178
00:08:26,200 --> 00:08:28,520
location tells you almost nothing.
179
00:08:28,520 --> 00:08:33,320
One SharePoint library can hold drafts, final agreements, meeting notes, invoices, and documents
180
00:08:33,320 --> 00:08:34,840
people no longer need.
181
00:08:34,840 --> 00:08:39,360
And one mailbox can hold casual conversations right next to an email that confirms a major
182
00:08:39,360 --> 00:08:40,360
business decision.
183
00:08:40,360 --> 00:08:41,800
That's when retention labels help.
184
00:08:41,800 --> 00:08:45,840
A retention label is an item-level rule attached to one specific piece of content such as
185
00:08:45,840 --> 00:08:47,280
an email or a document.
186
00:08:47,280 --> 00:08:49,040
Think of a filing cabinet.
187
00:08:49,040 --> 00:08:53,400
Every folder inside it has a small card on the front that tells you what the folder contains,
188
00:08:53,400 --> 00:08:58,400
how long it stays in the cabinet, and what should happen when that time ends.
189
00:08:58,400 --> 00:09:02,400
The cabinet itself may contain hundreds of folders, yet not every folder follows the same
190
00:09:02,400 --> 00:09:03,400
schedule.
191
00:09:03,400 --> 00:09:05,000
That's the difference a label creates.
192
00:09:05,000 --> 00:09:07,920
The instruction belongs to the item, not just the place where it sits.
193
00:09:07,920 --> 00:09:09,480
Let's go back to the contract example.
194
00:09:09,480 --> 00:09:13,640
During a negotiation, a team creates several drafts, revising the wording, comparing versions
195
00:09:13,640 --> 00:09:15,200
and sending comments back and forth.
196
00:09:15,200 --> 00:09:18,840
Those drafts matter, while the deal is active, but they may not need the same long term
197
00:09:18,840 --> 00:09:21,000
treatment as the sign agreement.
198
00:09:21,000 --> 00:09:24,880
Once both sides sign, that final contract becomes a different kind of content because
199
00:09:24,880 --> 00:09:29,480
it proves the agreement, so the organization might apply one retention label to drafts,
200
00:09:29,480 --> 00:09:33,120
with a shorter lifespan and another label to sign contracts with a longer one.
201
00:09:33,120 --> 00:09:37,200
Both files might live in the same sharepoint site, or even sit in the same document library,
202
00:09:37,200 --> 00:09:40,200
but their labels tell per view that they have different business meanings and different
203
00:09:40,200 --> 00:09:41,200
instructions.
204
00:09:41,200 --> 00:09:45,280
That makes labels useful when the type of content matters more than its storage location.
205
00:09:45,280 --> 00:09:46,960
How does the label get onto the content?
206
00:09:46,960 --> 00:09:50,000
Sometimes a person applies it manually, which works when someone understands the business
207
00:09:50,000 --> 00:09:51,000
meaning of the item.
208
00:09:51,000 --> 00:09:54,680
A legal team member might know that an email confirms a final decision or a contract manager
209
00:09:54,680 --> 00:09:58,320
might know the document has moved from draft to sign agreement, and they choose the right
210
00:09:58,320 --> 00:10:00,240
label as part of their normal work.
211
00:10:00,240 --> 00:10:04,600
Still, people are busy and may forget or not know which label applies, and some organizations
212
00:10:04,600 --> 00:10:08,680
have far too much content for users to sort every item by hand.
213
00:10:08,680 --> 00:10:12,760
Per view can also auto-apply labels when it can identify content through defined conditions,
214
00:10:12,760 --> 00:10:16,680
such as matching a known type of information, words used in a document, or another condition
215
00:10:16,680 --> 00:10:18,360
the organization has set up.
216
00:10:18,360 --> 00:10:19,360
The point is simple.
217
00:10:19,360 --> 00:10:23,640
When Per view can reliably recognize a content type, it can apply the label without asking
218
00:10:23,640 --> 00:10:25,400
a user to remember every rule.
219
00:10:25,400 --> 00:10:29,200
But before relying on automatic labels, test them carefully because a label with the wrong
220
00:10:29,200 --> 00:10:34,080
condition can classify the wrong items, and a retention rule can affect content long after
221
00:10:34,080 --> 00:10:36,800
people forget why it was applied.
222
00:10:36,800 --> 00:10:38,320
Labels can also support records.
223
00:10:38,320 --> 00:10:42,400
A record needs stronger control because the organization must treat it as an official version,
224
00:10:42,400 --> 00:10:43,840
not just another working file.
225
00:10:43,840 --> 00:10:48,000
For example, the final sign contract may need to stay put, and people shouldn't casually
226
00:10:48,000 --> 00:10:51,760
edit it, replace it, or delete it because they want a cleaner folder.
227
00:10:51,760 --> 00:10:55,000
Using content as a record gives it that tighter treatment.
228
00:10:55,000 --> 00:10:58,840
It tells the organization that this item has reached a point where normal day-to-day editing
229
00:10:58,840 --> 00:10:59,840
should stop.
230
00:10:59,840 --> 00:11:03,560
When a label's retention period ends, Per view can follow different next steps.
231
00:11:03,560 --> 00:11:07,160
Some content can be deleted automatically because the business already agreed it no longer
232
00:11:07,160 --> 00:11:09,960
needs it, while other content needs a human check first.
233
00:11:09,960 --> 00:11:13,720
That's where disposition review comes in, rather than deleting the item immediately,
234
00:11:13,720 --> 00:11:17,400
the system can send it to the right people for review, and they can decide whether it should
235
00:11:17,400 --> 00:11:20,920
be removed, or whether there is a reason to keep it longer.
236
00:11:20,920 --> 00:11:22,920
The right choice depends on the content.
237
00:11:22,920 --> 00:11:26,640
Routine drafts may be safe for automatic deletion, while a former record may need someone
238
00:11:26,640 --> 00:11:28,400
to look at it before it goes.
239
00:11:28,400 --> 00:11:32,480
So use retention labels when you need the rule to follow the content itself, especially
240
00:11:32,480 --> 00:11:37,440
when two items in the same mailbox or SharePoint site have different jobs, different life spans,
241
00:11:37,440 --> 00:11:39,840
or different end-of-life steps.
242
00:11:39,840 --> 00:11:41,120
One complication remains.
243
00:11:41,120 --> 00:11:45,240
A labeled item can also sit inside a location covered by a broader retention policy, so
244
00:11:45,240 --> 00:11:49,120
Per view needs clear rules for deciding which instruction wins.
245
00:11:49,120 --> 00:11:52,440
In blog 4, scope and conflict rules, who gets which rule?
246
00:11:52,440 --> 00:11:54,760
A retention rule also needs an audience.
247
00:11:54,760 --> 00:11:58,480
You might know that finance content needs one schedule and HR content needs another, but
248
00:11:58,480 --> 00:12:02,720
Per view still needs a way to identify the right people, mailboxes and sites.
249
00:12:02,720 --> 00:12:03,880
That job is called scope.
250
00:12:03,880 --> 00:12:05,960
A static scope is the simple option.
251
00:12:05,960 --> 00:12:10,480
When you create the policy, you choose named users, mailboxes, SharePoint sites, OneDrive
252
00:12:10,480 --> 00:12:12,120
accounts, or other locations.
253
00:12:12,120 --> 00:12:15,280
You pointed the exact target and say, "This rule applies here."
254
00:12:15,280 --> 00:12:17,760
That works well when the target won't change much.
255
00:12:17,760 --> 00:12:20,760
Maybe you have one dedicated SharePoint site for a project.
256
00:12:20,760 --> 00:12:24,440
Maybe a small legal team has a known group of mailboxes, or perhaps a fixed list of
257
00:12:24,440 --> 00:12:27,120
executive accounts needs one common rule.
258
00:12:27,120 --> 00:12:28,360
Static scope is direct.
259
00:12:28,360 --> 00:12:32,480
You choose the targets, and the policy stays with those targets until an administrator changes
260
00:12:32,480 --> 00:12:33,480
it.
261
00:12:33,480 --> 00:12:34,480
But organizations change all the time.
262
00:12:34,480 --> 00:12:37,960
People join, people change jobs, departments grow, teams reorganize.
263
00:12:37,960 --> 00:12:41,640
If someone moves from sales into finance, do you want an administrator to remember every
264
00:12:41,640 --> 00:12:45,160
rule that should now apply to that person's email files and messages?
265
00:12:45,160 --> 00:12:46,160
Probably not.
266
00:12:46,160 --> 00:12:47,480
That is where adaptive scopes help.
267
00:12:47,480 --> 00:12:52,360
An adaptive scope uses details about people, groups, or sites to decide who belongs under
268
00:12:52,360 --> 00:12:53,360
a rule.
269
00:12:53,360 --> 00:12:56,520
Those details can include a department, job role, or location.
270
00:12:56,520 --> 00:12:59,240
Think of Entra ID as the reception desk for your digital office.
271
00:12:59,240 --> 00:13:02,480
When someone arrives, the reception desk knows who they are and where they belong.
272
00:13:02,480 --> 00:13:05,360
It can see details such as their department or job title.
273
00:13:05,360 --> 00:13:09,520
Per view can use those details to place the person under the right retention rule.
274
00:13:09,520 --> 00:13:12,120
Imagine an employee moves into the finance department.
275
00:13:12,120 --> 00:13:15,000
Their account changes to show finance as their department.
276
00:13:15,000 --> 00:13:19,240
An adaptive scope that looks for finance staff can recognize that change, so the finance retention
277
00:13:19,240 --> 00:13:20,800
policy can follow their account.
278
00:13:20,800 --> 00:13:24,720
Nobody needs to rebuild a list by hand every time a person changes roles.
279
00:13:24,720 --> 00:13:28,360
That makes adaptive scopes a good choice for larger organizations where membership moves
280
00:13:28,360 --> 00:13:29,360
often.
281
00:13:29,360 --> 00:13:33,520
They reduce the ongoing admin work because the rule follows the organization's own details.
282
00:13:33,520 --> 00:13:36,520
Still, adaptive isn't automatically the better choice every time.
283
00:13:36,520 --> 00:13:39,000
A fixed project site doesn't need a moving target.
284
00:13:39,000 --> 00:13:42,960
A short list of named mailboxes may be easier to manage as a static scope.
285
00:13:42,960 --> 00:13:45,640
Use static scope when the target is simple and stable.
286
00:13:45,640 --> 00:13:50,160
Use adaptive scope when the target should move as people, groups or sites change.
287
00:13:50,160 --> 00:13:53,880
Then there is the harder question, what happens when more than one rule applies to the same
288
00:13:53,880 --> 00:13:54,880
content?
289
00:13:54,880 --> 00:13:56,480
Per view has conflict rules for that.
290
00:13:56,480 --> 00:13:58,200
Start with the safest idea.
291
00:13:58,200 --> 00:14:00,040
Retention beats deletion.
292
00:14:00,040 --> 00:14:04,720
If one rule says content must stay and another rule says content should be deleted,
293
00:14:04,720 --> 00:14:08,320
Per view won't delete the content while the retention requirements still applies.
294
00:14:08,320 --> 00:14:12,920
When two retention rules apply for different lengths of time, the longer retention period wins.
295
00:14:12,920 --> 00:14:16,760
If one policy keeps content for three years and another needs it for seven, Per view keeps
296
00:14:16,760 --> 00:14:17,760
it for seven.
297
00:14:17,760 --> 00:14:19,880
The stronger obligation stays in place.
298
00:14:19,880 --> 00:14:23,520
Labels can also take priority over a broad policy because a label gives Per view a more
299
00:14:23,520 --> 00:14:26,120
specific instruction for that individual item.
300
00:14:26,120 --> 00:14:30,160
The site may have a general rule while one document inside that site carries its own label
301
00:14:30,160 --> 00:14:32,200
because it needs different treatment.
302
00:14:32,200 --> 00:14:34,720
Per view can follow that item level instruction.
303
00:14:34,720 --> 00:14:37,320
Deletion rules work differently when deletion is all that remains.
304
00:14:37,320 --> 00:14:41,360
If multiple deletion instructions apply, the shortest deletion period wins.
305
00:14:41,360 --> 00:14:44,720
That sounds complicated at first, but the pattern is sensible.
306
00:14:44,720 --> 00:14:46,400
Keep content when any rule requires it.
307
00:14:46,400 --> 00:14:48,320
Keep it for the longest required time.
308
00:14:48,320 --> 00:14:52,000
Then once no retention requirement remains, don't keep it longer than the deletion rules
309
00:14:52,000 --> 00:14:53,000
allowed.
310
00:14:53,000 --> 00:14:55,520
This is exactly why overlapping rules need planning.
311
00:14:55,520 --> 00:14:58,480
Don't create policies because a number of years sounds reasonable.
312
00:14:58,480 --> 00:15:03,440
Write down why the rule exists, who it covers, where it applies, how long it lasts, and
313
00:15:03,440 --> 00:15:05,120
what should happen at the end.
314
00:15:05,120 --> 00:15:06,880
Give every policy a clear name too.
315
00:15:06,880 --> 00:15:11,360
A name that tells you the audience, location, duration, and final action is far easier to
316
00:15:11,360 --> 00:15:15,080
understand than something vague like retention policy for.
317
00:15:15,080 --> 00:15:18,000
Before you create the settings, map three things.
318
00:15:18,000 --> 00:15:21,240
Map your people, map your locations, map your content types.
319
00:15:21,240 --> 00:15:25,200
Once those maps are clear, life cycle management starts to look less like a pile of settings
320
00:15:25,200 --> 00:15:27,320
and more like a connected system.
321
00:15:27,320 --> 00:15:28,640
How the parts connect?
322
00:15:28,640 --> 00:15:30,440
One rule book for your digital office.
323
00:15:30,440 --> 00:15:35,800
Put the pieces together and you get one rule book for your Microsoft 365 content.
324
00:15:35,800 --> 00:15:38,280
You set the normal rules for broad areas.
325
00:15:38,280 --> 00:15:40,880
Labels deal with the individual items that need special treatment.
326
00:15:40,880 --> 00:15:44,760
Scopes decide which people, sites, and groups enter each policy.
327
00:15:44,760 --> 00:15:47,240
Imagine an employee starts a contract draft in one drive.
328
00:15:47,240 --> 00:15:50,600
They share it with co-workers through teams where the team discusses changes.
329
00:15:50,600 --> 00:15:55,240
Later, the final signed version moves into a share point site where the project files belong.
330
00:15:55,240 --> 00:15:59,240
The draft and the final contract may travel through different places, but the organization
331
00:15:59,240 --> 00:16:02,040
can still apply clear instructions at each stage.
332
00:16:02,040 --> 00:16:05,880
A broad retention policy can set a baseline for the employee's working area.
333
00:16:05,880 --> 00:16:10,480
That baseline covers ordinary content, without asking the employee to make a records decision
334
00:16:10,480 --> 00:16:12,880
every time they save a file or send a message.
335
00:16:12,880 --> 00:16:16,200
Once the contract becomes the final signed version, a retention label can give that one
336
00:16:16,200 --> 00:16:17,800
document a longer lifespan.
337
00:16:17,800 --> 00:16:19,280
The location has its normal rule.
338
00:16:19,280 --> 00:16:21,320
The special document has its own instruction.
339
00:16:21,320 --> 00:16:25,120
If the employee changes department or moves to another location, an adaptive scope can update
340
00:16:25,120 --> 00:16:29,320
the baseline rule that applies to their account, based on the details held in Enter ID.
341
00:16:29,320 --> 00:16:33,160
The policy follows the person's role instead of relying on an old list that someone forgot
342
00:16:33,160 --> 00:16:34,160
to update.
343
00:16:34,160 --> 00:16:37,360
Retention also protects required content when a user deletes it early.
344
00:16:37,360 --> 00:16:41,760
The user may remove an email, file, or message from their view, but the retention requirement
345
00:16:41,760 --> 00:16:45,400
can continue behind the scenes until its time ends.
346
00:16:45,400 --> 00:16:47,160
Recovery tools handle a different problem.
347
00:16:47,160 --> 00:16:51,200
They help restore content after accidental deletion or unwanted changes.
348
00:16:51,200 --> 00:16:55,280
Version history, recycle bins, and other recovery options are about getting work back after
349
00:16:55,280 --> 00:16:56,800
something goes wrong.
350
00:16:56,800 --> 00:16:59,040
Retention is about meeting an agreed lifespan.
351
00:16:59,040 --> 00:17:00,360
Retention is about undoing a mistake.
352
00:17:00,360 --> 00:17:03,920
It also helps to know what data lifecycle management does not control.
353
00:17:03,920 --> 00:17:06,240
Retention decides how long content must remain.
354
00:17:06,240 --> 00:17:08,160
It doesn't decide who can open the document.
355
00:17:08,160 --> 00:17:11,600
It doesn't decide whether someone can share it with an outside person.
356
00:17:11,600 --> 00:17:16,080
Sensitivity labels and data loss prevention, often called DLP, handle those kinds of protection
357
00:17:16,080 --> 00:17:17,320
and sharing controls.
358
00:17:17,320 --> 00:17:20,600
A sensitivity label can mark content and apply protection.
359
00:17:20,600 --> 00:17:23,320
DLP can monitor or block risky sharing.
360
00:17:23,320 --> 00:17:25,800
Data lifecycle management handles the time question.
361
00:17:25,800 --> 00:17:29,200
How long does this content stay and what happens when that time ends?
362
00:17:29,200 --> 00:17:30,200
That is the full picture.
363
00:17:30,200 --> 00:17:31,480
You're not trying to keep everything.
364
00:17:31,480 --> 00:17:32,880
You're not trying to delete everything.
365
00:17:32,880 --> 00:17:36,920
You're deciding what should stay, why it should stay, and when it can leave on purpose.
366
00:17:36,920 --> 00:17:41,120
From there, you can build a safe first plan without jumping straight into a wide deletion
367
00:17:41,120 --> 00:17:43,120
rule.
368
00:17:43,120 --> 00:17:44,400
Actionable takeaways.
369
00:17:44,400 --> 00:17:47,480
Start by mapping out where your content actually lives.
370
00:17:47,480 --> 00:17:51,440
Exchange online, SharePoint, OneDrive, Teams, and even AI interactions if you're using
371
00:17:51,440 --> 00:17:52,440
them.
372
00:17:52,440 --> 00:17:56,000
The locations go to each business owner and ask for simple questions.
373
00:17:56,000 --> 00:17:59,520
What data exists, why keep it, how long should it stay, and what happens when that time's
374
00:17:59,520 --> 00:18:00,520
up.
375
00:18:00,520 --> 00:18:01,520
Keep it small at first.
376
00:18:01,520 --> 00:18:05,240
Pick one low risk, broad policy, and don't try to create dozens of exceptions on day
377
00:18:05,240 --> 00:18:06,240
one.
378
00:18:06,240 --> 00:18:07,920
Here's a quick test to keep things straight.
379
00:18:07,920 --> 00:18:11,880
If a rule applies to a location that's a policy, if it applies to one special item, that's
380
00:18:11,880 --> 00:18:12,880
a label.
381
00:18:12,880 --> 00:18:15,840
And if it follows changing stuff, that's an adaptive scope.
382
00:18:15,840 --> 00:18:20,400
Always agree on deletion before you enable it and use review where a human needs to decide.
383
00:18:20,400 --> 00:18:25,080
From every policy clearly, test older content carefully and check overlaps with legal, records,
384
00:18:25,080 --> 00:18:26,720
compliance, and the business owners.
385
00:18:26,720 --> 00:18:28,560
Pick one content type this week.
386
00:18:28,560 --> 00:18:31,880
Define its lifespan in plain English, then build the rule around that decision.
