Process Builder – Availability in Professional Edition

When we made the decision to allow permission sets in professional edition, it was to follow a similar model to profiles:

1. you can assign them but you can't create or edit them without having customizable profiles enabled in your org
2. ISVs (Independent Software Vendor) can provide access to their features by embedding permission sets in their package with more specific access than what we allow for profiles through the package installation wizard. This access can include access to their custom objects, fields, apex classes, or visualforce pages. However, it cannot include access to standard functionality like user permissions, standard objects, standard fields, IP ranges, etc...

To answer your original question, if you mean user permissions like Modify All Data, no, it's not possible to affect user permissions with permission sets. The reason for this is that user permissions are not supported with packaging - for instance, it's not possible for an ISV to assign Modify All Data in a permission set that they package with their other metadata and you install as a subscriber. It's also not possible for an ISV to add access to standard object or field permissions in a packaged permission set which could otherwise have an impact on user permissions.

However, if you mean a user's permissions like CRUD to a packaged object or field, then yes, by assigning that packaged permission set to a user in professional edition, that user will now have access to that ISV's field or object. Since this is limited to what an ISV can add - it should protect you from inadvertently affecting any user's access to non-package metadata.

To see an example of what is possible from what is not with regards to permission sets in professional edition, check out the following blog posting: http://www.salesforcehacker.com/2013/05/whered-that-field-go-installing.html.

Hope this helps...

As per the Salesforce documentation,

You must be an eligible partner with salesforce.com and your app has to pass the security review. The appropriate permissions will automatically be enabled after you pass the security review.

Also, here are some important considerations for using Apex in GE/PE.

• GE/PE customers can’t create or modify Apex in your app; they can only run the existing Apex.
• Your Apex code should not depend on features and functionality that exist only in DE, EE, UE, or PXE, or your app will fail to install.
• Make sure to use REST if you plan to expose an Apex method as a Web service. Apex classes that have been exposed as a SOAP Web service can’t be invoked from an external web app in GE/PE.
• Using Apex to make Web service callouts is allowed in GE/PE. For instance, if you’re planning to make a Web service callout to an external Web service, as long as the managed package is authorized, these classes will function in GE/PE.