How to set up department-based file access?

Why can file permissions not be managed on a per-person basis?

In a small team, granting permissions person by person to each folder causes no issues. However, once the number of employees exceeds thirty and folders exceed one hundred, permissions no longer fit into a table. Someone who changes teams continues to see files from their old department; a newcomer may not see a folder they need because it was forgotten.

The root cause of the issue is that permissions are tied to individuals. People change departments, leave the company, or delegate. However, the department's need for files remains unchanged for years. By tying permissions to the department, personnel changes only affect department membership; you don't need to touch file permissions.

How is the principle of least privilege applied to file access?

The principle of least privilege means having just enough access to do your job, not more. For files, this goes beyond 'those who can't see them can't delete them': reading a document, modifying it, and deleting it are separate decisions.

For example, the sales team needs to read contract templates but not modify them. Accounting uploads invoices but should not delete them after year-end closing. Granting permissions with these distinctions reduces the risk of accidental deletion or unwanted changes from the outset.

How is department-based access planned step-by-step?

1. "Expand the department list. Write down every team in your organization schema and the document types each team is responsible for.
2. "Create one main area for each department. Consider a separate general area that everyone can read for shared documents (templates, policies).
3. "Prepare the authorisation matrix on paper. Place departments in rows and permissions such as read, write, edit, and delete in columns. Discuss each cell individually.
4. "Grant permission to the department, grant exceptions to individuals. Person-based permissions should only be used for temporary situations (proxy, project support) and removed when the period ends.
5. "Keep deletion permissions narrow. Grant deletion permission in each area only to the area owner and one backup.
6. "Review every three months. Re-read the matrix; remove unused person-based exceptions.

Which permissions should be kept separate?

A good permission model includes at least the following distinctions:

• "Reading and writing: viewing a document and uploading a new document are separate decisions.
• "Editing and deleting: the ability to rename or move a file does not require the ability to delete it.
• "History: viewing old versions and activity logs in the area is a privilege required more by supervisors than by regular users.
• "Artificial intelligence: independently toggling AI-based document reading and question-answering features is important in areas containing sensitive documents.

How are access changes audited?

The way to verify that the permission model works is through records. It must be recorded who uploaded, moved, or deleted which file and when a permission changed. These records are not used to find someone to blame when an issue arises, but to identify what went wrong in the model.

What does an example permission matrix look like?

In a mid-sized company, the following distribution is common for the Finance area. The table is not a recommendation but an example to start a discussion; each organisation adapts it according to its own workflow.

• "Accounting department: read, write, edit, folder and note. Delete permission only for the accounting manager.
• "General management: read, history, and notes. Does not upload documents, but sees versions and operations in the area.
• "Sales department: Read-only access on a per-person basis, applicable only to situations concerning the "Customer Invoices" folder.
• "Other departments: no permissions; not visible in the sidebar.

What are common mistakes in department-based access?

The most common mistake is assuming “everyone can read it, no problem.” Read permission seems harmless, but the real risk lies precisely in reading documents such as salary tables, performance evaluations, or customer contracts. Instead of enabling read permission by default, ask separately for each area: “Who should see this?”

The second error is the permanentisation of temporary permissions. A person-based permission granted to an employee supporting a project is forgotten when the project ends. Years later, the matrix fills with exceptions whose reasons no one remembers. Notting down the reason for each person-based permission and when it should be reviewed prevents this accumulation.

The third error is performing daily tasks with an administrator account. A user with access to all areas who accidentally deletes or moves a file causes wider impact than an ordinary user. Administrators should also work with their department's permissions during daily tasks.

What should happen when the working team changes?

The main benefit of the department-based model becomes apparent here. When an employee is removed from their old department and added to a new one in the DBLinx tenant panel, access to the old department’s areas closes, while access to the new department’s areas opens. There is no need to fix folder permissions individually; only exceptions granted specifically to the person need to be removed.

Checklist for department-based access

After installing the model, tick the following items one by one. If you cannot tick an item, it means there is a gap that needs to be closed in the model.

• Each department has its own area; shared documents reside in a separate area readable by everyone.
• Most permissions are department-based; those assigned to individuals are only exceptions.
• The reason and review date for each person-specific exception are recorded.
• Deletion permission is available to at most two people per area.
• AI permissions in areas containing confidential documents are consciously enabled or disabled.
• There is a responsible person who regularly reviews the activity history of the area.
• Accounts of employees who have left are closed on the same day.

How does SmartFiles solve this?

In SmartFiles, each storage area has eight independent permissions: Read, Write, Edit, Delete, Folder, AI, History, and Note. When the organization administrator selects an area, all people and departments appear in the permission matrix; checking a box grants that permission immediately.

Permissions granted to a department are automatically applied to everyone in that department. An employee sees areas with read-only access; other areas are not listed in the sidebar. A person with historical permissions can see uploads, moves, deletions, and permission changes in the area's activity history, along with the person and time.

Who users are, which department they work in, and whether they can access SmartFiles are managed from the DBLinx tenant panel; employees log in to SmartFiles using the same DBLinx identity. Thus, department changes are made in one place, and SmartFiles area permissions automatically follow this change. Each user can view their own active sessions and close sessions on unfamiliar devices.

• The eight permissions are independent: upload can be open while delete remains closed.
• Permission for a person or department; buttons for All and None for all permissions in the row.
• Area permissions for a person removed from the tenant are automatically cleared.

Area-based authorisationGranting person permission to storage areaReview activity in storage areas

Frequently asked questions

What is the difference between department-based file access and folder permissions?

Folder permission is granted to a single folder and usually to a single person. In department-based access, permission is granted to the entire area of a department; there is no need to adjust permissions separately for people joining or leaving the department.

What happens if an employee works in two departments?

Employees work in the areas of two departments with the permissions granted to their own department. If necessary, additional person-specific permissions can be granted in a single area.

Can a person without permission see the existence of the area?

No. In SmartFiles, a person without read permission does not see that area in the sidebar; files in that area are also not shown to them in search, note streams or file links.

When does a permission change take effect?

Changes take effect immediately upon saving. Open panels also update automatically shortly after.