# Field Permissions - Basic Functionality

<section class="yaqOZd" id="bkmrk-field-level-security">Field-Level Security works very similarly to Object-Level Permissions. When dealing with Profiles and FLS, there are three objects involved:

<div><div><div><div><div><div><div><div><div><div>- **Profile** object
- **PermissionSet** object
- **FieldPermissions** object

</div></div></div></div></div></div></div></div></div></div>***Note:** Every Profile has a corresponding child PermissionSet record, as indicated by the ProfileId field on the PermissionSet record. When dealing with Permission Sets, the Profile object doesn’t factor in.*

For every combination of Profile and Field, there is a corresponding FieldPermissions record. Each record has two boolean fields that control the access level for that Profile to that field. The same goes for Permission Sets. Those two fields are:

<div><div><div><div><div><div><div><div><div><div>- `<strong>PermissionsEdit </strong>`
- `<strong>PermissionsRead </strong>`

</div></div></div></div></div></div></div></div></div></div>***Note:** If a Profile or Permission Set has no access to a Field, then there is no FieldPermissions record for that Field/Profile combination. You cannot have a FieldPermissions record where all “permissions” fields are FALSE.*

In addition to these boolean fields, there are three other uneditable fields which indicate which Object the record is related to (`sObjectType`), which specific Field this record controls access to (`Field`), and the related Permission Set (`ParentId`). Remember, even if the FieldPermissions record is controlling access for a Profile, it will be related to a Permission Set. That Permission Set will have the Id of the corresponding Profile in the `ProfileId` field.

When a Profile or Permission Set is granted access to a Field, Salesforce automatically creates a new FieldPermissions record. When access to that Field is removed, Salesforce deletes that record.

</section>