- Object and record permissions (object level security AND record-level security -sharing-)
- Field permissions (field level security)
- Application permissions
Permissions are User based.
They can be assigned to each
user based on:
- The User Profile (each user has
one profile, accessible from 'Setup' -> 'Users')
- A few parameters on the User
record ('Setup' -> 'Users')
- Permission Set (a user can be
assigned to one or many permission sets). Permission extension only.
Permission sets extend users' access and permissions without changing their profile.
- Permission Groups (a user can be
assigned to one or many permission groups)
A Permission Set Group is a bundle of Permission Sets based on user job functions, for example.
Role (each User belongs to one
Role; Roles are gathered in a hierarchy)
Permission Group is a gathering
of Permission Sets.
Object and Record Permission Assignment
Each record (an instance of an
object; ie. an account or a contact) is owned by an Owner (the user that has
created the record).
The owner of a record can be
changed by the owner of whoever sits above him in the Role hierarchy :
Record Access Permissions / Organisation Wide Permissions
Object Access Permissions are
based on an Organisation Wide Default for each object.
Organisation Wide Default is set under Setup -> Sharing Settings.
DO NOT MODIFY THEM WITHOUT PRIOR VALIDATION WITH YOUR CUSTOMER SUCCESS MANAGER
Each object can be:
- Public Write (all users can
modify all records),
- Public Read (all users can read
- Private (the record is only
accessible to the owner)
When the Object is set Private,
the access to a record of the object is limited to the owner and it is then
- to any User who belongs to a Role
above the Role of the Record's Owner (please refer to Role Hierarchy)
- by Sharing Rules. Sharing Rules
will define other Users who may have access to the record based on condition
Object Wide Permissions
Object Wide Permissions are defined at
Object level; in the User Profile, or Permission Set (extension).
Object Wide Permissions are applied to
all records of the object based on the user. They define what a user can DO in the system.
Permissions can be:
- Create (User may create a new
record of the object)
- Read (User may have access to records of the object)
- Edit (User may modify records
of the object which they have access to)
- Delete (User may delete records
of the object which they have access to)
WE RECOMMEND TO NEVER ACTIVATE
THE DELETE PERMISSION FOR ANY OBJECT.
Field Permissions define the access level for each field in an object.
The Field Permissions are shared by all records. They cannot be set at record level.
can be restricted to :
- Read and Edit (visible)
- Read (visible and read only)
- Non (non visible)
Field Permissions can be defined field-level security in either of three ways :
- Multiple fields on a singe permission set or profile
- Single field on all profiles (from Object setup)
- All users from the Record Layout
Multiple Fields on a Single Permission Set or Profile
- For multiple fields on a single permission set or profile
Go to Setup -> Profile -> (select profile) -> Object Settings -> (select object)
Single Field on all Profiles (from Object setup)
- For a single field on all profiles
Go to Setup -> Object -> (select Object) -> Fields & Relationships -> (select field) -> Set Field Level Security
From the Record Page Layout
Setup -> Object -> (select object) -> Page Layouts -> (select layout) -> (select field)
are defined under Setup -> Sharing Settings -> (bottom on the screen).
They are applied to all records and used for extending record access based on rules to other users beyond the record owner.
They grant access permissions (Read, Edit) to records of objects that are not Public Read/Write.
Do not modify sharing rules without notifying your Thynk Customer Success Manager.
Role versus Profile
Profiles are used in order to assign the same type of permissions to similar users (admin, managers, ...).
These permissions can then be extended with Permission Sets and Permission Set Groups.
These permissions are DO permissions (Create, Edit, Read, Delete any / all records of a specific object).
Roles define how users relate to each other from a Data Access point of view (it may not match with the actual hierarchy).
A user that has been assigned a specific Role will inherit access to all records owned by users with Roles below his role in the Role Hierarchy.
The permissions are SEE / ACCESS permissions.
Two users belonging to the same Role do not share records.
This is why it is required to create Roles for the Head of each team.
Data Access (record access) provided by Role Hierarchy can then be extended with Sharing Rules.
Roles are accessible from Setup / Role .
How to Create a New User Login
As THYNK Admin, you can manage user logins and grant new users access to your properties. You will also deactivate users as they leave. To Create New Users Before creating the new user, you must follow the steps for Multi-Factor Authentication. With ...
Manage Permission Sets
What are Permission Sets? Permission Sets are useful to understand the structure of our solution. They define functional access for users to different features such as emailing, and the creation of contacts, accounts... Only Admins can manage and ...
Edit User Information
You can change your contact information, profile or even role by editing your user account. Click on your profile photo to 'View Profile' Click on 'Settings' under your name The menu opens on the left side. Here you can edit edit your user ...
User Locale Settings / Language & Time Zone
Objectives Understand what Locale Settings are Update your personal Locale settings What Are Locale Settings? The Salesforce locale settings determine the display formats for date and time, user names, addresses, and commas and periods in numbers. ...
How to Build a Dashboard
Objectives Get familiar with dashboard feature and terminology Create a dashboard with the Dashboard Builder What is a Dashboard? Reports make it easy to access and visualise data to make it insightful and actionable. Dashboard take it one step ...