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.
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
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.
@RemoteActioncalls aren’t limited in the same way, so they’re advisable for supporting PE.
Some types of
Dashboardsaren’t supported in GE and can limit the user from installing into their org.
Sharing rules and
Profilesare not supported in the same way in PE
Some objects such as
Campaignsare 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
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:
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
RecordTypeAPI 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
- use of
RecordTypeobject is NOT allowed.
- use of
Force.com Sites: again, any hard-coded reference to the
SiteDomainobjects 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.SiteApex 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