No, once we create user in salesforce we cannot delete the user record. We can only deactivate the user record.
If you need help resolving a problem, you can grant login access to your account to a Salesforce administrator or a support representative.
If we enable ‘Grant Account Login Access’ for a user then we can see ‘Log in’ button on the detail page of that user. By clicking on that ‘Log in’ button without giving that user’s username and password we can log in.
To enable the ‘Grant Account Login Access’ follow the below steps –
Using Profiles and Permission Sets.
A profile is a group/collection of settings and permissions that define what a user can do in salesforce.
A profile controls “Object permissions, Field permissions, User permissions, Tab settings, App settings, Apex class access, Visualforce page access, Page layouts, Record Types, Login hours & Login IP ranges.
We can map only one profile for one user and without mapping the profile we cannot create the user.
Permission set is also very similar to profile. Whatever you can manage at profiles (Like Object permissions, Field Permissions, User permissions, Tab settings, App settings, Apex class permission, visualforce permission) the same you can manage here also.
But the main difference between these two is that user can have only one profile and can have multiple permission sets at time.
Example: To give additional permissions to few users who belongs to different profiles over Apps, Tabs, sObjects and fields.
1000 (It will depends upon the number of licenses taken by the client, it will be like upto 4000 like that based on the client)
A role hierarchy controls level of visibility that users have to an organization data.
Organization-Wide Defaults, or OWDs, are the baseline security you for your Salesforce instance. Organizational Wide Defaults are used to restrict access. You grant access through other means we will talk about later (sharing rules, Role Hierarchy, Sales Teams and Account teams, manual sharing, etc).
There are four levels of access that can be set:
Private: only owner and above hierarchy users can have Read/Write access and below hierarchy users don’t have any access.
Public Read only: only owner and above hierarchy users can have Read/Write access and below hierarchy users can have only Read Only.
Public Read/Write: Irrespective of role hierarchy everyone can have Read/Write permissions on the records.
Determine whether users have access to records they don’t own, including records to which they don’t have sharing access, but someone below them in the hierarchy does. Say there are three roles
Role A is higher in hierarchy, Role B is in middle and Role C is lower in hierarchy
If the Role A user through Manual Sharing or Sharing Rules, shares the record to Role C user who is in lower hierarchy, then the Role B user who is above in hierarchy to Role C user can see the records, if we enable Grant Access Using Hierarchies at sharing settings else Role B user cannot see the record.