Designing an Application for Group and Professional Edition

Abstract

There are currently 72,500 salesforce.com customers (as of March 2010). A number of these customers are small-to-medium business using Group Edition (GE) and Professional Edition (PE). GE and PE do not contain all of the objects and features found in Developer Edition (DE). Therefore, an application developed in your DE organization might not work in a GE or PE org.

This article is intended for partners planning to sell an application to GE and PE customers. The following will help you understand what features are (and aren't) available in these editions, and looks at how and when to design applications that support multiple editions.

Background

There are multiple environments you can use to create apps, but this article will focus on the DE org because it's the only org that can create managed packages. It is recommended you use a managed package when building for GE and PE, as this allows you to add more sophisticated functionality to your app.

The Appendix found in Architecting a Commercial App provides an overview of all production environments that salesforce.com customers would use. You'll notice there are objects and features not available in GE and PE. Therefore it’s critical to understand what functionality is included, so that you can make design considerations to accomplish your objectives.

Note: Currently Contact Manager Edition (CME) does not allow AppExchange package installations, so it will not be included in this article. Check back for a future revision that includes design considerations for CME apps.

Why support Group and Professional Edition?

A number of salesforce.com customers use GE and PE. As such, it may make a lot of sense to your business to support these editions. Creating a version of your application for GE and PE will instantly expand your potential customer market. Also, if you have tiered offerings, supporting GE and PE provides a way to offer an entry solution you could later up-sell. Later in the article, you'll learn how you can create a managed package that can be extended for up-sell opportunities.

Furthermore, as part of the AppExchange Partner Program, your managed package will be eligible for special permissions allowing you to take advantage of unique benefits ensuring your app will properly install and function in GE and PE. Apps built on Force.com and which have these special permissions are called Aloha Apps. Aloha Apps will be featured on the AppExchange here.

Upon eligibility, an Aloha App is Apex authorized and immune to certain edition limits. In addition, if your app requires API integration, eligible partners can gain API access to GE and PE orgs. For more information on the Partner Program, including eligibility requirements, please visit us at www.salesforce.com/partners.

Note: Your app can only be an Aloha App and receive the Aloha App icon on your AppExchange listing if it's packaged as a managed package.

To learn how to make your managed package an Aloha App, jump to the How to make an Aloha App? section.

Apex Authorized

As a general rule, one cannot run Apex in a PE or GE. However, there is one exception to this rule. Apex that you develop in DE can run in GE and PE, if the following conditions are met:

  1. Apex is installed into the GE and PE org via a managed package.
  2. Apex does not expose classes as a Web service - these can be installed, but not invoked (more below).
  3. Apex is not dependent on features and functionality that exist only in EE or UE (e.g., record types and/or Campaigns) unless it's dynamic Apex.
  4. Your app and Apex have passed the Security Review and been "Apex Authorized."

Please note this benefit is only available to eligible partners.

Apex Authorization means that Apex (classes, triggers and email services) in your app will run in GE and PE, even though those editions do not support Apex by default. It is important to note this does not mean the GE or PE customer can create new Apex or modify Apex in your app. They can only run the existing Apex in your app. As noted above, any Apex classes that have been exposed as a Web service cannot be invoked from an external Web app in GE or PE even with this special permission.

To be clear, let's say you also host a separate Web app that needs to call an Apex class in your app. You might expose one of your Apex classes as a Web service and include it in your managed package. For DE, EE or UE, you will be able to invoke this Web service externally, but in GE and PE, it will not work.

However, using Apex to make Web service callouts is allowed in GE and PE. For instance, if you are planning to make a Web service callout to an external Web service like Google, as long as the managed package is authorized, these classes will function in GE and PE.

Apps/Objects/Tabs Limit Immunity

All salesforce.com editions have limits that restrict the number of apps, objects, and tabs that can be used. Normally this limit would be a problem if your prospective customer is already using their entire allotment of apps, objects, or tabs, but there exists a special permission that allows your app to be exempt from those limits. This means your app can be installed into any org without worrying about the normal app, object, or tab limits. To be sure, there are additional limits that will still be in affect, but they are listed here in documentation. For instance, if you have any custom objects with more than 100 custom fields, or you have more than 50 custom record types, your app will not install in GE or PE.

API Access

Finally, if you are building a composite solution where you need to make API calls to GE and PE, after passing your Security Review, you will be eligible for an API Token (a.k.a. Client ID) that can be appended to your SOAP headers when making integration calls. This special key will allow your app to successfully make calls to GE/PE even if the customer does not have API access. In the past, the Client ID only supported PE customers, but now it also supports GE customers.

The Force.com platform has 2 Web services API: Data API and Metadata API. It is important to note the API Token will only grant GE/PE access to the Data API, not the Metadata API. The Metadata API allows you to dynamically create various components you typically create in Setup - this is how the Force.com IDE works. For instance, creating a custom field dynamically is not possible in GE and PE even with the API Token.

Note: You cannot use the ClientID with the AJAX Toolkit in custom JavaScript, S-controls or anywhere in your app where the value can be exposed to the end customer.

What features and objects are available?

The best way to determine what features and objects are available in GE and PE is through the online help (you can login with any edition to access). Search for any feature or object and you'll quickly see what edition(s) are supported. For instance, if you wanted to develop enhancements around the Lead object, you'll know what editions support this object at the top of the help page as shown in Figure 1.

Figure 1: Lead Object is supported in all Salesforce CRM Editions (GE, PE, EE and UE)


The following appendix will help you identify many of the objects and features supported in GE and PE. It is imperative to examine these resources before you begin designing your app to ensure it only uses objects/features supported.


Designing to Support Multiple Editions

Supporting GE and PE provides an opportunity to up-sell and release richer versions of your app that can support more advanced features found in EE and UE. With that said, it's important to understand how you can support multiple editions using various Force.com technologies. There are two concepts that can be leveraged. The first approach uses extension packages and the second leverages Dynamic Apex. There are benefits to both, so be sure to review both strategies before designing your app.

Supporting Multiple Editions with Extension Packages

Managed packages provide the ability to distribute your app with the option to upgrade and extend, while allowing your customers to tailor the app to their business. An extension package is another package that can be used to extend and enhance a core managed package. This can be an ideal approach when building apps for GE/PE, as you can build a core managed package that supports the lowest edition and then build extension packages that add additional features to support editions like EE and UE. Figure 2 outlines the concept of extension packages.

The Developer's Perspective

From a developer perspective, the process is as follows:

  1. Create a managed package in your DE org (DE 1) that leverages features supported by GE and/or PE - this will be your base managed package
  2. Upload the managed package in a Released state (be sure to test as Beta first, as some components cannot be modified/deleted once released)
  3. Install your base managed package into a separate DE org (DE 2) to begin building additional functionality
  4. In DE 2, create a new package that includes a component that reference the base managed package (for instance, if you create a custom field on a custom object from the base, once you add that custom field to your package, your package will automatically become an extension)
  5. Upload your new extension package (this can be unmanaged or managed)

For more details on creating an extension package, review the documentation.

The Customer's Perspective

From a customer perspective, the process is as follows:

  1. Install base managed package and configure
  2. If the customer has an edition that supports features in the extension package, install extension package and configure (extension requires base managed package to be installed first)


Figure 2: Supporting Multiple Editions


Using extension packages is a smarter and safer choice to avoid multiple code sets, as well as up-sell your customers. For instance, if you decide to build a package that supports GE/PE (let's call this lite) and a separate package that supports EE/UE (let's call this premium), you will have duplicate code and no upgrade path. If a GE customer has installed your lite version and then decides to upgrade to EE, without an extension package, the customer will have to uninstall the lite version, download the data, install the premium version and migrate the data, all this to get the advanced features. This can be a tedious process and require additional support resources.

Now imagine the same situation using extension packages. The same GE customer could install the base version of your app (still called lite) and if they upgrade to EE, they can install the extension package (still called premium) that introduces some advanced features. This is easier for the customer (and partner) because now they just need to install the extension, instead of uninstalling a lite version and installing a separate premium version. Plus, your customer's data and customization is not affected.

When using extension packages, there may be instances where the extension package needs to call an Apex class in the base package. If this is a requirement, you must make sure the desired Apex class(es) are made global. Please note that if you make a class global, the code is still obfuscated since the base package will be managed. In other words, making an Apex class global does not expose the code, it merely makes it accessible by extension packages.

Supporting Multiple Editions using Dynamic Apex

Dynamic Apex provides ISVs the ability to create more flexible apps by providing functionality to:

  • Access object and field describe information
  • Write dynamic SOQL queries, dynamic SOSL queries and dynamic DML

Using dynamic SOQL, SOSL, and DML, an app can be tailored precisely to the customer's edition as well as the user's permissions. This is useful when designing an app with the intent to support multiple editions. Using Dynamic Apex, it is possible to create one managed package for all editions you plan to support without having to use extension packages.

When you typically reference a feature or object in your package not supported by GE or PE, the installer will prevent installation of the package. This can include adding a custom field on a standard object not supported (i.e. Campaigns and/or Assets), or making an Apex reference to features like multi-currency or territory management. However, if you only use Dynamic Apex to reference these unsupported features and objects, and do not include components in the package (i.e. workflow, record types, custom fields on unsupported objects, etc.), you can install and run your managed package in GE and PE. The important piece to consider is you must code your Dynamic Apex in a way that can support both use cases. Therefore if your customer does not have a specific feature or object, your app will still function.

The following example uses Dynamic Apex to describe the org's objects and fields. You can use this example to understand your customer's org and then use dynamic SOQL, SOSL, and DML to manipulate your app.


Security Access in GE/PE

Both GE and PE do not support custom profiles. As a result, when a customer installs your app, they will not be able to define which profiles have access to what. Therefore, you should be sure to design your app to work for the Standard User profile at a minimum. Furthermore, these standard profiles are not editable, and field-level security is handled on the page layout. In other words, any fields you want to access to must be on the page layout or they will not be visible by the API or Visualforce.

For instance, if you've create a custom Visualforce page that displays a field, this field must be on the default page layout for it to appear in the Visualforce page. The same is true with API integration. You cannot read/write to a field that is not on the page layout in GE and PE.


Sample Scenarios

Here are some scenarios to help you understand when and how to build for GE and PE.

Scenario 1: You want to build an app that uses record types and workflow
Since record types and workflow are both features not found in GE or PE, you will need to decide if you want to support GE/PE. Assuming you do, you can build a base managed package that does not include record types and workflow. After uploading this managed package in a released state, you can install it into another DE org to start building the extension. Your extension can add record types and workflow that will be installed and leveraged by your EE and UE customers.

Scenario 2: You want to build an app with 80 custom objects and 25 custom tabs
Typically this would present a problem for GE and PE because of their objects and tabs limit. However, you can now request a special permission be applied to your managed package making it immune to custom objects, tabs and apps limits. So even if your app has 80 custom objects and 25 custom tabs, with this special permission applied, your app will install normally into GE and PE.

Scenario 3: You want to build an app that makes Apex callouts to a Web service
Apex doesn't generally run in GE/PE, but if you get your managed package authorized during the Security Review, your Apex will execute as expected. So for this scenario you would build your Apex callout to invoke your external Web service and then include this class in your package. During the Security Review, request that your package be Apex Authorized to ensure the code will run in both GE/PE.

Scenario 4: You want to build an app that leverages Campaigns
Similar to scenario 1, Campaigns is a feature not supported by default in GE or PE. PE has the option to purchase Campaigns as an add-on, but for this scenario, you have 2 options that may work. The first option is to build a base managed package that does not reference Campaigns. Once complete, upload and install into another DE org to build the Campaign functionality as an extension package. Now your GE and PE (without Campaigns) customers can install the base, while the rest can also install the extension to get additional features. The second option could require only one package if you are using Dynamic Apex as the only reference to Campaigns (as described above), and ensure your package does not include a custom field on the Campaign. Your app can then be installed in GE and higher and if Campaigns is in your customer's edition, then your Dynamic Apex can manipulate Campaigns as expected.

Scenario 5: You want to build a composite app where your receive inbound calls
You have a separate hosted app that you want to integrate with Salesforce, so you'll need to make API calls to GE/PE customers. By default, this is not possible, but if you are an eligible partner, you can request a special API Token that allows your SOAP calls to integrate with GE/PE. You will just need to embed the Client ID in the SOAP header of your external code. Take a look at the Use of ClientID page for examples on embedding your Client ID inside the SOAP header. For more information on the Partner Program, including eligibility requirements, please visit us at www.salesforce.com/partners.

How to make an Aloha App?

By now, you understand there's many special permissions you can take advantage to build for GE and PE. If you've built an app and you think it's ready to work with GE/PE as is, you can log a case at the Partner Portal and create a case requesting any of the permissions mentioned (Apex Authorization, Apps/Objects/Tabs Limit Immunity, and/or API Access). Note that your application has to have a managed package associated with its listing and you must be an eligible partner. For more information on the Partner Program, including eligibility requirements, please visit us at www.salesforce.com/partners.

Keep in mind you may still need to re-architect your app to support GE/PE, even with these special permissions active. As a partner, you are entitled to various test environments to ensure your app will work properly against GE/PE, you can learn more here.

Summary

As of March 2010, there are 72,500 salesforce.com customers and a substantial portion of these customers use GE and PE. Building an app that supports these customers can help you penetrate the SMB market as well as expand your revenue potential. Aloha Apps are specially blessed to install and run in GE and PE as long as you follow the details described above.

Furthermore, developing your app as recommended, you can minimize the effort required by both your customers and development team. And remember, don't forget to test before you release.


References


About the Author

Sati Hillyer is a Sr. Technical Alliances Manager at salesforce.com. His background consists of technical evangelism, product management and product marketing. At salesforce.com, his mission is to ensure partners experience technical success architecting their SaaS app and business on Force.com. He can always be reached on the discussion boards, look for shillyer.

Retrieved from "http://wiki.developerforce.com/page/Designing_an_Application_for_Group_and_Professional_Edition"