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.

Attribution to: Joey Chan

Possible Suggestion/Solution #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

Attribution to: jordan.baucke

Possible Suggestion/Solution #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

Attribution to: zachelrath
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/547