Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

What are the considerations when trying to build an AppExchange Application that works for Group or Professional Edition? I understand that there are a lot of Professional edition org and it would be great to be able to have them as customers too.

share|improve this question

2 Answers 2

up vote 7 down vote accepted

Building for 'Group Edition' and 'Professional Edition' there are some things to keep in mind:

  • Professional Edition doesn't support web service calls unless the org is API enabled (although this is possible it's not well documented)

  • Permission sets are not available in in PE, and including them in a package can cause issues uninstalling a package from a PE org.

  • Use of @RemoteAction calls aren't limited in the same way, so they're advisable for supporting PE.

  • Some types of Dashboards aren't supported in GE and can limit the user from installing into their org.

  • Sharing rules and Profiles are not supported in the same way in PE

  • Some objects such as Campaigns are not included in these editions by default.

You should always attempt to install your app into a PE and GE edition org before releasing it to the AppExchange in order to confirm it's interoperability so that users coming in from the AppExchange don't encounter issues.

I'm giving a presentation at Dreamforce '12 that Includes notes on supporting and testing multiple editions. It's called Team Development on the Force.com Platform for ISVs

share|improve this answer
1  
Record types are also unsupported. –  ca_peterson Aug 17 '12 at 5:35
1  
This answer isn't fully correct (anymore). Permission Sets are supported, but they cannot be edited. This feature exists so that professional edition orgs with record types/custom profiles can assign custom permissions. API can be used in PE with a client ID (for ISV partners), even if the org isn't enabled for it. Same thing for canvas apps and connected apps. –  sfdcfox Sep 12 '13 at 22:03

It is very important to note that when a feature is listed as "Not Supported" in GE/PE, this means there can be NO API references to the feature throughout your Code. For instance, here are some gotchas related to non-supported features in GE/PE:

  1. Record Types: just because your package does not include any Record Types on Standard or Custom Objects does not mean that your package can go in GE/PE. If your Package ever even refers to the RecordType API object, such as in a Utility method that you might use for your EE/UE customers for getting all active/available record types by name/id, your package will be excluded from GE/PE orgs. However, use of the DescribeSObjectResult getRecordTypeInfos() family of methods does not exclude your package from GE/PE. So in summary:

    • use of Schema.RecordTypeInfo IS allowed
    • use of RecordType object is NOT allowed.
  2. Force.com Sites: again, any hard-coded reference to the Site or SiteDomain objects in Apex will exclude your package from GE/PE orgs. However, Dynamic SOQL, i.e. Database.query('select Id from Site limit 1') is a good way to get around this, as it moves the feature detection from compile-time to run-time. I would assume that, as with RecordTypeInfo, use of the System.Site Apex class methods would not exclude you from GE/PE.

Furthermore, you might think that deprecating a method or part of your code that uses a not-allowed API object would allow successive versions to be allowed in GE/PE. Nope!

Also, a couple of features not supported in either GE or PE orgs not mentioned in Jordan's answer:

  • Record Types
  • Custom Report Types
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.