Contributed by: Connie Anderson, Senior Technical Writer, Laserfiche 

When setting up security, each Laserfiche repository will be different and have different requirements to consider. Without careful planning and regular updates as your site grows and changes, your system may become chaotic and unsecured. To keep this from happening, have the following recommendations in mind when setting up Laserfiche security. 

Entry access rights determine the operations that a user can perform on folders or documents. For example, users may be able to read invoices, but not edit or delete them. 

It is a best practice to assign entry access rights to groups rather than individual users. This way, you can simply add users to groups and they will automatically be assigned the correct rights.

This way, if a new person is hired, simply add them to the appropriate group and they will automatically inherit the correct security.

For example, members of the accounting department need to create, read and modify financial statements, but most other departments don’t even need to know where the financial statements are stored.

In general, it is a best practice to simply not allow a right if a user should not be able to do something, rather than explicitly denying it. Explicit denies should be used primarily for exception cases.

Privileges are special account rights that grant the ability to perform operations dealing with the management of a Laserfiche repository. Privileges can be divided among different types of administrators. 

For example, a high-level administrator can be granted Manage Entry Access and Manage Metadata privileges while a department manager will have Manage Templates and Fields and Manage Stamps.

Some privileges have repercussions across the entire repository. For example, a user with the Manage Tags privilege can grant security tags, and a user with the Manage Entry Access privilege can browse the entire repository. The number one rule about privileges is: know what a privilege does before you grant it.

Since all users will always be part of the “Everyone” group, you should give it only very limited security access.

By default, all members of the “Everyone” group are assigned two privileges that confer significant system performance benefits. These privileges allow them to bypass certain security settings:

If you will be using the Folder Filter Expressions advanced security feature, or restricting the Browse right for certain folders, you will need to remove the relevant privilege from the “Everyone” group. Otherwise, it is recommended that you leave these privileges in place.

Since it is a best practice to grant entry access rights to particular folders, not individual documents, if you want to control access to documents regardless of where they are located in the folder tree, you can use security tags. A security tag ensures that only users who have been granted that tag will be able to see documents that have that tag applied to them, regardless of where the document is in the repository. 

Use security tags for documents that:

Security tags will not be inherited by documents in a folder if they are applied to a folder. In general, security tags should be applied only to documents, not to folders.

Feature rights provide administrators with the ability to enable or disable certain functions for users across the entire repository. For example, the Scan feature right controls a user’s ability to scan documents. If they do not have the Scan feature right on a folder, they will not be able to scan new documents into that folder, even if they have sufficient entry access rights to create documents at that location. Feature rights are best used when you want to simplify a user’s experience by disabling functions across the whole repository. 

Laserfiche gives you the ability to configure access to specific parts of your repository, such as the fields, and templates. In general, these access rights have reasonable default values; if you don’t have a reason to need to restrict access to specific fields or templates, you do not need to configure field and template security and can use the default values. However, they are useful for exception cases. For example, you may want to use security to hide sensitive field values, such as social security numbers.