By default, collection-level permissions are the same as the account and application level permissions. For example, if a user is assigned a role that grants them "User" permission to an application, then they are granted the same "User" permission (to Create, Read, Update and Delete) records within any of the application's collections. You have the option to overwrite these default permissions and assign your own collection-level permissions. Currently, if you assign custom, collection-level permissions, the collection will not inherit any permission settings from the application or the account and any user access will have to be specifically granted in your custom settings.

At the collection level, users with authoring privileges can select the Set Collection Permissions action, click the wrench on the side of the Collections tabs – this will bring up the UI to define the collection level permissions. By default, collections will always inherit the account or application level permissions (if set).

These permissions can then be overridden by setting explicit collection level permissions. The default permission template governs the static permissions that apply to the entire collection (and data). The user can then define custom data-driven permission templates to further control access at the individual record level based on the defined criteria.

If you select the option to set data-driven permission templates, you will have to specify the query for the specific set of records/data to which you want to apply create/read/update/delete privileges for a set of groups.

Advanced Search dialog box will open and you can select the field.

It is important to note that:

• Permissions set at the collection level replace those inherited from the account level in entirety. This means you have to set the collection level permissions for each and every group when you check the option to override with collection level permissions – any group that is not explicitly assigned a permission set at the collection level will automatically be inferred to have no access/privileges on that collection (since none was defined for that group). When you unset the collection level permissions, the access privileges for that collection will revert back to the default account or application level settings.

• Collection and record level permissions are additive. If an user is part of multiple groups, he/she can get access privileges through any one of those groups – e.g. if Group X has no update access to the collection, but Group Y has update access to records in the collection…and the user is a part of both groups, then this user will have update access to those records.

As soon as you create a custom Collection level permission Create, Update, Read and Delete are all affected. So if you set custom Create permissions but leave Update, Read and Delete blank no group will be have permission to Update, Read and Delete for this Collection. You will need to set each one of these permissions if you customize one of them.