Determine the Salesforce Edition for Your App
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the basic differences between the editions supported by ISVforce applications.
- Given a set of requirements, determine the editions your solution can support.
- Describe why it’s important to determine the Salesforce edition and Salesforce licenses in your target org.
- Describe when an AppExchange Partner determines which Salesforce editions to target.
Determine the Correct Edition
It’s now time to determine which editions of Salesforce you want to support. Again, imagine you are a furniture designer who has designed a beautiful couch. Based on your design, you have several pre-orders. The factory builds the couch. When the first delivery is made, you discover that the couch doesn’t fit through the front door. Its dimensions are bigger than most doorways. Not a good outcome. A little more planning could have saved you and your customers quite a bit of a headache.
We want you to avoid this type of outcome when you build your AppExchange app. You design your app in a special Developer Edition (DE) org configured for AppExchange partners, or a Salesforce DX Scratch org. Both org types have everything to support developing different types of apps serving different audiences. However, the environment of your target customer might not include all those features. If you don’t limit the features in your solution to those available in your target org, you’ll have to rethink your plans.
What Is a Salesforce Edition?
We provide different editions of Salesforce to offer different levels of functionality and resources to our customers. As an AppExchange partner, you need to learn about four editions: Unlimited Edition (UE), Enterprise Edition (EE), Professional Edition (PE), and Starter (S).
Editions are tiered, with each edition building on the previous one. Going up a tier increases the features available and raises the limits on certain features. For example, S orgs don’t support record types, but UE, EE, PE, and DE do. An S org has a limit of five user licenses. A PE or higher edition org can have an unlimited number of user licenses. For more details on the differences, see our editions comparison chart.
The Importance of Choosing a Salesforce Edition
The edition you target determines which features you can use in your app. It also defines limits on resources that your app can consume. You aren’t limited to supporting one edition. For example, you can provide different packages for different editions. Or you can design your solution to be sensitive to the edition in which it’s installed. Keep in mind, your business plan influences your choice of target editions as well.
If you are building an OEM Embedded app, the only type of org you can provide net-new customers is EE. Existing customers can install your app only if they have EE or higher edition orgs.
Orgs, Editions, and Licenses
The Salesforce cloud environment is often compared to an office building. Everyone shares infrastructure, such as plumbing and electricity, but each business has its own dedicated space that other tenants cannot enter—its org. When customers choose an edition, they choose their office space. Some tenants choose a few rooms without a reception area or kitchen. Others choose an entire floor with a reception area, kitchen, and executive offices. The smaller office space is like a PE org; the entire floor is like an EE org.
When customers purchase user licenses, they are determining who has access to the “offices” and what type of access they get. Standard user licenses provide “keys” that allow access to all org features. Other user licenses provide more limited access. For example, users with Customer Community licenses can’t access Lead and Opportunity objects and can’t be mentioned in flows.
Customers also purchase feature or permission set licenses for non-standard features. For example, using Salesforce Knowledge in the Sales Cloud requires a permission set license.
Choose Which Editions to Support
Let’s look at the audiences for different editions.
| Edition |
The low down... |
|---|---|
| Starter (S) |
The edition for businesses with five or fewer users. Functionality is minimal. |
| Professional Edition (PE) |
Mid-size customers use PE. It has everything a customer needs for CRM and no limit on user licenses. It doesn’t include all the bells and whistles, but it does includes easy-to-use customization, integration, and administration tools to facilitate small to mid-size deployments. |
| Enterprise Edition (EE) |
EE is our most popular edition. It includes all core tools and technologies, and meets the needs of large and complex businesses. In addition to all the functionality available in Professional Edition, it includes advanced customization and administration tools to support large-scale deployments. |
| Unlimited Edition (UE) |
UE is like EE on steroids. Large enterprises purchase these editions. In addition to all the functionality available in EE, UE includes Premier Support, increased storage limits, and other features. |
For your internal architecture, OEM Embedded app orgs are the equivalent of EE. But customers have contractual restrictions. They can’t see data or objects related to Sales or Service Cloud functionality. And they can’t use features to build out more apps. See the ISVforce Guide for details.
Most customers are on an EE or higher edition. Customers with these higher editions usually purchase the most licenses, so they represent the biggest market. EE and higher orgs have the most built-in functionality, which can make your design easier to implement.
PE edition customers, unlike many large enterprise customers, often have a short buying cycle, which could help you sell your app more quickly. If you’re thinking about adding PE as another edition, consider the effort relative to the potential market.
Determine the Available Declarative Features
It’s critical that you limit your design and development to use only the features available in your target org. We recommend periodically checking the ISVforce Guide and other Salesforce documentation so that you don’t have to back track.
For example, let’s say you’re considering S or PE customers. The Architectural Considerations section in the ISVforce Guide contains a table that lists some of the most popular features that AppExchange partners use.
| Feature |
Starter | Professional Edition |
|---|---|---|
| Assets |
No |
Yes |
| Campaigns |
No |
Yes |
| Contracts |
No |
Yes (with Sales Cloud) |
| Forecasts |
No |
Yes (no Opportunity Splits or Custom Field forecasts) |
| Ideas |
No |
Yes |
| Products |
No |
Yes |
| Solutions |
No |
Yes |
| Record types |
No |
Yes |
| Permission sets |
Yes |
Yes |
| Custom profiles |
No |
Yes |
| Custom report types |
No |
Yes |
| Flows and approvals |
No |
No (See note.) |
| Apex code |
See note. |
See note. |
| Sharing rules |
No |
Yes (for some features) |
| API |
See note. |
See note. |
| Sites |
No |
No |
- All listed features are available in DE.
- As a partner, flows within your application run in a Professional Edition org. However, customers can’t create their own flows. They must purchase the feature directly from Salesforce.
- A client ID allows your app to use the API for integration for composite apps. For more information, see Using Apex in Group and Professional Editions and API Access in Group and Professional Editions in the ISVforce Guide.
This list isn’t exhaustive. To ensure that the features you use are available, check the list of editions that appear on documentation pages. Check out this page on record types.
Starter isn’t listed, so it doesn't support record types.
Determine the Available Programmatic Features
The features and functionalities we’ve been describing are around declarative customizations—those that can be done in Salesforce’s point-and-click interface. You can also customize an org programmatically using, for example, Salesforce’s cloud-based programming language Apex. S and PE orgs have no access to Apex or the APIs. However, as an AppExchange partner, your approved application is allowed to use Apex and the APIs listed in the following table in customers’ S and PE orgs. The ISVforce Guide has all the details on getting your app allowlisted and getting an API access token for your app.
| API |
Access to S and PE |
|---|---|
| Web Services (SOAP) |
Yes, with token |
| Apex methods exposed as Web services (SOAP) |
No |
| Web services (REST) |
Yes, with connected app consumer allowlisting |
| Apex methods exposed as Web services (REST) |
Yes, with connected app consumer allowlisting |
| Chatter REST API |
Yes |
| Metadata API |
Yes, with token |
| Bulk API |
No |
| Data Loader tool (uses SOAP Web services) |
No, can’t set the token |
| Streaming API |
No |
| Platform Events |
No |
Limits and Your Target Org
All Salesforce orgs share infrastructure. To make sure that no org consumes excessive resources, we enforce limits. This is one way Salesforce ensures trust with you and our customers. Limits vary with editions. For example, consider these limits on validation rules, a feature for verifying values on input fields.
| Feature |
Starter | Professional Edition |
Enterprise Edition |
Unlimited and Performance Editions |
|---|---|---|---|---|
| Number of Active Validation Rules per Object |
20 |
20 |
200 |
200 |
When existing customers install your app, they carry the overhead for your use of resources in addition to whatever resources they are already using. Let’s say a customer in a PE org has 18 active validation rules on the Account object, and your app adds 3 more. Your app will fail to install in the customer’s org, because the limit on active validation rules is exceeded.
However, the apps of eligible AppExchange partners do have leeway for three specific features. When an app has passed the security review, the applications, objects, and tabs included in the package don’t count against the customer’s limits.
For more information on declarative limits, check our help docs.
Watch for limits around the execution of code as well. If transactional limits are exceeded, the entire transaction fails, and your customer is not a happy camper. To learn more about programmatic limits, read Execution Governors and Limits.
Ensure Your App Works in Your Chosen Editions
You can use your Environment Hub or Salesforce DX to create edition-specific test orgs.
Which Editions Should I Target?
Now let’s practice choosing editions by walking through some scenarios.
Scenario #1: Deal Progress Forecaster
App type:
ISVforce
Base cloud:
Sales Cloud
Target editions:
Enterprise Edition
App functionality:
Add insight to opportunities in Salesforce by:
- Analyzing past related deals
- Analyzing overall usage
- Tying analysis into the current state of a sales rep’s opportunity lifecycle
The sweet spot for this app is customers with an EE or higher edition org because they have large data sets to analyze. Could you design your app to work for S and PE orgs? Look at this table for some considerations.
| If you want to... |
Can customers install your ISVforce app in their S or PE org? |
|---|---|
| Use the role hierarchy to restrict some information |
No. Role hierarchy isn’t available in either of these editions. |
| Create 10 custom objects |
Yes! The apps, objects, and tabs you create don’t count against customer limits. |
| Use the REST API for integration |
Yes! Although your S and PE customers can’t use the REST API to connect to their org, you can! |
Scenario #2: Support Agent Time Tracking
App type:
ISVforce
Base cloud:
Service Cloud using Lightning Service Console
Target editions:
Enterprise Edition
App functionality:
Provide support agents with a time-tracking calendar within the Lightning Service Console. The calendar maintains awareness of an agent’s:
- Schedule
- Working cases
- Availability
The Lightning Service Console is only available in Starter, Professional, Enterprise, and Unlimited editions with Service Cloud. You can’t sell this app to customers without Service Cloud. That limits your total addressable market (TAM), so you may want to consider other alternatives. For more details, read the Lightning Service Console help doc.
Scenario #3: Supplier Sourcing
App type:
OEM Embedded
Base cloud:
Salesforce Platform
Target editions:
Enterprise Edition
App functionality:
Support the supply requisition process for complex projects by helping employees:
- Track part requirements
- Identify suitable vendors
- Track bids and choose bids
Trick question! OEM Embedded apps can only be used with EE and higher edition orgs.
Did You Catch All That?
The editions, user licenses, and feature and permission set licenses of your target customers affect the design of your app.
Whether you are building an ISVforce app or an OEM Embedded app, ask yourself:
- Are the declarative features you want to use available in your target editions?
- Are the programmatic features you want to use available to an AppExchange partner in your target editions?
- Does your design stay within the limits imposed on your target edition?
Congratulations! You made it through, and you’re ready for your quiz!