Enough Is As Good As A Feast

Auntie Pat Tern loves Sir Thomas Mallory and Mary Poppins, and quotes both when she reminds us "enough is as good as a feast", especially when Tim Toady's eyes are bigger than his stomach at the buffet. So I thought I would look at Salesforce storage limits to see if we have a feast in our Enterprise Edition org (which is the entry-level org for many businesses and the basis for the nonprofit license grant, even those with the nonprofit starter pack pre-installed).

Salesforce currently allocates 20MB of data storage per user in every EE org. But wait, there's more. Every org starts with a minimum of 1GB of data storage. So whether you are a nonprofit with a grant of 10 free licenses or a small business with 50 licenses, you have a minimum of 1GB for data.

More than enough is too much.

But how many records is that? Salesforce allocates 2KB for most records. Articles require 4KB, Campaigns require a whopping 8KB (4 times the size of most other records). That means a basic Salesforce org (Enterprise Edition or better) will have data storage capacity for about 500,000 records (excluding Campaigns and Articles). If you have 100,000 Accounts and 400,000 Contacts for 1-50 users, you are going to need more storage.

If you are using Person Accounts, or if you create a unique Account for each Contact, 250,000 individuals would result in 500,000 records since each individual would require both an Account and Contact record.

Custom objects behave the same as typical standard objects taking 2KB per record, regardless of the number or type of fields associated with those records. Even if you use a lot of rich text fields with large image files, a custom object record still requires only 2KB of data storage. The trick with rich text fields is that they actually are stored as files and so impact file storage rather than data storage.

Consider your storage needs carefully when you create sandboxes. Partial Copy sandboxes currently provide 5GB of data storage, that's more than you have in your production org if you have 50 or fewer users! But they don't offer much in terms of file storage. You may need a Full Copy sandbox for the convenience of copying all of your data at once and accommodating larger amounts of file storage and files from rich text fields.

But for standard data needs, use these basic formulas to calculate your data needs in GB:

( # of records X 2KB ) X 1/1024 X 1/1024

or

( # of Campaigns X 8KB ) X 1/1024 X 1/1024

or

( # of Articles X 4KB ) X 1/1024 X 1/1024

In the first formula, we multiply the number of records you have times 2KB, the data storage typically needed for records to get the required number of kilobytes of storage. Then we multiply by 1/1024 to convert from kilobytes to megabytes and again to convert from megabytes to gigabytes.

In the second formula, we multiple the number of Campaign records times 8KB because they consume a lot of storage compared to typical standard and custom objects. Then we do the same calculations to convert from KB to GB as described above.

The third formula is for calculating the storage needs of Articles since their records require 4KB rather than the standard 2KB. Otherwise it works like the first two, with the result expressed in gigabytes.

Keep in mind that Person Accounts and 1x1 Contact to Account data models will create a Contact and an Account record, so every individual is represented by two records rather than just one.

Salesforce offers options for purchasing additional storage space. You can also upgrade to Performance, Unlimited or similar Editions that offer six times as much data storage per user compared to Enterprise Edition (orgs with fewer than 10 licenses may not see the benefits of the additional storage).

But, as Auntie Pat Tern would say, it is good to be grateful for what you have and know when you've got enough for your share. Salesforce makes it easy to calculate your needs.

Using Flow Rather than Apex: Performance Tests

Some of the newest Flow features allow for working with collections of records and using a single operation for adding those records to or retrieving them from the Salesforce datatbase.  In the past, Flow could only create or retrieve a single record at a time, but recent features give administrators a visual interface for creating powerful and automated solutions to their business problems using clicks-not-code.

Checking time required and limits for Flow.

As the capabilities of Flow converge with those of Apex programming, administrators will no doubt start handling some of the same tasks with Flow that previously required Apex.  Creating and updating records automatically is a great example of a task that administrators with no programming experience can now manage themselves, for multiple records at a time, with Flow and no Apex code.

But if you have a choice between two tools, it is interesting to see how they compare.  Flow is obviously easier than Apex for anyone not trained to code, while Apex is more flexible.

Benchmarking performance differences reveals the impact of using Flow to replace Apex.  I tested this by coming up with both a Flow and a bit of Apex code to create new records for a custom object and comparing their performance according to feedback from the developer console. 

Performance Comparison

To start, I created a simple bit of Apex code to add 1,000 records to a custom object.  The developer console tracked CPU usage as well as the number of database manipulation language (DML) statements, both of which are performance concerns for anyone watching their governor limits.

I then replicated the code using Flow to add a large number of records to my custom object so that I could compare the performance relative to those same governor limits.  Thanks to the collection variable available with Summer '14, I was able to create a Flow that managed a single DML statement for multiple record insert operations using a Fast Create element.  Previously, this would require a single Record Create element for each new record and so the number of DML statements could become excessive and slow without these new features.

Unfortunately, Flow was more restrictive on the number of records I could manipulate with both the collection variable and the Fast Create element.

For the collection variable, I found that I was only able to hold 499 records with a single variable.  Apex is not so limited with lists and arrays.  This limit meant that I could not create as many records with Flow as I could with Apex.

For the Fast Create element, I was even further limted by Flow.  With Apex, up to 200 records can be insterted with a single DML statement and more records can be submitted with insert operation.  Salesforce automatically divides the operation into multiple statements for blocks of up to 200 records.  For example, 201 records result in 2 DML statements according to the debug console.  My Flow got stuck at 200 records, I could not use the Fast Create when my collection contained more.  Even with 200 records, the debug console reported 2 DML statements being executed for the Flow.

Having to reduce my test size meant that neither the Apex nor the Flow had any measurable use of CPU time.  I look forward to being able to insert more records to better compare performance.

One of the Salesforce critical update messages suggests that enabling governor limits for Flows will have an impact on performance.  You should test your Flows with this update enabled before it goes into effect by default in 2015.