Building an App that works in Group & Professional Edition?

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.

Answers:

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.

Method 1

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

Method 2

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


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x