Data management is never easy & things become a little more complex when the data is huge in volume & resides within a Salesforce system. Data management in Salesforce deals with Import/Export of data or records to/from a Salesforce organization. This helps the organization focus on innovation rather than managing technology. Salesforce is one of the best Customer Relationship Management (CRM). It benefits both small and large businesses.

IMPORT DATA

Data can be easily imported into Salesforce through various tools provided by Salesforce. Supported data sources include any program that can save data in the comma delimited text format (.csv).

There are 3 operations possible while Importing Data in Salesforce:

Insert: It simply creates new records in Salesforce.
Update: modifies existing records in Salesforce with the help of record id or external id.
Upsert: It is a combination of insert and update. It modifies the existing records and if the record is not present in the org, it creates a new record for it.

Salesforce offers two main methods for importing data.

Data Import Wizard
Data Loader

DATA IMPORT WIZARD

This tool, accessible through the Setup menu which lets us import data in common standard objects, such as contacts, leads, accounts, opportunities, as well as data in custom objects.
It can import up to 50,000 records at a time.
It provides a simple interface to specify the configuration parameters, data sources, and field mappings that map the field names in your import file with the field names in Salesforce.

DATA LOADER

This is a client application that can import up to five million records at a time, of any data type, either from files or a database connection.
It can be operated either through the user interface or the command line.
In the latter case, you need to specify data sources, field mappings, and other parameters via configuration files.
This makes it possible to automate the import process, using API calls.
Note: Data Import Wizard only imports Accounts, Contacts, Solutions, leads, and all the custom objects whereas Data loader imports all standard as well as custom objects.
With both methods, the number of records you can import depends on your permissions, the type of data you’re importing, and the overall data storage limits for your organization.

SALESFORCE ARCHITECTURE:

EXPORT DATA

Data can be easily exported from Salesforce either manually or on an automatic schedule. The data is exported as a set of comma-separated values (CSV) files. Salesforce Data Export provides a convenient way to export the data, either for backup or for importing into a different system. Salesforce offers two main methods for exporting data.

DATA EXPORT WIZARD

It is an in-browser wizard, accessible through the Setup menu. It allows us to export data manually once every seven days (for weekly export) or 29 days (for monthly export). We can also export data automatically, at weekly or monthly intervals using “Schedule Export”.

DATA LOADER

It is a client application that needs to be installed separately. It can be operated either through the user interface or the command line. The latter option is useful if you want to automate the export process or use APIs to integrate with another system. Salesforce creates a zip archive of CSV files and emails you when it is ready. To download the zip file follow the link on an email or click on Data Export. Exports will complete as soon as possible, however, Salesforce does not guarantee the date and time the export will get complete. Large exports are broken up into multiple files. Zip files are deleted 48 hours after the email is sent.

DATA SECURITY

CREATE A ROLE HEIRARCHY

Role hierarchy is a mechanism to control the data access to the records on a salesforce object based on the job role of a user. For example, a manager needs to have access to all the data pertaining to the employees who report to him, but the employees have no access to the data that is only owned by their manager. In this manner, the access model looks similar to the org chart in an organization but it need not be exactly same as the Org chart.

Salesforce Role Hierarchies can be used to extend the record access automatically so that:

Manager: A Manager will always have access to the same data as his/her employees regardless of the organization-wide default settings.
Users: Users who tend to need access to the same types of records can be grouped. These groups can be used as Roles & Sub-Ordinates in Sharing Rules.
Role hierarchies don’t have to match your organization chart exactly. Instead, each role in the hierarchy should just represent a level of data access that a user or group of users needs. Depending on the organization’s sharing settings, roles can control the level of visibility that users have into the organization’s data. Users at any given role level can view, edit, and report on all data owned by or shared with users below them in the role hierarchy, unless the organization’s sharing model for an object specifies otherwise.
Note:
If the “Grant Access Using Hierarchies” option is disabled for a custom object then only record owners and users granted access by the organization-wide defaults have access to the object’s records. However users such as with the “View All” and “Modify All” object permissions and the “View All Data” and “Modify All Data” system permissions can still access records they do not own.
“Grant Access Using Hierarchies” option is enabled for all objects and it can only be changed for custom objects.
Public Groups: A public group consists of a set of users. It can contain individual users, other groups, or the users in a particular role or territory plus all the users below that role and subordinates in the hierarchy The role hierarchy automatically grants record access to users above the record owner in the hierarchy. This option is enabled for all objects by default. To change this, we take help of custom objects and manual aces grants.

DEFINE SHARING RULES

Though we can manage the access to different objects and records through organization-wide settings and role hierarchies, we come across situations wherein, exceptions are required. We need to grant access to specific data to specific users who are not able to access the required data because of their roles. For example, to see the case history when a user has only access to the current case details. In such scenarios, we take help of sharing rules. Through this mechanism, we create a public group which will accommodate all the users who need such exception and then add sharing rules to such a group.

There are 2 types of Sharing Rules in Salesforce based on which records to be shared:

Owner Based:

Owner based shares the records owned by certain users. Owners can be identified through public groups, roles and roles, and sub-ordinates.

Criteria Based:

Criteria based shares the records that meet certain criteria.

Before creating them, administrators need to answer these 3 questions:

Share which records?
This identifies the records that need to be shared. They can be categorized based on the owner of the records or the criteria that records met.
With whom the records need to be shared?
Records can be shared with public groups, roles, and roles & subordinates.
What kind of access should be provided for these records?
The users with whom the records are shared should have Read-Only or Read/Write access is decided by this question.
Note:
As they cannot restrict access this is the reason it gives Read-Only and Read/Write as access parameters in sharing rules.
They work best when they are defined for a particular group of users that can be determined or predicted in advance rather than a set of users that frequently changes.