Choosing a Document Management Platform

SCSB is regularly asked to repair a document library that has stopped being usable: files nobody can locate, permissions nobody can account for, and no agreed position on what should be kept or removed. The pattern is consistent across Malaysian organisations, and it is rarely resolved by moving to a different product. What follows is the sequence SCSB works through before any platform is configured.

Start with the information, not the interface

A document-management project is usually framed as a choice of product. The more useful starting point is the information the organisation needs to create, find, share, retain and protect. Identify the document categories, the business processes that produce them, the users, the access restrictions, the retention decisions, and the person accountable for each area.

This matters because most document-management failures are not platform failures. A capable platform configured against an unclear information model reproduces the problems of the file share it replaced — duplicated files, uncertain final versions, and access nobody can explain — with a larger bill attached. The platform decision is the easy part. The decisions about who owns what, and for how long, are the work.

Build a requirements record before you look at a platform

For each priority document type, write down where it originates, who may access or amend it, how a version becomes final, how long it should be kept, how it is retrieved, and what happens when an employee changes role or leaves. Record the exceptions that matter in practice rather than only the clean path.

• External sharing: which document types may leave the organisation, to whom, and under what conditions.
• Legal holds: which categories could become subject to a hold, and who would be told.
• Duplicates: where the same document legitimately exists in more than one place, and which copy governs.
• Records held outside the platform: email attachments, personal drives, third-party portals and paper.
• Personal data: which categories contain personal data, since that shapes both access and retention decisions.

This record is what makes a demonstration meaningful. Without it, every platform demonstrates well.

Separate the three controls that are routinely confused

Permissions, sensitivity labels and retention are frequently treated as one “security” decision. They answer different questions, are owned by different people, and fail in different ways.

• Permissions determine who can reach a document now, in the location where it currently sits.
• Sensitivity labels classify the content itself and can apply protection to it. Microsoft documents that a sensitivity label is stored in clear text in the file or email metadata and is persistent, so the label stays with the content wherever it is saved, and that a label can apply encryption, content markings such as headers, footers and watermarks, container protection for sites and groups, and default sharing-link scope.
• Retention determines how long an item is kept and what happens at the end of that period, independently of who can see it.

Two documented details are worth knowing before designing the scheme. Microsoft states that each item supporting sensitivity labels can have a single sensitivity label applied to it from the organisation, while documents and emails can carry both a sensitivity label and a retention label. And deleting a sensitivity label from the administration portal does not remove it from content: any protection settings continue to be enforced on content that already carried it.

On scheme size, Microsoft’s own guidance is blunt and worth quoting to anyone designing a ten-label taxonomy: real-world deployments show effectiveness is noticeably reduced when users have more than five main labels, or more than five sublabels per main label. Fewer, clearer labels are applied correctly more often than a comprehensive scheme nobody can navigate.

Understand how retention resolves conflicts before you configure it

Retention and sensitivity labelling across Microsoft 365 are administered through Microsoft Purview, and its precedence rules determine the outcome when two policies disagree.

Retention is where assumptions cause the most damage, because the consequences appear only when someone tries to delete or recover something.

Microsoft’s retention documentation sets out the order in which conflicting settings are resolved. By default, retention takes precedence over permanent deletion, and the longest retention period wins. Where deletion conflicts remain, an explicit setting wins over an implicit one — a delete action from a retention label takes precedence over a delete action from any retention policy, because the label applies to an individual item rather than being inherited from a container. Only where that does not settle the outcome does the shortest deletion period decide it.

Three practical implications follow.

1. Layering additional retention settings “to be safe” does not produce a cautious outcome. It produces the longest one, which may sit awkwardly against a data-minimisation position under the Personal Data Protection Act 2010.
2. A retention period is a decision about the organisation’s legal, contractual and operational obligations. It should be set by whoever owns those obligations, on advice where the answer is not obvious, and not defaulted during configuration by whoever happens to be in the admin console.
3. Items under an eDiscovery hold cannot be permanently deleted by any retention policy or label while the hold is in effect. When the hold is released, the ordinary rules resume.

Plan for the departing employee before someone leaves

The most common operational surprise is what happens to a leaver’s files, and Microsoft documents the deletion sequence precisely enough to plan around.

