With examples from Laserfiche and IBM FileNet
In enterprise content management (ECM), one design decision seems simple but has deep consequences:
Should you name or design a repository around a user?
At first glance, it feels natural — but in most cases, it is not a good practice.
1. What Does “User-Based Repository” Mean?
This usually means:
A repository named like: John_Repository, Finance_User_DB Or a structure where content is tied directly to a specific person
Instead of:
Business function (Loans, HR, Security) Or process (Approval, Onboarding, Audit)
2. When It Can Be Acceptable (Rare Cases)
There are limited scenarios where it can work:
✔ Personal Workspaces
Temporary storage Draft documents Individual work areas
Example:
A developer sandbox in Laserfiche A personal test object store in IBM FileNet
👉 Even here, it should not be critical to the business.
3. Why It Is Usually a Bad Practice
❌ 1. Users Change — Systems Should Not
People:
Leave the company Change roles Get replaced
But your system must remain stable.
👉 If your repository depends on a user:
You create tight coupling to a human
❌ 2. Breaks Business Logic
Systems should reflect:
Business processes Organizational structure
NOT individuals.
Bad design:
“Loan approvals stored in Ahmed’s repository”
Good design:
“Loan approvals stored in Loan Management repository”
❌ 3. Security Risks
When tied to users:
Permissions become messy Hard to audit access Risk of over-permission or orphaned data
In Laserfiche:
You lose clean role-based access
In IBM FileNet:
ACLs become inconsistent
❌ 4. Scalability Problems
Imagine:
100 users → 100 repositories
This leads to:
Duplication Hard maintenance Complex integrations
4. When It Fails (Real Scenarios)
🚨 Scenario 1: User Leaves the Company
Repository owner is gone No one knows the structure Permissions break
🚨 Scenario 2: Process Expansion
You start with:
One user managing loans
Then:
Team grows → multiple users
Now:
Repository design blocks collaboration
🚨 Scenario 3: Automation / Workflow Failure
Workflows depend on:
Stable paths Consistent structure
If tied to users:
Paths change Workflows fail
Example in Laserfiche:
Workflow cannot find folders because user context changed
🚨 Scenario 4: Integration Issues
External systems expect:
Stable endpoints Consistent naming
User-based repositories:
Break APIs Complicate integrations
5. Best Practice (What You Should Do Instead)
✔ Use Business-Based Design
Structure should follow:
Function → “Finance”, “HR”, “Security” Process → “Loan Approval”, “Access Control”
✔ Use Role-Based Access
Instead of:
User = Owner
Use:
Roles (Manager, Reviewer, Auditor)
✔ Separate Personal and Enterprise Data
Personal → Temporary workspace Enterprise → Shared, structured repository
6. Architect Insight
A strong rule in ECM architecture:
Design for the organization, not for individuals.
Systems must survive:
Staff turnover Organizational changes Growth and scaling
Final Thought
Working with a user-based repository might feel simple at the beginning, but it introduces hidden risks.
It works only in small, temporary, or personal contexts.
In enterprise systems like Laserfiche and IBM FileNet:
👉 The moment your system grows,
👉 The moment users change,
👉 The moment automation starts…
User-based design fails.
Build for processes, roles, and business — not for people.