Application Storage

It is important to consider your customer's storage needs and use cases with regard to their data creation and consumption patterns early in the application design phase. This ensures that your object schema is the most optimal one with respect to large data volumes, data migration processes (inbound and outbound), and storage cost. In this chapter, we will extend the Custom Objects in the FormulaForce application as we explore how the platform stores and manages data. We will also explore the difference between your application's operational data, configuration data, and the benefits of using Custom Metadata Types for configuration management and deployment.

You will gain a good understanding of the types of storage provided and how the costs associated with each are calculated. It is also important to understand the options that are available...

Mapping out end user storage requirements

During the initial requirements and design phase of your application, the best practice is to create user categorizations known as personas. Personas consider a user's typical skills, needs, and objectives. Using this information, you should also start to extrapolate their data requirements, such as the data they are responsible for creating (either directly or indirectly, by running processes), and what data they need to consume (reporting). Once you have done this, try to provide an estimate of the number of records that they will create and/or consume per month.

Share these personas and their data requirements with your executive sponsors, your market researchers, early adopters, and, finally, the whole development team so that they can keep them in mind and test against them as the application is developed.

For example, in our...

Understanding the different storage types

The storage used by your application records contributes to the most important part of the overall data storage allocation on the platform. There is also storage used by the files uploaded by users and that used by so-called Big Objects. Big Objects are a type of object, allowing you to store billions of records of data in the platform (we will discuss them later in this chapter). By default, in a Scratch org, you can store up to 1 million records in your Big Objects.

From the Storage Usage page under the Setup menu, you can see a summary of the storage used, including those that reside in the Salesforce Standard Objects.

Later in this chapter, we will be creating a Custom Metadata Type object to store configuration data. Storage consumed by this type of object is not reflected on the Storage Usage page and is managed and limited...

Reusing the existing Standard Objects

When designing your object model, a good knowledge of the existing Standard Objects and their features is key to knowing when and when not to reference them. Keep in mind the following points when considering the use of Standard Objects:

• From a data storage perspective: Ignoring Standard Objects creates a potential data duplication and integration effort for your end users if they are already using similar Standard Objects as pre-existing Salesforce customers. Remember that adding additional Custom Fields to the Standard Objects via your package will not increase the data storage consumption for those objects.
• From a license cost perspective: Conversely, referencing some Standard Objects might cause additional license costs for your users, since not all are available to the users without additional licenses from Salesforce. Make sure that...

Importing and exporting data

Salesforce provides a number of its own tools for importing and exporting data, as well as a number of third-party options based on the Salesforce APIs; these are listed on AppExchange. This section will focus on a more complex scenario when importing records with other record relationships, as it is not possible to predict and include the IDs of related records, such as the Season record ID when importing Race records; this section will present two solutions to this:

• Salesforce DX CLI Data Import and Export
• Salesforce Data Import Wizard

The following subsections will go into the preceding tools in more detail.

Salesforce DX CLI Data Import and Export

When developing and testing your solution...

Options for replicating data

Enterprise customers often have legacy and/or external systems that are still being used or that they wish to phase out in the future. As such, they may have requirements to replicate aspects of the data stored in the Salesforce platform to another platform. 

The following lists some platform and API facilities that can help you and/or your customers build solutions to replicate data:

• Replication API: This API exists in both the web service SOAP and Apex form. It allows you to develop a scheduled process to query the platform for any new, updated, or deleted records within a given time period for a specific object. The getUpdated and getDeleted API methods return only the IDs of the records, requiring you to use the conventional Salesforce APIs to query the remaining data for the replication. The frequency at which this API is called is...

External data sources

One of the downsides of having data not stored on the platform is that the end users have to move between applications and logins to view data; this causes an overhead, as the process and data are not connected.

Salesforce Connect (previously known as Lightning Connect) is a chargeable add-on feature of the platform. It has the ability to surface external data within the Salesforce user interface via the so-called External Objects and External Data Sources configurations under Setup. They offer similar functionality to Custom Objects, such as List View, Layouts, Custom Buttons, and also Reports. 

External Data Sources can be connected to existing OData-based endpoints and secured through OAuth or Basic Authentication. Alternatively, Apex provides a Connector API, whereby developers can implement adapters to connect to other HTTP-based APIs. Depending...

Creating a new FormulaForce package version

If you wish, you can create a new version of the FormulaForce package and install it in your test Scratch org, as described in Chapter 1, Building and Publishing Your Application. The summary page during the installation of new and upgraded components should look like the following screenshot: 

The preceding screenshot shows a portion of the components that will be installed. The following screenshot shows further information from the package's install page:

The preceding screenshot shows the Custom Metadata Type records that will be installed during the package installation. Once you have installed the package in your test Scratch org, visit the Custom Metadata Types page under Setup and click on Manage Records next to the object. You will see that the...

Summary

In this chapter, you have learned about the declarative aspects of developing an application on the platform that applies to how an application is stored and how relational data integrity is enforced through the use of the Lookup field deletion constraints and defining unique fields. The Master-Detail relationships allowed you to model containment concepts in your data model to allow you to represent clear ownership concepts for your user's data. We also learned how to consider the data storage implications of extending your schema across columns instead of rows, and the benefits of the cost of storage for your end users. Finally, you also learned about a new type of object known as the Big Object, for storing billions of records in Salesforce.

In this chapter, we have now covered some major aspects of the platform with respect to packaging, platform alignment...