The cleanup process begins when the user account is deleted from Microsoft Entra ID — not when the person is blocked from signing in, and not when their licence is removed. By default the user’s manager is given access to the OneDrive content, and a secondary owner can be configured for users with no manager set. Microsoft is explicit that if access delegation is disabled and neither a manager nor a secondary owner is set, nobody receives automatic access and nobody is warned that the content will be deleted.

The default retention period for a deleted user’s OneDrive is 30 days, configurable in the SharePoint admin center. After that period the content moves to the site collection recycle bin, where it is kept for 93 days, and restoring it requires PowerShell. Microsoft also notes that the recycle bin is not indexed, so searches do not find content there and an eDiscovery hold cannot locate content in order to hold it. Separately, unlicensed OneDrive accounts are automatically archived on their 93rd unlicensed day.

Microsoft 365 retention settings take precedence over this standard deletion process in both directions: content covered by a retention policy can be retained well beyond 30 days, and content covered by a deletion action can go sooner. The offboarding checklist and the retention design therefore have to be written together. Testing this path once, deliberately, is considerably cheaper than discovering it during a dispute.

Migration is where the information model is actually tested

SCSB treats migration as the point at which the decisions above are proven or found wanting, rather than as a file-copying exercise.

Moving content from a file share exposes every decision that was deferred. Budget for it as analysis, not as a copy operation.

• Naming and structure. Microsoft documents characters that are not permitted in file and folder names, restrictions on leading and trailing spaces, and reserved names. Deeply nested folder structures carried over unchanged are a common source of failed or truncated migrations, and path-length limits differ between apps and versions.
• Volume and file size. Individual files are supported up to 250 GB, and Microsoft’s recommended limit is 300,000 synced items across cloud storage. Very large libraries and heavy sync scopes need a deliberate design rather than a lift-and-shift.
• What does not move. Obsolete content, superseded drafts and duplicate copies are cheaper to retire than to migrate, classify and then retain for years. Decide the disposal position before the migration, with the owner who can authorise it.
• Permissions. Inherited folder permissions accumulated over a decade rarely reflect current roles. Rebuild access from the requirements record rather than replicating what exists.

Test the scenarios that expose a weak configuration

Use authorised representative documents and real users, and record the expected result alongside the evidence observed. Test the situations that reveal weakness rather than the ones that flatter the configuration:

• a departing employee’s files, run end to end through the actual offboarding process;
• a document shared externally and then revoked, checked from the external recipient’s side;
• a file deleted in error and recovered, with the recovery time measured;
• a document subject to two different retention settings, to confirm the outcome matches the principles above;
• a search run by someone who does not already know where the document lives.

The last one decides adoption. Findability, not feature coverage, determines whether people use the system or quietly keep working somewhere else. A successful demonstration does not establish that the organisation’s information governance, privacy or records responsibilities have been met.

Keep responsibility clear

In SCSB’s experience this is the control that decays first, because it is the only one that depends on people rather than configuration.

Platform settings, user training and periodic review need named owners with the authority to decide. Classification schemes drift, permissions accumulate, and retention decisions age as contracts and obligations change, so a review cycle with an owner is part of the design rather than an optional extra.

Where a decision requires a privacy, legal, contractual or records-management conclusion, obtain advice from the responsible internal function or adviser. Configuring a control is not the same as discharging the underlying obligation, and a correctly configured retention policy is evidence of a decision, not proof that the decision was right.

It is also reasonable for a smaller organisation with a narrow document set, clear ownership and internal capability to configure this itself using Microsoft’s documentation. The case for implementation support strengthens with the number of document types, the number of people who must be trained, the presence of external sharing and personal data, and the consequences of getting retention wrong.

Next step

Where an organisation has defined its document types, access decisions and retention requirements, the SharePoint and OneDrive information architecture is configured as part of SCSB’s Microsoft 365 implementation service. Classification decisions, retention periods, consent handling and records obligations remain the responsibility of the organisation and its legal or compliance advisers.

Microsoft, Microsoft 365, Microsoft Entra ID, Microsoft Purview, OneDrive and SharePoint are trademarks of the Microsoft group of companies.

This article is general information about platform selection and configuration. It is not legal advice and does not determine any organisation’s obligations under the Personal Data Protection Act 2010 or any other requirement. Product behaviour and regulatory guidance change; confirm the current position with the relevant authority, with Microsoft, and with the organisation’s own advisers before relying on it.