Chapter 3. Application Storage

It is important to consider your customers' storage needs and use cases around their data creation and consumption patterns early in the application design phase. This ensures that your object schema is the most optimum 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 applications operational data and configuration data and the benefits of using Custom Metadata Types for configuration management and deployment.

You will obtain 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 when it comes to reusing or attempting to mirror the Standard Objects such as Account, Opportunity, or Product, which extend...

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 the users' typical skills, needs, and objectives. From 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.

Tip

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 FormulaForce application, it is likely that managers will create and consume data, whereas race strategists will mostly...

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 another type of storage used by the files uploaded or created on the platform. From the Storage Usage page under the Setup menu, you can see a summary of the records used, including those that reside in the Salesforce Standard Objects.

Note

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 in a different way.

Tip

The preceding page also shows which users are using the most amount of storage. In addition to the individual's User Details page, you can also locate the Used Data Space and Used File Space fields; next to these are the links to view the users' data and file storage usage.

The limit shown for each is based on a calculation between...

Reusing the existing Standard Objects

When designing your object model, a good knowledge of the existing Standard Objects and their features is the 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 you understand the differences between Salesforce (CRM) and Salesforce Platform licenses with respect to the...

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. When importing records with other record relationships, 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 a solution to this.

Salesforce provides Data Import Wizard, which is available under the Setup menu:

It is straightforward to import a CSV file with a list of race Seasons since this is a top-level object and has no other object dependencies. However, to import Race information (which is a related child object to Season), the Season and Fasted Lap By record IDs are required, which will typically not be present in a Race import CSV file by default. Note that IDs are unique across the platform and cannot be shared between orgs.

Tip

If you need a reminder of the structure of these...

Options for replicating and archiving 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. Likewise, in order to move unwanted data off the platform and manage their data storage costs, there is a need to archive data.

The following lists some platform and API facilities that can help you and/or your customers build solutions to replicate or archive data. There are, of course, a number of AppExchange solutions listed that provide applications that use these APIs already:

• 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...

External data sources

One of the downsides of moving data off the platform in an archive use case, or with not being able to replicate data onto 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 is not connected.

The Salesforce Connect (previously known as Lightning Connect), a chargeable add-on feature of the platform, is 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 a similar functionality to Custom Objects, such as List View, Layouts and Custom Buttons. Currently Reports, and Dashboards are not supported, though it is possible to build custom report solutions via Apex, Visualforce or Lightning Components.

External Data Sources can be connected to existing OData based end points and secured through OAuth or Basic Authentication. Alternatively, Apex provides a Connector API...

Summary

This chapter has further explored 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 applying unique fields. The Master-Detail relationships allow you to model containment concepts in your data model. We also considered the data storage implications of extending your schema across columns instead of rows and the benefits on the cost of storage for your end users.

Upload the latest version of the FormulaForce package and install it into your test org. The summary page during the installation of new and upgraded components should look something like the following screenshot. Note that the permission sets are upgraded during the install.

Once you have installed the package in your testing org, visit the Custom Metadata Types page under Setup and click Manage Records next to the object. You will see that the records are...