Salesforce Security and Validation

Security and Validation

Security:

The Sharing Model is specified by starting at the organization level, Organization-Wide Defaults (Org Wide Defaults), and are selectively restricted/exposed after that.

• Org Wide Defaults: It set whether an entire object is Private, Public Read-Only, or Public Read/Write. The Org Wide Defaults will allow the user to make all Accounts private.

For example, it means that only the person who “owns” record can see it.

• Roles: Roles are used in a defined “Role Hierarchy”. Roles in the role hierarchy should be created as “functional” rather than “real”, meaning that administrative associates should be placed above their bosses in the hierarchy.

This may seem unreasonable, but people can easily see our data “if Grant Access via Role Hierarchy” option is checked.

The assistant can see all of their boss's Accounts (set to Private in Org Wide Defaults). Roles can also be used in Sharing Rules.

• Public Groups: Public Groups is used to group users for Sharing Rules. 
• Sharing Rules: An object is marked as anything other than Public Read/Write in the Org Wide Defaults; it shares rules which can be used to expose records that meet particular criteria. Sharing Rules ensures user to request support, the support person can see precisely record trouble with, but other members of the Sales Team cannot see our Accounts.

For example, we can do something towards the lines of "All Accounts owned by the Public Group' Sales Team should be shared with the users in the “Role Support Staff."

• Profiles: Profiles store a big amount of user’s data assigned to Profile within the instance.It includes password policies, hours (user`s login), locations (from user`s login), the objects, and fields (user’s access).

Profiles also control custom-coded customizations that are available to the users assigned to them.

• Permission Sets: The permission sets can be reflected “mini-profiles”, which are assigned to the defined users. They have most of the same configuration options as profiles, and they are used to grant additional access to the Profile given.

• Field-Level Security: It can be set when a field is first being created, stored on profiles, and edited after creation. A field has the option of being read or editable.

Validation:

It is also essential to have data validation, sometimes even to assure that the users are not bypassing security.

There are three different types of validation in addition to custom develop Apex code validation.

• Database: Database-level validation will always confirm that the correct type is being stored.

For example, It will not allow us to store a value of 'twenty' in a field that is defined as a Number type. Database validation also comes into the formation if the “Required” checkbox was checked during field creation or “Unique” settings were set.  If records violating any of the validations that are attempted to be inserted into the database, a fatal exception will be given, and the data will not be saved.

• Layout-Based: Validation is added to the page layout when adding a field to the layout. This kind of validation allows administrators to require fields to be filled out for only certain Record Types while enabling them to be empty for other Record Types. Layout-based validation can also make fields read-only for users who would normally be able to edit that field.

• Validation Rules: The formula-based rules can be created by administrators to validate against business requirements. If these formulas evaluate to true, a validation error is displayed to the user with the defining message.