Object level access
Object level access using profiles
Until and unless you have access on an object, you can’t access its field. An admin can give access to a particular object through the profile. On the profile, admin can set what kind of access he wants to give to the users of the profile. User can have read, create, edit, delete, view all and modify all access on an object. Admin can select one or all of these permissions.
You can configure it from -> Setup | profile | Desired profile | Standard object permissions and custom object permission
Consider your profile has only read access on the account object so you can only access account records without editing or deleting them. If you manage to get edit permission, then you can edit it also but still deleting an account would be a dream.
Object level access using permission sets
On this gate, there is a supporting entity ( a watchman) which can help you add more features. Let’s take a scenario where two users of same profile want a change in their profile. One of them wants only read access and the other wants read/write access both on the account. In this case, instead of a creating separate profile for both of them, we can use Permission sets. Permission sets behave like an enhancement to a profile which can carry the same features of a profile but in limited count. You can assign some extra permissions in permission sets which you haven’t done in the profile and further assign that permission set to a user. These sets can be used as an extension to the profiles by providing more features. In the previously mentioned scenario, admins can create a profile with read access and allocate it to users. Further, admin can create a permission set with extra edit permission which was not there on the profile and assign them to user who was in need of edit access. This way permission sets can be useful and admins can serve the purpose of both the users with a single profile.
If you have got an idea on object access, let’s move to the next gate.