Becoming a Salesforce partner and the benefits of doing so

As an ISV, the Salesforce Partner Program has many advantages. The first place to visit is https://partners.salesforce.com/. You will want to focus on the areas of the site relating to becoming an AppExchange Partner. Click on Becoming a Partner to get started. It is free to join, though you will want to read through the various agreements carefully, of course.

Once you wish to start listing a package and charging users for it, you will need to arrange billing details for Salesforce to take the various fees involved. While this book is not equipped to go into the details, do pay careful attention to the Standard Objects used in your package, as this will determine the license type required by your users and the overall cost to them, in addition to your charges.

For example, integrating with CRM objects that existing Salesforce customers are already using, such as Account, Contact, and Opportunity objects can be beneficial to you as a feature of your application, since it’s an appealing, immediate, and seamless integration not found on other platforms without further configuration or even, in some cases, coding effort.

If you’re planning on using Standard Objects, and are in doubt about the costs (as they do vary depending on the type), you can request a conversation with Salesforce to discuss this; this is something to keep in mind in the early stages.

Make sure, when you associate a Salesforce user with the Partner Community, you utilize a user that you use daily (known as your Partner Business Org user) and not one from a development or test org. Once you have completed the signup process, you will gain access to the Partner Community. The following screenshot shows what the current Partner Community home page looks like. From here, you can access many useful services:

Figure 1.6: Navigation options on the Partner Community home page

This is your primary place to communicate with Salesforce and access additional materials and announcements relevant to ISVs, so do keep checking it often. You can raise Cases and provide additional logins to other users in your organization, such as other developers who may wish to report issues or ask questions.

Security review and benefits

The features described in this section are only available once your managed package has gone through a Salesforce-driven process known as a security review, which is initiated via your listing when logged into AppExchange. Unless you plan to give your package away for free, there is a charge involved in putting your package through this process.

While the review is optional and there is nothing stopping you from distributing your package installation URL directly, keep in mind that Salesforce displays a banner during installation and, once installed, it informs admins that the package has not gone through a security review. Furthermore, you will not be able to benefit from the ability to list your new application on AppExchange for others to see and review. More importantly, you will also not have access to the following features to help you deploy, license, and support your application. The following is a list of the benefits you get once your package has passed the security review:

• Bypass installation org setup limits: Limits such as the number of tabs and Custom Objects are bypassed. This means that if the installation org has reached its maximum number of Custom Objects, your package will still install. This feature is sometimes referred to as Aloha. Without this, your package installation may fail. You can determine whether Aloha has been enabled via the Subscriber Overview page that comes with the LMA application, which is discussed in the next section.
• Licensing: You are able to utilize the Salesforce-provided License Management Application (LMA) and Feature Management Application (FMA) in your LMO.
• Subscriber support: With this feature, users of a managed package in the subscriber org can enable, for a specific period, a means for you to log in to their org (without exchanging passwords), reproduce issues, and enable much more detailed debug information, such as Apex stack traces. In this mode, you can also see custom settings that you have declared as protected in your package, which is useful for enabling additional debug or advanced features.
• Push upgrade: Using this feature, you can automatically apply upgrades to your subscribers without their manual intervention, either directly through the Push UI, on a scheduled basis, or via the Push API. You may use this for applying either smaller bug fixes that don’t affect Custom Objects or APIs or for deploying full upgrades. The latter requires careful coordination and planning with your subscribers to ensure that changes and new features are adopted properly. This feature is also available to unlocked packages.
• Usage Metrics: This feature provides additional analytics on how customers are using your application, such as the objects they are using and the parts of the user interface they are accessing. Your Product Management team can use this to drive roadmap priorities and track the adoption of new features.

  Salesforce asks you to perform an automated security scan of your software via a web page (http://security.force.com/security/tools/forcecom/scanner). This service can be quite slow depending on how many scans are in the queue. Another option is to obtain the Eclipse plugin from the actual vendor, CheckMarx, at http://www.checkmarx.com, which runs the same scan but allows you to control it locally or via your Continuous Integration (CI) build system. There are a number of code analysis tools now available for Apex, such as the open source project PMD, which includes rules for security and other code quality checks: https://pmd.github.io/latest/pmd_rules_apex.html. There is also the Salesforce Code Analyzer plugin (SFCA) that makes it easier to work with PMD rules for APEX: https://forcedotcom.github.io/sfdx-scanner.

This book focuses on building a fully native application; as such, additional work involved in so-called “hybrid” applications (where parts of your application have been implemented on your own servers, for example) is not considered here. However, keep in mind that if you make any callouts to external services, Salesforce will also most likely ask you and/or the service provider to run a BURP scanner, to check for security flaws.

Make sure you plan a reasonable amount of time to go through the security review process; it is essential that you initially list your package, though if it becomes an issue, you have the option of issuing your package install URL directly to initial customers and early adopters.

Creating test and demo orgs via the Environment Hub

Partners can use the Environment Hub to create orgs for further testing or demo purposes. Orgs can be linked and logins can be managed here as well. Unlike scratch orgs you can get from the Dev Hub, these orgs have additional user licenses. It is also possible to link your Trailforce Source Org (TSO) and create orgs based on templates you define, allowing you to further optimize the base org configuration for your own further testing and demo needs. For more information, review the documentation detailing the Environment Hub (https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/environment_hub_intro.htm).