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.