Access Control
Access Control determines which users can see and open documents in Docwize, and where applicable, whether they can edit them. It operates across three independent layers — explicit document-level security, folder security, and project security — any combination of which may apply to a given document.
This page is a reference for administrators and implementation leads. Access control changes may affect document visibility as soon as they are saved. Review the impact before changing folder, project, group, or explicit document access.
How access control layers work
A document's visibility to a given user depends on which access layers apply to it. The diagram below shows the conditions under which access is granted.
Each pathway grants access independently. A user who has explicit access to a document can see it regardless of which folder or project the document belongs to.
| Layer | What it controls | Where it is configured |
|---|---|---|
| Explicit user and group security | Direct access grants on the document itself | Document Permissions dialog |
| Folder security | Which folders a user or group can see | User or Group settings |
| Project security | Whether a user is assigned to the document's project | Project settings |
Explicit user and group security
Explicit access is granted directly on a document. A user or group with explicit access can see the document. Editing rights, where available, are configured separately within the same dialog.
Explicit access is granted in two ways:
- Automatically — workflows can grant explicit access to a document as part of a workflow action step, typically when the document is sent to a user for review or action.
- Manually — by an administrator using the Document Permissions dialog on the document.
Security rules are applied to a document immediately at the point of creation, rather than via a background process. This means access controls take effect as soon as a document is created.
'Document Permissions' dialog
The dialog lists individual users and groups with access to the document. An edit toggle on each entry controls whether that user or group can edit the document in Office Online.
Group access works through membership: if a user belongs to a group listed in the dialog, they gain the access assigned to that group. Removing a user from a group may remove access that the user inherited through that group, unless they retain access through another group, explicit document access, folder access, or project access.
Explicit access is independent of folder and project security. A user with explicit access to a document can see it regardless of which folder or project it belongs to.
Folder security
Docwize folders are a tree structure for organising documents. A user's access to a folder determines which documents in that folder they can see — subject to any project restriction that also applies (see When folder and project security combine).
Folder access states
| Icon | Name | What it means |
|---|---|---|
 | Public Access | The folder is public. No explicit users or groups have been assigned; users with general system access can see it, unless another access layer also restricts the document. |
 | Explicit User Access | The folder has been assigned directly to this user, independent of any group membership. |
 | Explicit Group Access | The user's access to this folder comes through one or more group assignments. |
 | No Access | The user cannot see this folder. |
Configuring folder access
Folder access is configured per group or per user. The video below demonstrates assigning folder access for a group. Folders shown in red have no access; folders in green have access granted.
Managing group folder access
The video below demonstrates folder access for an individual user.
Managing user folder access
When folder access is sufficient
If a document is in a folder and not assigned to a project, a user with access to that folder can typically see the document.
If the document is in a folder and assigned to a project, folder access alone may not be sufficient — see When folder and project security combine.
Project security
A project is a metadata field that can be assigned to a document. Project security controls which users can see documents within a project.
A user can access documents in a project if either:
- They are assigned to the project, and the project has no folders associated with it, or
- The project is public (visible to all users with general system access)
If a project has associated folders, users may need access to both the project and the relevant folder to see its documents. See When folder and project security combine.
Project security is managed by users with the required permissions.
A project is public when no users or groups have been assigned to it in the Admin Console. Any user with general system access can see documents within a public project, regardless of project assignment. A project becomes private as soon as at least one user or group is assigned to it.
When folder and project security combine
If a document is assigned to both a folder and a project, the user typically needs access to both to see it:
- Access to the folder alone may not be enough.
- Access to the project alone may not be enough.
- Both may need to be granted.
If the folder is public, project access alone is sufficient to see documents in that combination.
This is a common cause of access denial when setting up new projects: a user is assigned to the project but not the folder (or vice versa), and cannot see the documents.
Before changing access settings
Understand what is in scope before restricting access. If you remove a group's access to a folder, users in that group may lose access to documents in that folder — unless they retain access through another group, explicit document access, or project access.
Plan group-based folder access before adding users. Folder access assigned to a group typically applies to all current and future members of that group. Adding a user to a group may grant them access to folders and documents accessible to that group.
Check for workflow interactions before restricting documents. Workflows may automatically grant explicit document access as part of their action steps. Restricting access at the folder or project level may not remove explicit access that a workflow has already granted. Workflow-granted explicit access persists until manually removed — it is not automatically revoked when the workflow closes.
Do not rely on document-level explicit access as a substitute for group and folder planning. Granting access document-by-document is difficult to manage at scale and does not integrate with group-based reporting or auditing.
Confirm the intended state before inviting users. Users who accept invitations before access control is correctly configured may gain insufficient or incorrect access immediately on joining.
Common risks
| Risk | How it typically happens | What to check |
|---|---|---|
| User cannot see a document they should | Document has both a folder and a project; user has access to one but not the other | Check both folder assignment and project assignment for that user |
| User can see documents they should not | Folder or project may be set to public; or user may be in a group with broader access than intended | Review folder and project visibility; review group membership |
| Removing a user from a group causes unexpected loss of access | Group had folder or project access the user relied on | Check all access routes for the user before removing group membership |
| Access granted by a workflow persists after the process ends | Workflows grant explicit document access that is not automatically revoked when the workflow closes | Check the Document Permissions dialog on affected documents and remove any explicit access entries that are no longer required |
Testing access-control changes
Before applying changes in a live environment:
- Identify a test user account with the same group memberships as the affected users.
- Apply the intended access change (folder, project, or explicit access).
- Log in as the test user — or ask a trusted colleague with that account — and verify:
- Can they see the folders they should?
- Can they open the documents in scope?
- Are they seeing any documents they should not?
- Open the Document Permissions dialog on affected documents to confirm there is no unintended explicit access remaining.
Docwize does not have an impersonate user or view-as-user feature. A separate test account is required to verify access changes from a user's perspective.
Related configuration
- Groups — assign folder access to groups; manage group membership
- Users — assign folder access and explicit permissions at the individual user level
- Permissions — permission levels required to manage project security and other admin areas
- Projects — create and manage projects; assign users to projects
- Folders — folder structure and navigation from the user perspective