The Permissions applied to objects (record types) are a product of the Mandatory Permissions applied to the object combined with the Sharing Policies for that object. You can access these settings by clicking Start > Configuration> Permissions.
The Mandatory Permissions for an object are the base-level permissions which are always in place regardless of any changes that a User tries to make. Users are not able to change the Mandatory Permissions; they must always apply. The Mandatory Permissions can be changed by a System Administrator but this is not generally recommended unless there is a strong business reason for changing them.
By default your Workbooks account is configured so that the majority of objects have a mandatory Ruleset called Minimum Access.
Each object type has one set of Mandatory Permissions.
NOTE: A Ruleset is a set of permissions grouped together.
Within the Mandatory Rulesets you can control whether Sharing Policies are applied when the record is created or when ownership of the record changes. To do this, open the Mandatory Rulesets Landing Page and choose the type of record from the list on the right. You're presented with a dropdown picklist that allows you to specify when Sharing Polices are applied.
NOTE: A record is owned by the user to whom the record is assigned. If you assign the record to a Queue, the permissions can also be recalculated depending on the Queue configuration. You will need to configure your Permissions so that this situation is taken into account. See here for configuring Queues.
Sharing Policies combine with Mandatory Permissions to determine the overall permissions of an object when it's first created. By default Workbooks is supplied with one Sharing Policy for each object type, but a System Administrator can create more if required.
Sharing Policies can be configured so that they are applied either when the record is created or when the ownership of the record changes (ie, when the record is reassigned from one user to another). REMEMBER: Assigning a record to a queue does not change the ownership of the record.
Unless you change the Sharing Policies (which you can only do if you have the Advanced Security extension licence), the majority of objects are configured with a Public Read Write Ruleset. The screenshot below shows you what this means. (Click to enlarge.) As you can see, if a user owns the record they can read, modify, delete, change owner and change permission on that record. If they don't own the record they can still read and modify the details.
Remember, the Sharing Policy works in conjunction with the Mandatory Permissions so if you haven't changed the out-of-the-box settings for Mandatory Permissions or Sharing Policies, the permissions for the majority of records will look like this:
Whilst the majority of records are supplied with a Public Read Write Ruleset, some are supplied with a Private Ruleset. When this is combined with the standard Mandatory Permissions it means that users can read, modify, delete, change owner and change permissions on records they own but they cannot even read records that they don't own. Users in the System Administrator group will have read, modify, delete, change owner and change permissions regardless of who owns the record. If a record has a Private Ruleset, a user can use the padlock on an individual record to share the record with other users. Records that are shipped with a Private Ruleset are: API Data, Accounting Objects, Bulk Actions, Dashboards, Email Credentials, Form Layouts, Import Jobs, Processes, Record Templates, Scripts, Templates and Views.
The permissions an object is given when it's first created depend on which User is creating the object and which Sharing Policy applies for that User.
It is possible to create Sharing Policies for specific users and groups. However it is important to understand that when a new object is created the permissions it is given are based on ALL the policies that the user is matched against.
- Changing the Sharing Policies only affect records created after the changes have been made. The permissions of all existing records are not changed.
- Changing the Mandatory Permissions will affect all records in the system. However it is possible that changing the Mandatory Permission on an object will not change the Access Permissions of a specific record, if the existing permissions take precedence.
Example One: Default Behaviour of Dashboards
This means that the owner of the Dashboard has full access and so do any Users in the System Administration group. This is because the Mandatory Permissions for a Dashboard object are combined with the Sharing Policies for the User. In this case the Mandatory Permissions for Dashboard objects have a Minimum Access Ruleset and the Sharing Policy for the Everyone group has a Private Ruleset. The combination of the Mandatory Permissions and the Sharing Policy result in the permissions for new Dashboards to be those shown above.
Example Two: Preventing System Administrators from accessing all Dashboards
As seen in Example One, by default all users in the System Administrator group have access to all Dashboards created. This is because the Mandatory Permission for Dashboards is Minimum Access which grants access to anyone in the System Administrator group.
To remove System Administrators from all Dashboards by default we need to do the following:
- Create a new Mandatory Permissions Ruleset called Owner Full Access;
- Set the permissions in the new Ruleset to Read, Modify, Delete, Change Owner, Change Permissions for Everyone on all items they own;
- Set the Mandatory Permissions for Dashboards to our new Ruleset called Owner Full Access.
By applying these new Mandatory Permissions to Dashboards, the previous Mandatory Permissions are removed from all existing Dashboards. In this example, if a User had specifically shared their Dashboard with a System Administrator it would still be shared. If the Sharing Policy or the specific permissions of an object grant more access than the Mandatory Permissions, these take precedence.
Example Three: Limiting Opportunities to specific groups
Let’s assume you have two sales teams (UK and France) and you want each team to have access only to their own specific Opportunities, however you want your Sales Managers to have access to all Opportunities.
You will need to do the following:
- Create a User Group called UK Team and add the UK users to that group;
- Create a User Group called France Team and add the French users to the group;
- Ensure all your Sales Managers are in the existing Sales Manager User Group;
- Remove the existing Sharing Policy which states all new Opportunities are Public Read Write for everyone;
- Create a new Ruleset under Sharing Policies called France & Managers with the following permissions:
- Create a new Ruleset under Sharing Policies called UK & Managers with the following permissions:
- Create a new Sharing Policy for Opportunities created by the UK team using the permissions Ruleset UK & Managers.
- Create a new Sharing Policy for Opportunities created by the French team using the permissions Ruleset France & Managers.
This creates the following scenario:
- All new Opportunities created by the UK team will be shared by all members of the UK team plus users in the Sales Manager group – this is controlled by the Sharing Policy;
- All new Opportunities created by the French Team will be shared by all members of the French team plus users in the Sales Manager group – this is controlled by the Sharing Policy;
- All Opportunities created by other people will only have the Mandatory Permissions set of Minimum Access which gives the access to the owner and System Administrators only.
Access Permissions: The permissions on a specific object at a point in time.
Mandatory Permissions: A minimum set of permissions that an object will have at all times.
Ruleset: A set of permissions that are grouped together.