Within the intranet Document Management System, you may have:
- Parent folders – these are the folders that sit at the root level of your DMS tree.
- Sub folders – these are the folders that sit underneath your parent folders (and you may have subfolders within subfolders within subfolders and so on).
- Documents – these are the actual files that sit within your folders (either parent folders or subfolders).
By default, permissions are inherited from the parent object. For example:
You have a parent folder called “Marketing”. This folder sits at the root level of your DMS tree, which means there is no parent object and therefore you define permissions on this folder manually. You create a subfolder within the “Marketing” folder called “Product Collateral”. Then you upload a document within the “Product Collateral” folder called “DMS Features”.
The “Product Collateral” folder will inherit permissions from the “Marketing” folder and the “DMS Features” document will inherit permissions from the “Product Collateral” folder. This means that the same people that have access to the “Marketing” folder, will have access down to the “DMS Features” document.
As much as possible, it’s good to leave permissions inheritance enabled. Of course you can disable this for a particular folder or document, if it should have more restrictive access than others. But you should try not make a habit of doing this. If you start defining individual permissions on every folder and document, you will find yourself in a mess before too long!
(If you’re already in a mess, don’t worry, we have an awesome Support Team who can help you out!)
If you decide that a new Group or Role should have access to a particular parent folder and its contents, you would start by updating the permissions on that folder. If the contents of the folder (i.e. subfolders and documents) are inheriting permissions from the parent folder, you wouldn’t need to do anything else. However, say 20 of the documents within the folder had individual permissions, you would then need to update the permissions on all 20 documents.
Of course sometimes it is necessary to disable permissions inheritance – that’s why the option is available after all.
There are 3 little tips that I would love to share with you…
A little tip I’d like to share is this: the little yellow key icon you see in the Documents Control Panel is your friend!
If you have ever looked at the Documents List in the Documents Control Panel, you have probably seen the little yellow key icon that sits to the left of some folders and documents. This icon represents that the permissions on that object are not inherited from the parent object.
This is extremely useful if you need to have a look at everything that has individual permissions. Rather than looking at the permissions of all objects, you know you only need to look at the permissions of objects displaying the key icon. All the rest are inheriting permissions from the parent object. Simply click on the key icon to be taken directly to the permissions page.
Did you know that you can quickly identify who has access to a particular folder or document and the level of access they have? From the permissions page, click View effective permissions.
Are you having trouble finding a Group, Role or User when defining permissions on a folder or a document? You’re typing their name but it just isn’t showing up? Read on…
You can only grant Groups, Roles and Users, permissions to a folder or document if they have at least View rights on the parent object. For example:
You have a parent folder called “Human Resources”. This folder sits at the root level of your DMS tree, which means there is no parent object and therefore you define permissions on this folder manually. Only the “HR” Group have access to this folder and its contents.
A while later you add a document called “Employee Handbook” to the “Human Resources” folder. You want everybody in the company to be able to access this document. So in theory you need to uninherit permissions from the “HR” folder because keeping the permissions inherited would mean that only the “HR” Group have access to it. But when you go to change the permissions on the document, you can’t find the “Staff” Role which holds all company users. You are typing “Staff” but it’s not coming up with any results.
This is due to that fact that the “Staff” Role does not have access to the parent object, i.e. the “Human Resources” folder. If you think about it logically, if you granted the “Staff” Role permissions to view the “Employee Handbook” document, how would they actually get to it if they don’t have access to the folder it sits in?
The only way to give the “Staff” Role access to the “Employee Handbook” document would be to grant them permissions on the folder above, i.e. the “Human Resources” folder. But this would mean they have access to everything else within the “Human Resources” folder because the rest of the contents has permissions inheritance enabled. So you would then need to uninherit permissions on every other object, in order to restrict the “Staff” Role from seeing everything.
Hopefully this clarifies the reason you might not be able to find a Group, Role or User when defining permissions on a folder or a document. But of course, the scenario above is not ideal. The better option would be to move the “Employee Handbook” folder out of the “Human Resources” folder altogether and put it somewhere that the “Staff” Role does have access to!