SharePoint Information Architecture in Nigeria: Structure, Naming, and Metadata
SharePoint makes it easy to store documents. The harder part is deciding how to organise those documents so someone else can find them six months later.
A document can be in the right library and still be hard to find if its filename is inconsistent, its metadata is missing, or the structure reflects an old reporting line rather than how the business works day to day.
Good information architecture gives documents a predictable place, a consistent name, and enough metadata to answer questions that folders alone cannot. In SharePoint, those three decisions are closely connected: structure, naming, and metadata.
Where This Fits
Access control and retention both depend on reliably identifying documents. That is why information architecture comes first in the governance model. It forms Pillar 1 of Document Management Governance in Nigeria.
This article focuses on structure, naming, and metadata. Physical implementation, department-by-department library design, and permissions belong to SharePoint Document Management in Nigeria instead.
Structure Follows Workflow, Not the Org Chart
Structure determines where information lives, naming determines what files are called, and metadata describes them in ways folders alone cannot. Getting structure wrong undermines the other two, so it’s worth establishing first.
Why the Org Chart Fails as a Structure
The org chart answers who owns a piece of work. Information architecture answers how information moves through the business as that work happens. Problems start when a structure mirrors the first question instead of the second.
A structure named after the current head of a department, “Amaka’s Team,” “Legal (Tunde),” has to be renamed whenever that person changes roles or leaves. A structure named after the function itself, “Contract Review,” “Vendor Onboarding,” survives that change untouched, because the work still exists even when the person doing it doesn’t.
The problem becomes harder to ignore once a document touches more than one department. A vendor contract typically involves Procurement, Legal, and Finance at different stages. If it lives under Procurement because Procurement created it, Legal has to know to look there; if Legal keeps its own copy, the business now has two potential sources of truth.
Finance, Legal, HR, and Operations libraries each implement this differently. SharePoint Document Management in Nigeria walks through those implementation choices in full. Here, the test is simpler: does the structure describe the work, or today’s staff list?
Stage-Based Structure, and a Geography Trap
Workflow can also show up as a stage rather than a department. A contract structure organised around stages such as Draft, Under Review, Approved, and Archived tracks a document’s actual life rather than who currently owns it. A document moving through those stages doesn’t need a new home each time; it needs a status that changes.
The same trap catches businesses with more than one location. A company with offices in Lagos, Abuja, and Port Harcourt might default to a library per city without asking whether the work itself is location-specific.
A finance process is usually the same process regardless of which office initiated it; structuring around geography when the workflow doesn’t vary by location just recreates the department problem with cities instead of teams.
The fix is the same one that applies to departments: structure around the workflow itself, and let location live in a metadata field if it’s worth tracking at all, rather than building the primary structure around it. A search or report can still filter by office when that distinction genuinely matters, without every document needing a separate home per city.
Choosing Between Approaches
None of stage-based, function-based, or department-based structure is universally correct; the right choice depends on how the documents get used day to day.
A stage-based structure works well when documents move through clear sequences, such as contracts under negotiation, expense claims awaiting approval, or onboarding packets in progress. The stage is often the first thing someone searching for the document knows.
A function-based structure works better for documents that become reference material once finished, such as signed agreements, completed policies, and closed reports.
Many businesses benefit from both: stage-based structure for documents still in motion, and a function-based archive for where they land once they’re finished.
Naming Conventions
A naming convention is only useful if two different people can apply it and produce the same result. If every employee has to make their own judgement about how a filename should look, the convention will eventually fragment. What breaks a naming convention in practice is inconsistency: half a team abbreviating a client name one way, half spelling it out, search quietly failing for everyone.
The Core Elements
A convention needs an unambiguous date format, consistent treatment of abbreviations, and a version-numbering rule that leaves little room for interpretation. Nigerian business names create a practical issue: if one person uses “Eko Electricity Distribution Company” and another uses “EEDC,” the convention needs to specify which form to use.
Version numbering is where conventions quietly fall apart even when everything else works. “v1” and “v2” sort correctly and mean the same thing to everyone. “Final,” “Final2,” and “Final-Approved” don’t sort at all, and each one implicitly claims to be the authoritative copy with no way to check which claim is true.
The date format matters for the same reason: sorting, not aesthetics. 2026-03-15 sorts chronologically without extra work. 15-03-2026 doesn’t, and March 15 2026 sorts alphabetically by month name, which isn’t the same as sorting by time.
What Stays Out of a Filename
Anything that changes after a file is created, such as a status, reviewer’s name, or approval stage, belongs in metadata instead. Editing a filename every time a document’s status changes just reintroduces the inconsistency the convention was meant to prevent.
Putting It Together
A document type, a client or project reference, a date in year-month-day order, and a version number cover most of what a filename needs to communicate at a glance: Invoice-EEDC-2026-03-15-v2.pdf tells a reader what it is, who it’s for, when it was created, and that it is version 2, without opening the file.
The same structure carries over to other document types without new rules: Contract-EEDC-2026-01-10-v1.pdf, Report-EEDC-2026-03-31-v1.pdf. Only the document type at the front changes, which is what makes a convention learnable in one sitting rather than relearned for every kind of file.
Naming conventions also fail when they become too complicated. A fifteen-rule standard with exceptions for edge cases teaches nobody anything; people abandon it within a few weeks. The goal is a convention simple enough that a new hire can apply it correctly on day one.
Metadata Taxonomy
Folders and metadata answer different questions.
| What it answers | Best suited to | |
|---|---|---|
| Folders | Where does this document live? | Daily browsing, content people already know how to navigate |
| Metadata | What is this document? | Cross-cutting questions folders can’t filter for |
Why It Matters in Practice
Consider a compliance officer asked for every contract renewing this quarter. A folder structure, however well organised, answers “where are the contracts.” It cannot answer “which of these renew in the next ninety days” without someone opening every file. Metadata answers that directly: filter on document type and renewal date, and the list exists in seconds.
A CBN examiner requesting every credit approval memo issued in the last financial year hits the same wall from a different angle. The memos exist, scattered across individual loan officers’ folders, and without a document-type field there’s no way to compile the list except by asking every officer to check their own files.
Designing the Fields
What matters is not the number of fields but how they are designed. Common fields include document type, status, owner, and date, although the right combination depends on what a given library needs to support.
A financial services business tracking CBN reporting deadlines may need fields that would serve little purpose in a manufacturing environment. The specific field set depends on the platform, industry, and document processes involved; SharePoint Document Management in Nigeria has that implementation detail.
Two principles matter most. The first is controlled vocabularies over free text: a dropdown of fixed department names prevents “HR,” “Human Resources,” and “HR Dept” from fragmenting into unrelated values a filter can’t reconcile.
This matters beyond search. A retention rule applied to “Contract” only works if every contract is tagged consistently, and a compliance report pulling everything flagged “Confidential” only catches what was tagged that way in the first place.
The second is treating folders and metadata as complementary rather than competing: folders for the daily-browsing structure people already understand, metadata for the cross-cutting questions folders were never designed to answer.
How Information Architecture Supports Compliance
When an NDPC request, a CBN examination, or an internal audit requires a business to produce a defined set of records, the same problem appears underneath: can the business identify that set reliably and completely?
That operation depends on the naming and metadata decisions covered above. Structure and naming make a document findable one at a time. Metadata is what makes a whole category of documents producible as a complete, defensible set, which is what an auditor or examiner is really asking for.
Information architecture doesn’t determine what NDPA or a sector regulator requires. It determines whether a business can demonstrate compliance when asked, rather than reconstructing the answer by hand under a deadline.
GAID Nigeria Data Protection Directive: What Businesses Must Know has the underlying obligations this article’s structure and metadata work ultimately serves.
The Limits of AI-Assisted Search
Keyword-only search needed a person to know roughly what a file was called, which folder it sat in, or which keyword it contained. AI search makes badly named documents easier to find.
Copilot in SharePoint can help locate a file from its content or context rather than requiring the user to know the exact filename, a genuine improvement over keyword-only search. Copilot in SharePoint Explained has more on how it works.
That’s a real improvement when someone needs to find a single document. It doesn’t remove the need to classify and govern documents consistently.
Finding the latest contract with a specific vendor is a search problem, and AI search handles it well. Identifying every contract expiring this year, applying a retention rule consistently, or producing a compliance report is different.
A compliance team, a retention rule, and an access control all depend on documents being tagged correctly beforehand, and better search doesn’t make that tagging optional.
Where Naming and Metadata Break Down
Three problems appear repeatedly: naming conventions drift, metadata gets filled in without thought, and free-text fields fragment what should be controlled categories.
Convention Drift at Scale
A naming system that five people apply consistently rarely survives the jump to thirty, because new joiners never receive the original explanation and nobody owns re-explaining it. One person starts typing “Invoice March” instead of the agreed format; another drops the version number because nobody ever told them why it mattered.
Within a year, the documented convention may still exist somewhere, but it’s no longer what people type.
Metadata Abandoned Without Explanation
Staff are frequently told what to fill in and rarely told why the field exists. A finance team required to tag “Document Type” without ever being shown that it powers the compliance filter they’ll need during an audit has no reason to fill it in carefully.
A required field with no visible payoff gets filled in with whatever clears the save button fastest: the first option in a dropdown, a single character, a value copy-pasted from the last document. Metadata that exists only to satisfy a mandatory checkbox is functionally the same as no metadata at all.
Free Text Mistaken for a Taxonomy
A department field left open to typed entry produces “HR,” “Human Resources,” “Human Resource,” and “HR Dept” within the same library. A free-text box asks people to remember an exact spelling rather than choose from a fixed list, and different people will inevitably make different choices.
The field is technically populated. A filter built to pull every “HR” document will miss the ones tagged “Human Resources” or “HR Dept,” even though they’re the same thing to everyone except the search tool.
A Findability Test
Pick three documents someone outside the department would reasonably need. Give the task to someone who didn’t create the files or set up the structure, and ask them to find each one without asking a colleague.
Then check four things: Can they find it without help? Can they tell which version is current? Can they filter by document type instead of browsing folder by folder? Can they distinguish the authoritative document from an old duplicate sitting nearby?
Each failure points somewhere specific. Can’t find it at all usually signals a structure or naming problem. Can’t tell which version is current suggests naming or version-control issues. Not being able to filter by type is a metadata gap.
Not being able to distinguish the authoritative copy from a duplicate may indicate a governance problem rather than an information architecture one. It’s worth checking whether ownership, version control, and document lifecycle rules have been defined in Document Management Governance in Nigeria.
If someone who didn’t build the structure can’t complete the task without help, the same problem is likely to affect new staff, auditors, and anyone else unfamiliar with the library.
When an Existing Structure Needs Redesigning
A structure doesn’t have to be broken from day one to need redesigning later. A naming convention that worked at ten people can stop working at fifty without anyone formally changing it. It simply becomes harder to apply consistently as the business grows.
Signs the Structure Has Failed
A few signals are worth watching for at the organisational level, distinct from the individual findability test above: the same document routinely gets uploaded twice because nobody’s confident it already exists, and a parallel system- a shared drive, a personal folder, a WhatsApp group- has quietly become where people go first.
“Does anyone know where this is?” becoming a routine question in a team channel, rather than an occasional one, is usually the clearest sign the structure has already been lost.
Rebuild or Repair in Place
Once those signals show up, the real decision is whether to rebuild wholesale or repair going forward. A full rebuild makes sense when the document collection is still small enough to move deliberately, or when a business is already mid-migration to a new platform and can redesign structure as part of that work.
Repairing in place, applying a new convention to everything created from that point on while leaving the existing documents where they sit, tends to make more sense for a large, actively used library, where a full migration would disrupt more people than the current structure’s problems do.
Where to Go Deeper
For how all five pillars fit together, see Document Management Governance in Nigeria. For SharePoint implementation and licensing, SharePoint Document Management in Nigeria has the practical detail.
For who should see what once the structure exists, SharePoint Access Control has the detail on permission models and review cycles.
If your organisation has SharePoint but nobody can confidently answer where a given document type lives or what it’s called, our Document Management Systems team can help review the structure and identify where it’s breaking down. Contact us to talk through your current setup.
