8

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.

Improve this question

2 Answers 2

Reset to default
11

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

Improve this answer
2
  • 1
    Record types are also unsupported.
    – ca_peterson
    Commented Aug 17, 2012 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 ♦
    Commented Sep 12, 2013 at 22:03
3

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
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .