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 PESome 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:
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 DescribeSObjectResultgetRecordTypeInfos()
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.
- use of
Force.com Sites: again, any hard-coded reference to the
Site
orSiteDomain
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 withRecordTypeInfo
, use of theSystem.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