A signed contract disappears from a shared folder.
Nobody knows who removed it, whether it should still exist
or whether a copy lives somewhere else.
With paper records, the process was more straightforward.
You had a filing cabinet, a locked drawer,
and a retention schedule that told you exactly
how long to keep each box.
Then, on a planned date, someone approved it for shredding.
Work doesn't happen that way anymore.
A contract might sit in SharePoint,
the approval email in Exchange Online,
and the discussion in Teams, while someone also has a copy
in one drive, so what exactly keeps all of that under control?
Microsoft Per View Records Management
is the part of Microsoft Per View
that helps your organization keep official records
protected for the required time,
then dispose of them in a controlled way when that time ends.
That sounds simple, but the risk of getting it wrong is serious.
If someone asks why you kept a document,
changed it, or deleted it, we think that's what happened,
isn't a good answer.
You need a clear rule, a clear process,
and a history of what people did.
Think of Microsoft 365 like a modern office building.
SharePoint, OneDrive, Exchange Online,
and Teams are the rooms where work happens.
Per View Records Management works behind the scenes.
That isn't another app where most employees spend their day.
It's more like the records office in the basement,
setting rules for which paperwork becomes official,
how long it stays, and when it can leave the building.
In this knowledge nugget, we'll first separate an ordinary file
from an official record, then look at the rule attached
to that record, the controls that protected,
the review before deletion, and the audit history
that helps you show what happened.
First, we need to answer the question
behind every record rule, what actually counts as a record.
A record is more than a file.
A record is official evidence that your organization
did something, decided something, approved something,
or agreed to something.
That could be assigned contract, a final financial report,
an employee record, or an approved company policy.
The word official matters here.
Your team might create 10 drafts of a policy
before leadership approves the final version.
Those drafts are part of the work,
but they don't all carry the same weight as the approved policy
that tells people what they must do.
Think about a contract.
While people negotiate, you have word documents
with tracked changes, comments, and names
like contract final V3, or contract final V3 really final.
Those are working files that people expect to change.
Then the agreement gets signed, and that signed copy
becomes evidence of what both sides agreed to.
The email that confirms final approval may matter too,
and those items need more care
because they may answer a question years later,
what did we agree to?
Who approved it, when did the agreement end?
That's why not every file should get the same treatment.
If you treat every draft, chat, note, and download
like a formal record, you create a huge pile of content
that becomes hard to manage.
You also keep more information than you need,
but if you fail to protect the official items,
you can lose the evidence your organization relies on.
Records management helps you draw that line.
For each type of record, your organization
needs a plain rule with three parts.
First, the retention trigger.
What starts the clock?
Sometimes it's simple.
You might retain a final report for a set number of years
after the file is created.
Other records follow a business event instead.
A contract may need to stay for a number of years
after the contract ends, and employee file
may need to stay for a period after the employee leaves.
In both cases, the file's creation date
isn't the main date that matters.
The business event is.
Second, the retention period, how long you keep it?
Your organization decides this based on its own business,
legal, and compliance needs.
Per view doesn't decide whether a contract belongs
for five years or seven years.
The people who own the business process,
along with legal or compliance teams,
decide that rule.
Third, what happens when the time ends?
Maybe the record can be deleted,
maybe someone needs to review it first,
or maybe another business process needs to happen
before disposal.
The key is that the end action should be planned
from the start, not guessed years later,
when folders are already full.
Let's go back to that signed contract.
The rule could read like this.
Keep the signed agreement for seven years
after the contract expires, then send it for review
before deletion.
That one sentence gives you the trigger,
the period, and the end action.
This is how a paper retention schedule becomes
something Microsoft 365 can follow.
The business team knows what the record means,
and when the contract ends, compliance teams
help define the required rule,
and Microsoft 365 admins turn that approved rule
into a control that works across the places
where content lives.
So you don't start with technology.
You start by deciding which files count
as official evidence when their clock should start,
how long they need to remain,
and what should happen at the end.
Once you have that answer,
purview can attach the right rule directly to the item.
Retention labels are the rule book.
So once you know an item needs a rule,
purview uses a retention label
to attach that rule to the item.
Think of a retention label as a digital rule card
attached to a document, an email, or any piece of content.
The label tells Microsoft 365 when to start counting,
how long to keep the item,
and what should happen when that time runs out.
And that matters because a contract
doesn't always stay in one neat folder.
Someone might move it, a team might reorganize a sharepoint
side, or the business might work with the file
through teams, and the underlying file still
lives in sharepoint.
The label stays focused on the item,
so the retention rule stays connected to the content that
needs it.
For a formal record, that control
at the item level gives you much more precision
than a broad rule over an entire location.
Let's use a simple example.
You create a retention label called contract seven years
after expiry, then disposition review.
Even without seeing the admin screen,
you can understand the intent.
The clock doesn't start when someone first saves the contract.
It starts when the contract expires,
and then purview keeps the record for seven years.
When those seven years are complete,
purview doesn't just treat the item
like an old download in a folder,
but instead sends the record into the review process
defined by your organization.
That is the rule book.
A retention label has three questions built right in.
When does the clock start?
How long does the records stay?
What happens at the end?
The first question is more important than it sounds.
For a simple document, the clock might start
when the item is created, last changed,
or when the label was applied.
But many business records follow an event outside the file
itself, like a contract ending, an employee leaving,
or a project closing.
In those cases, the record needs a rule
that follows the business event, not just the day
someone uploaded a PDF.
This is where beginners often mix up retention labels
and retention policies.
They sound similar because both can tell Microsoft 365
to keep or delete content over time,
but they work at different levels.
A retention policy is like applying one house rule
to a whole area.
For example, you could apply a broad policy
to an exchange online mailbox, a SharePoint site,
or Teams messages.
That makes sense for general content
where one consistent rule covers a lot of information.
Maybe your organization keeps general Teams messages
for a set time, or maybe all content in a broad business site
needs a baseline retention period.
A retention label is more focused.
It tells purview.
This particular item belongs to this record category,
so give it this specific rule.
That makes labels a better fit for official documents
that need their own retention path,
especially when the clock starts from a business event
or the item will need a control decision at the end.
You can use both approaches in the same connected platform,
but they solve different problems.
Policies handle broad coverage, while labels
handle the records that need individual treatment.
The next question is, who puts the label on the item?
In some cases, a person applies it manually,
which works when someone has the business knowledge
to recognize an official record at the right moment,
like when a final agreement arrives
or a policy receives approval.
But relying on people to remember every label every time
can be difficult.
Per view can also apply labels automatically
when your organization defines clear conditions
for matching the right content, using known signals,
set properties, or other conditions
that identify the type of item.
Instead of following users around and asking them
to choose from a long list, the organization creates the rule
and purview applies it in the background.
The smart approach depends on the record type.
If a person must make a judgment call, manual labeling may fit.
But if a record follows a clear pattern,
automatic labeling brings more consistency,
either way the label turns a written retention schedule
into something Microsoft 365 can act on.
For you, the practical step is simple.
Take one written rule and make sure it
answers those three questions clearly.
What starts the clock?
How long does the item stay?
What happens when the time ends?
A label can tell per view to keep an item,
but the next building block adds a stricter control
treating that item as official evidence
rather than ordinary working content.
Record declaration locks the evidence.
A retention label tells per view how long an item needs to stay
and record declaration takes the next step
by marking that item as an official record
and applying stricter controls around it.
Think of an ordinary working file as paperwork sitting
on someone's desk where people can update it, add comments,
and replace it while the work is still moving.
A declared record is the final signed paperwork
moved into a locked archive room.
The work may continue around it,
a new policy version may be written or a contract
may be renewed, but the declared record preserves
the official version that existed at that point in time.
So why does that lock matter?
Because official records can become evidence.
An auditor may need to see the approved financial report
from a certain year.
A legal team may need to find the signed agreement
that covered a dispute or an internal investigation may need
to confirm which policy applied when a decision was made.
In each case, the question isn't only whether we can find
a file, but also whether we can trust this is the file
that existed at the time.
That's what record declaration is designed to support.
Consider a final company policy.
During the writing process, different people
might edit the policy, add notes or ask for changes,
but once the policy receives approval,
that approved version can become the record.
And declaring it as a record helps protect that version
for the required time.
The same idea applies to a signed agreement.
You don't want the official signed copy treated like an ordinary draft
that someone can quietly replace, edit, or remove
because they were cleaning up a folder.
A completed employee record can work the same way.
Once it becomes the official business evidence,
the organization can apply a record label
to keep it protected through its retention period.
There's an important point for beginners here.
Records management controls retention across time,
making sure an official item remains available
for as long as the rule requires,
even if someone tries to delete it before that period ends.
And it also adds record controls
that help preserve the item's evidence.
But records management doesn't do every form
of protection in Microsoft Perview.
It doesn't encrypt a document, decide who can open a document,
or stop someone from sending sensitive information
to the wrong place.
Those are different jobs.
A sensitivity label protects access and sharing,
and you might use it to apply encryption or limit
who can open a file.
Data loss prevention or DLP watches
for risky movement of sensitive information
and can help detect or block actions
like sharing protected information in ways your organization
doesn't allow.
Records management answers a different question.
How long must this official evidence stay?
And what controls should apply while it stays?
Picture a signed contract that contains confidential terms.
A sensitivity label can control who has access to it.
DLP can watch for risky sharing,
and a retention label that declares it as a record
controls its life as evidence.
Keeping the contract from disappearing
before it's required retention period ends.
These tools can work together, but they shouldn't be confused.
One protects the document while people use it
and the other protects the business obligation across time.
That difference helps you avoid a common mistake.
Treating a record label like a general security setting,
it isn't.
A record label is the rule that tells Microsoft 365
this item is official evidence.
Keep it according to this schedule
and apply the stricter record controls we've chosen.
That also means you need to be thoughtful
before declaring something as a record.
Once you lock every rough draft, duplicate, and informal note,
you make normal work much harder because the goal
is to protect the final official evidence,
not freeze every piece of content the moment it appears.
Keeping a record is only half the job, though.
Every retention rule eventually reaches a harder question.
When the required time ends, who decides
that the record can finally go?
Disposition review is the gate before deletion.
Keeping a record for the right amount of time
is only half the story.
The other half is what happens when that time runs out.
That decision is called disposition and it needs care.
Delete a record too early and your organization
could lose evidence it still needs for a legal case
and audit or a business dispute.
Keep every expired record forever
and you end up with a growing pile of old content,
more information to protect and more material
that could be requested in a lawsuit.
Per view records management gives you a gate
between those two risks.
It's called disposition review.
Think about the old paper process for a second.
A box reaches its planned destruction date
but nobody should feed it straight into the shredder
without checking it first.
Someone responsible for the records
looks at the box, confirms nothing has changed
and then approves what happens next.
Disposition review brings that same decision
into Microsoft 365.
When a record reaches the end of its retention period,
per view can send it to designated reviewers
instead of deleting it right away.
The reviewer opens the item in the purview portal
and decides whether the record can be permanently deleted.
That review gives your organization
one final chance to ask a practical question.
Is there any reason we still need this?
Take our contract example.
The contract ended and its seven year retention period
has now finished.
At that point, the contract reaches the disposition review Q.
The reviewer checks whether there is an ongoing dispute,
a legal request or another business reason to keep it.
If nothing requires the contract to remain,
the reviewer can approve disposal.
If the contract is still relevant,
the reviewer can pause the process
instead of letting it disappear just because a date arrived.
That is a much safer process than a calendar reminder
that somebody may miss.
A simple record type might need just one review stage.
For example, a records team could review routine contracts
that have reached their end date.
One group checks the Q, makes the decision
and completes the process.
Other record types may need more than one stage.
A sensitive financial record might need a business owner
to confirm it is no longer needed,
followed by a compliance or records team review
before the final action.
Per view can support that kind of multistage review
where the record passes through more than one approval step.
More stages bring more control,
but they also create more work.
So you should match the process to the risk of the record.
Don't build a longer approval chain for every ordinary item.
At the same time, don't give one person
the final decision on records that need legal, finance,
or compliance input.
There's one practical setup choice that saves trouble later.
Assign reviewers through a maintained group
when you can instead of naming one person.
People change jobs, they take leave, they leave the company.
A group can continue to own the review work
as its members change, which means records don't sit
in a queue waiting for somebody who no longer works there.
You also need to plan permissions.
Being a general Microsoft 365 admin
doesn't automatically mean someone can review records
waiting for this position.
The people who need to see an act on these items
require the right records management permissions.
That's worth checking before you switch on a label
that sends large amounts of content into review.
For you, the starting point is not the purview screen.
Write down who owns the final decision for each record type.
Ask who can confirm that the record is no longer needed,
who needs to approve disposal,
and what should happen if a reviewer finds
an active legal or business reason to keep it.
Once those answers are clear,
purview can root the record through a repeatable process.
After a record has been kept reviewed and disposed of,
one more question remains.
Can you show what happened?
Audit history provides the proof.
Records management is not only about setting a rule,
it's also about being able to show that people followed it.
That is where audit history comes in.
Microsoft purview audit keeps a centralized history
of activities across Microsoft 365.
Depending on the activity and your audit setup,
it can help you investigate who acted, what they did,
and when they did it.
For records work, that matters when someone asks questions
after the fact.
Imagine an auditor asks why a signed contract no longer exists.
You need more than an empty folder and somebody's memory.
Your organization should be able to connect the dots.
The contract had a retention label.
The retention period reached its end.
The correct reviewer approved the disposition decision
and the activity was recorded.
That creates a trail you can examine.
Maybe the question is different.
Who applied the label to this item?
Did someone try to delete it before the retention period ended?
When did the reviewer approve its disposal?
Audit history can help answer those questions
by providing recorded activity from across the Microsoft 365 platform.
There is one distinction that often surprises beginners.
The audit history does not live inside the document itself.
You won't open a word file and find
its complete audit trail stored in the file.
Purview stores that activity in the unified audit log,
which is a central place for audit records across services
such as SharePoint, OneDrive, Exchange Online, Teams, and EntraID.
Think of it as the building's visitor and activity register,
not a note-clipped inside each piece of paper.
That means you need to think about audit retention
separately from record retention.
A record might need to stay for many years.
The audit information available to you
depends on how your organization has set up, purview audit,
and what licensing it has.
If you need a long history of record-related activity,
confirm that your audit set up keeps that history
for the period your organization requires.
Otherwise, you could still have the record,
but lose access to older activity details
that would help explain its journey.
This is why record decisions cannot sit with one team alone.
Business owners understand the records their teams create.
Compliance and legal teams define the rules
and the proof they need.
Microsoft 365 Admins configure the labels,
review permissions, and audit settings
that make those rules work.
Each group holds part of the answer.
The retention label defines the rule.
Record declaration protects the official evidence.
Disposition review controls the decision at the end.
Audit history documents the trail around those actions.
For you, the practical question is simple.
If someone challenged a deletion years from now,
could your organization show the rule, the approval,
and the recorded activity that led to it?
If not, the record may be protected,
but the process still has a gaps in the digital records life cycle.
So put the pieces together and Perview Records Management
gives official content a controlled path
through its working life.
First, your organization identifies what counts as evidence.
Then the right retention label attaches the approved rule.
If the item meets formal record controls,
it gets declared as a record.
Perview keeps it for the required time,
sends it for review when that time ends,
and audit keeps the history that explains the result.
That's the big picture.
Think of it like a digital filing cabinet with a built-in timer.
Now Perview doesn't sort every file into neat folders for you.
It applies a defined life cycle to the records that matter most.
In the old approach, teams relied on folders, spreadsheets,
calendar reminders, and memory.
In Microsoft 365, the record might live in SharePoint,
OneDrive, Exchange Online, or Teams.
Perview manages its rule in the background.
Before anyone creates a label,
start with the business decision behind it.
Start with one record type, like signed contracts,
employee records, or final financial reports.
Write its rule in plain English.
What starts the clock?
How long does it stay?
And what happens when the period ends?
Then name the business owner and the disposition reviewers
before you configure anything in Perview.
That gives you a working records process,
not just a setting in a portal.
Subscribe on your favorite podcast platform for more knowledge nuggets
and share this with someone sorting out Microsoft 365 compliance.