Edition limits

Customers of salesforce.com subscribe to a specific edition of the service. These editions exist across the various core applications (marketed as clouds) as well as the Salesforce1 Platform offering. The lowest priced edition always has the most restrictions. As you move up in price, these restrictions are reduced, but still exist. As a result of these restrictions, when you build an application on the Salesforce1 Platform, it's always a best practice to have as small of a footprint as possible so that any customer, regardless of the edition, can install your app.

Subscribers of the Salesforce core applications can install and execute code that references any of the objects included in those applications, such as opportunities, assets, or cases. Subscribers to just the Salesforce1 Platform don't have access to those objects and therefore can't install or execute code that references them. If you are building an application for the AppExchange app store, it's critical to determine ahead of time which of salesforce.com's customers you are building it for. Including the wrong object in your package could prevent your ideal customer from being able to install your application.

One of the most important limits to be aware of is the custom objects limit. Each edition has a limit to the number of sObjects that can be created (though at the high end it's in thousands). If you are a subscriber to one of the lower-priced editions, this will impact you as you build the schema for your business. While you can create hundreds of custom fields per sObject, you might be limited to creating as few as 10 custom objects. Complex processes with multiple many-to-many relationships can easily exceed this limit. As always, there are workarounds, you can reuse sObjects, store data as JSON in long text fields, or leverage code to determine relationships. In the end, it might be easier to just pay the piper and upgrade to a higher edition.