Once you have your framework set up, you might think that it's time to to start loading data. However, before you can start the loading process, you should first set up checklists to ensure that the data being entered into the system is legitimate data. If you have thought about your edge cases in your initial plan, you should have an idea of what kinds of data you expect to see in your org. Building on this, you must also consider data integrity — what bad data you could potentially encounter in your org but do not want to allow.
In some situations, like in the case of relationships and formula fields, some fields are dependent on others. When adding or deleting records in the system, you could break the system in any number of ways, like disrupting existing formulas or creating unrealistic values. When considering different scenarios of what kinds of data might enter your org or how your end-user might interact with your app, you need to define some rules to help verify your data's integrity. This allows you to make assumptions elsewhere in the org on the condition that the data you are using is valid and that it is properly set up as you would expect.
After you set up these requirements for what quantifies valid data, you are ready to start adding data into your org. This article explains how to check data against your requirements to validate your data, and how to get started loading data into your org.
To ensure data integrity, the platform provides you the declarative (point-and-click) tool known as validation rules. A validation rule is a database-centralized rule that prevents Force.com from saving a record when the rule's condition is true. Centralized data integrity rules are important because they ensure data quality across all access points, including end-user apps, data loads, and Web service calls.
Building the logic for a validation rule is like a formula; however, in all validation rules, the formula expression must be an assertion that evaluates to either true or false. In every validation rule you build, the formula evaluates the expression with the submitted values of the fields. If the expression evaluates to “true” it displays the specified error message and prevents the update.
The image below is an example of a formula field from the workbook, and can be applied to extend your data model in the Quick Tutorials. The rule is on the line item object, and it checks to ensure that there is enough inventory in stock when creating a line item for a given number of units sold. If the number of units sold exceeds the total inventory, the formula will evaluate to true and the error message will fire.
Lets evaluate the formula piece by piece. The first line of the formula uses an "IF()" logic function. When you click on a function, the syntax of how to use the function and a description of what it does appears below. In the case of the IF() function, the first parameter is an expression that will evaluate to either true or false, the second parameter is the value the statement will evaluate to if the expression is true, and the third parameter is the value the statement will evaluate to if the expression is false.
In the first parameter, we check to see whether or not the validation rule is applied to a new record using the ISNEW() function.
If the record is new, the second parameter will then be used to define the if statement. The second parameter uses a comparative operator to check if the number of units sold (Units_Sold__c) is greater than the total inventory (Merchandise__r.Total_Inventory__c).
Merchandise__r.Total_Inventory__c < Units_Sold__c ,
Notice the "Merchandise__r" on the total inventory field. You can reference fields on the parent object in your merge field through your relationship field. In this case, line item has a master-detail relationship with merchandise (the master-detail field on line item being Merchandise__c). Above we reference the total inventory field on merchandise, but we can access all fields on merchandise through the relationship field by changing the merge field syntax from __c to __r and appending the field to the end.
The third parameter has a nested if statement to determine the outcome if the record being evaluated is not new. If you are checking a line item update, you must check against the previous value for units sold.
IF ( Units_Sold__c < PRIORVALUE(Units_Sold__c), FALSE, Merchandise__r.Total_Inventory__c < (Units_Sold__c - PRIORVALUE(Units_Sold__c)) )
If your new value for units sold is less than the previous value, we know there is enough stock in inventory because the validation rule already validated that there was enough inventory for the previous value. By defining the second parameter as "FALSE", the if statement will be defined by the false value and it will cascade upwards as the value for the above if statement as well; therefore, the formula would not fire an error because it evaluated to false.
If the new value for units sold was more then the total inventory, you need to check if there is enough inventory to cover the difference. For example, if we ordered originally 10 units but updated the record because we now need 15, there needs to be at least 5 more items in stock to cover the order change. This logic can be seen in the third parameter of the nested if statement.
Once you have all of your objects and fields built out, and you have set up the proper validation rules to ensure data integrity, you can start creating records. You can create records manually within your org, or you can load several records at once by loading data in either a spreadsheet or a .csv file.
Note: There are two distinct classifications for the information that gets stored to the database: data and its associated metadata. The data is the actual information you are storing to the database, whereas the metadata (also known as metacontent) is a collection of attributes that describe the related data. Metadata provides information about one or more aspects of the data, such as: means of creation, purpose of the data, time and date of creation, and creator or author.
The native import wizard is the cloud tool every org provides to let you load data through your browser. One thing to note: You must be a Salesforce administrator to use this wizard. By navigating to Setup -> Administrative Setup -> Import Custom objects, you can import records for any object you create in your app.
Before importing data, be sure that all of your objects and fields are built out. While it is possible to go back and update records, it can be timely to modify existing data, so double-check before starting to load the data. Click Start the Import Wizard! and begin configuring the import. Select your object and begin mapping the affiliated fields in the org to the columns in your spreadsheet.
If you are inserting records with relationships to other records, be sure to load the dependent records in a logical order of operations. For example, if you are loading data for both projects and team members, where team members have a lookup field referencing projects, you would load data for projects first and then load team members referencing those projects.
The first method you could use is the Data Loader. The Data Loader is an easy graphical tool that helps you to get your data into Salesforce objects. The Data Loader is a software extension that works in conjunction with Excel (on PCs only, sorry Apple people ) and allows you to load data directly from your spreadsheet. It can also be used to extract data from database objects and perform bulk deletions.
When creating the spreadsheet for your object, think of the object itself as the entire table and the columns as your fields. Each row represents a record, and the data to store for each field goes in the associated column. Once you have the spreadsheet set up, you can upload it using the Data Loader and create a mapping schema to ensure that all of the columns are mapped to the proper field within the org.
When loading many records, it is often too tedious to map the relationships yourself in a spreadsheet. To make your data loads easier, try using VLookups, a search function in Excel, to map these relationships for you within your spreadsheet. You need an external identifier on your parent object other than the unique Salesforce Id to build this formula.
To get started, export your parent object data with the external Id and the Salesforce Id. Create your VLookup formula checking against the external Id reference column in your child data. By linking the two columns in a formula, you can associate the Salesforce Id in another column of that row on your child record, which you can then use when mapping your child object import data.
Another tool available for inserting data or performing other data manipulation (DML) operations is Workbench. Workbench is a powerful, Web-based suite of tools designed for administrators and developers to interact with their orgs. Workbench allows users to describe, query, manipulate, and migrate both data and metadata in their orgs directly in their web browser. Workbench also provides several advanced features for testing and troubleshooting.
To login to Workbench, simply navigate here in your web browser and if you are not already authenticated into your org put in your credentials. You need administrative privileges to be able to do anything with these tools in your org.
Workbench is designed to be an application administrators and developers can use to quickly view their organizations' data and metadata, test and troubleshoot their own applications, and be a one-stop shop for interacting with the various Force.com APIs.
When working with data in Workbench, or trying to grab data from your org programmatically, you can access the data by either a query or a search. Salesforce uses the native query language SOQL (Salesforce Object Query Language) to return a specific list of data based off of a formulaic search statement. You can also use SOSL (Salesforce Object Search Language), which can construct text searches. Unlike SOQL, which can only query one object at a time, SOSL enables you to search text, email, and phone fields over multiple objects simultaneously.
Though the tools are essentially different ways to do the same thing, they are optimal for differing use cases. If you are perfoming large data loads or exports, scripting, or other performance intensive operations, you should use the Data Loader because Workbench is subject to browser and connection timeouts. On the contrary, for quick, on-the-fly interactions Workbench is a powerful cloud tool that can save you time and eliminate the need for software installs.
It is important to create validation rules in order to ensure data integrity at the data level. By setting up rules that prevent bad data from being inserted into the database, you can make assumptions based off its validity in business processes elsewhere in your app. In addition, by setting up validation rules before importing any data, you can sanity check your old data to make sure that all data going in falls within your standards.
Once you have your validation rules setup, and all of your old and/or new data is in the system, you are ready to start setting up security for how users can view and edit that data.