If you are exploring various data storage models and feel confused about which one to choose, we’ve got you covered.
In this blog, we will talk about the different data options, their advantages, when to use them, and when not.
Types of Data Storage Methods
We will discuss the following 4 types of storage methods:
- Custom Objects
- Custom Settings
- Custom Metadata
- Static Resources
Let’s go!
Custom Objects
The most widely used storage option is custom objects. These are very powerful and come with features like Triggers, Sharing, FLS Reports, easy automation with Process builders and Flows, etc.
Despite the fact that almost everything a user does gets stored in custom objects, the data does not get hidden from view. Someone out there can easily access your data and even alter it.
For instance, you want to save some highly private information or app secrets. Keeping it secure will be your topmost priority, isn’t it? Not only will your app fail the Security Review pass, but you will also be unable to deploy data with your app. The data in the object inside a subscriber’s app should be added there post-installation. Therefore, custom objects may not be the best-suited storage option in every situation.
Custom Settings
Custom settings were popular among the users before Custom Metadata came into play.
These can be updated with standard Apex DML and are even lightweight. The data stored in each custom field gets counted against your data storage limit. Moreover, you can store only up to 300 custom fields each.
Some advantages of Customer Settings are:
- They are cached for fast reads
- They don’t require SOQL for access
- They are protectable
Some disadvantages of Custom Settings are:
- You can not have Triggers, Flows, Validation Rules in Custom settings.
- You can not deploy any values in Custom settings. So, these are deployed empty and you need to either add data later in a post-install script or ask the user to fill it in after installing.
- Less versatile as you can not create multiple records using custom settings.
Make sure to keep the advantages and shortcomings in mind before using Custom settings.
Custom Metadata
Custom Metadata is relatively new and most likely a better alternative for Custom Settings. Custom Metadata can do the job better than List Custom Settings, exactly why Salesforce recommends the former over the latter.
Unlike Custom Settings, Custom Metadata acts like an object in which you can store multiple records. These records aren’t data. They are Metadata instead. But, how is it beneficial for you?
Well, it allows you to deploy them like any other metadata and even lets you access them from the App Page configuration page or Validation Rule directly. That’s a win-win situation right there! Moreover, they read quite fast and don’t need SOQL for access. This saves you from the post-install scripts.
A few more advantages of using Custom Metadata are:
- You can protect a whole Custom Metadata Object or one Custom Metadata Record
- It allows you to send URLs to private screens
One major drawback of using Custom Metadata is that you can not update it with DML, making it a bit difficult to work with. Moreover, they can not store Triggers or Flows just like Custom Settings.
Static Resources
Static resources can be used for storage purposes once in a while. It allows you to store a significant amount of data in CSV or JSON formats, and that too at an affordable price.
If your app must include sample data, you can leverage Static Resources to store your data. This will let you load everything on your special screen or post-install screen later. Normally, Static Resource can store anything that you have to read or write.
How To Choose The Right Storage Option For Yourself?
Now that you know the primary storage options, we have curated a special guide to further help you choose the right storage feature.
When Is ‘Custom Objects’ Best-Suited?
- While saving subscriber-specific app secrets like integration keys
- While saving user data
- For user-managed complex configuration items
- For complex configuration items
- that require custom UX or needs to be handled by admin
When Is ‘Custom Metadata’ Best-Suited?
- For user-managed complex configuration data that can be handled by admin and don’t require a custom UX
- For configuration items that do not change and are controlled by the application
When Is ‘Custom Settings’ Best-Suited?
- User-specific configuration items like a preference
- Simple configuration data
When Is ‘Static Resources’ Best-Suited?
- When saving sample data
Some Important Things To Keep In Mind
- Custom Settings can either be public protected or public.
- Custom Metadata Objects can be Public, Protected-Package, or Protected-Namespace.
- Custom Metadata Records can also be protected.
- You can make Custom Metadata or Custom Settings less restrictive via the package updates (from Protected to Public) but you cannot go the other way around (from Public to Protected).
Let’s Wrap Up!
Selecting the right storage space for your application is extremely crucial.
However, launching an app involves effort, skill, and time. From the basic app idea to the selection of storage options, each and every step acts as an essential building block.
Choosing an incorrect approach can cause many troubles with keeping your app upgrades functioning and managing how your users access your app.
At CEPTES, we have 7+ solutions and products listed in AppExchange and understand exactly when things get cumbersome for you. Click here to get in touch with us today!
For more info-packed blogs like one, visit our blogs section.
