[SalesForce] Is it possible to get data storage details of a Salesforce organization using Apex code

I am trying to get details of space used by several sObjects, Attachment and other using Apex code. I can get Attachments details but is there any possibility to get how much data has been consumed by an sObject e.g; Case, Lead etc..

In my opinion this may not possible. Any ideas ?

Best Answer

This has been made possible by now via the OrgLimits class [1].

Map<String,System.OrgLimit> limitsMap = OrgLimits.getMap();
System.OrgLimit fileStorage = limitsMap.get('FileStorageMB');
System.debug('Limit Name: ' + fileStorage.getName());
System.debug('Usage Value: ' + fileStorage.getValue());
System.debug('Maximum Limit: ' + fileStorage.getLimit());

You seem to be able to use the limit descriptors that are available via the REST API's limits resource [2].

[1] https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_OrgLimits.htm [2] https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_limits.htm

Related Solutions

[SalesForce] How to increase data storage in salesforce developer edition

Developer Edition orgs are meant for development of new code to put into packages and install into customer production accounts. They cannot be upgraded into Active orgs, which have different storage limits and the ability to add more.

If this is for business use, I recommend signing up for a Lightning Professional sales cloud trial here: https://www.salesforce.com/editions-pricing/sales-cloud/

They come with 1Gb data storage and I believe 5Gb file storage as well. Trials expire after 30 days, at which point you can purchase a license.

Salesforce Storage Issue – Hitting Data Storage Limits with Email Messages

My org has run into similar issues with the amount of data storage consumed by EmailMessage. Unfortunately, EmailMessage is a difficult object to work with.

From my own testing:

There are two fields on EmailMessage that are treated differently by Salesforce when it comes to storage. TextBody and HtmlBody. These fields consume storage space for every byte stored (i.e. count your characters, and that's how many bytes are consumed, multi-byte characters push that up even higher).
Salesforce also treats the HtmlBody field in a special way that allows the html to be rendered (which I was not able to reproduce with another field).
If you get an email with only an HtmlBody, Salesforce will use that to additionally populate the TextBody field.
The TextBody and HtmlBody fields cannot be updated unless the Status is "Draft" (i.e. you're composing the email from the Salesforce UI)
We can clone EmailMessage records (which allows us to alter the two 'body' fields), and there is a system-level permission (set audit fields) that can be granted to maintain system fields like CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate, etc...
If the CreatedDate is carried over, it does appear that the relative record order is preserved
If you transfer the content of TextBody and HtmlBody to custom fields (and null out TextBody and HtmlBody), EmailMessage records only take the standard 2kB that pretty much every other record does
The easiest way for us to "clone" EmailMessage records is to use something like Dataloader to extract the records, then re-insert them (i.e. don't map the Id field). If you're transferring TextBody and HtmlBody to custom fields, you can just do that with some simple re-mapping in Dataloader
Attachments on emails are another matter (and I don't recall if I worked out how to handle that)

So we can reduce the storage consumed by EmailMessage records, but there can be some serious drawbacks to consider (html portion of emails not being rendered in Salesforce if you store it in a custom field instead of HtmlBody, perhaps the standard "send an email" button would cease to work for such an EmailMessage).

In my org (and in others too, most likely), one of the big offenders is that Salesforce is storing the entire email thread every time a customer replies. So if your email conversation goes through 3 round trips (you -> customer -> you -> customer -> you -> customer), you're effectively storing 21 emails when the final email comes into Salesforce.

Repeated bits like email signatures and the to/from/cc/date information don't help matters either.

In terms of possible solutions I was looking at, here are the ones I came up with in order of storage space saved (most savings -> least savings)

Use a trigger, scheduled/batch apex, or a middleware tool to capture EmailMessages as they arrive, and send them to an external platform (I'm currently investigating Amazon's "Snowflake" for this). Develop a Lightning component to make callouts and retrieve the email data on demand. Once stored off-platform, delete the EmailMessage from Salesforce. (Fairly customization-heavy, disrupts standard functionality)
Delete previous emails under a given parent on receipt of a new one (chances are pretty good that you'll still have the entire thread)
Archive/Export emails older than a certain age
Use Dataloader (or a similar tool) to effectively clone records, and map TextBody and HtmlBody to custom fields (likely disrupts standard functionality, but saves a bunch of space)
Use Dataloader (or a similar tool) to clone records and simply leave the HtmlBody field unmapped (I think I found that Html takes something like 3x the characters as plain text on average)
Use Dataloader (or a similar tool) to clone records, and remove rendundant information (signatures, the entire thread history. Being able to process the data to detect/remove redundant information is another matter)

Best Answer

Related Solutions

[SalesForce] How to increase data storage in salesforce developer edition

Salesforce Storage Issue – Hitting Data Storage Limits with Email Messages

Related Topic