Apps within the Salesforce ecosystem are very unique offerings. The term “app” causes the mind to jump immediately to the mobile applications found on Android and iOS devices. AppExchange apps are an entirely different species as they provide extended capabilities and features into an already feature-rich business application environment.
Many of our initial interactions with potential clients that want to develop a “Salesforce App” need this initial conversation. Preconceived notions of what Salesforce Apps are and what the process of creating one entails warrants a thorough conversation with these companies to insure from discussion #1 that all parties are in alignment with expectations. This helps with anticipating the effort, time, and costs associated with these projects and ensuring all three of those types of resources are put to use effectively and efficiently.
Once it is understood what it means to have an AppExchange App for their customers, the conversation makes a natural shift into how we can aid in the success of the app. Broken down into the following milestones, these core objectives are what these potential clients can anticipate on their journey to the AppExchange.
Milestone 1: App Readiness Considerations
From the business' perspective
What problem does your app attempt to solve for its potential users?
What features and offerings are to be included in the app?
Would your customers agree?
Milestone 2: Partner Registration
Get started at https://partners.salesforce.com. The partner registration process is one of the earliest deliverables achieved when starting a new app. Many of our clients will be well through the registration process before our initial project kick-off calls.
This process typically includes some of the following steps:
App and business use case review
Technical questionnaire document
Legal documents
The results of these efforts establish you as a Salesforce partner and earn you access to the “Partner Community” (what’s behind the login form at partners.salesforce.com). Here you have a cornucopia of partner goodies, including various community conversations and groups to connect to other partners, developers, and product managers; access to support where you can log Cases with Salesforce to investigate issues, request features, etc; as well as access the “Publishing Console” where your AppExchange Listing will be created.
Most importantly at this point, you’ll establish what will become your “Partner Business Org.” If you have an existing Salesforce org for your business, you can leverage it. Alternatively, you can use an existing Developer Org or request a new org altogether. Regardless, it’s recommended you keep your development and packaging orgs separated from your Partner Business Org. It’s also not uncommon to have Salesforce provision two courtesy license to your org of choice to ensure you have full access to the org (and commonly also dedicate one of these licenses to your development partner).
The “Partner Business Org” will commonly be used for:
Connecting to the AppExchange to receive lead data sourced from your App’s installs.
Access to the “License Management App” (dependent on Security Review)
Provision licenses to your customer’s orgs for usage of your app
Provide secure support to your customers
This is what gives your customers the ability to “Grant Login Access”
Rather than customers providing you their credentials or provisioning a temporary account to their org, a user of the org can simply grant access
This provides you, the app developer, access to the customer’s org, as that customer.
Now you can replicate issues as they would with the benefit of being able to see logs, exceptions, settings and more that are normally obscured from the end users.
Usage of the Partner Environment Hub
This allows you to relate all other orgs, whether development, packaging, testing, QA, etc together.
The Partner Environment Hub gives you an easy way to quickly generate additional Salesforce orgs (with higher limits than a developer org) as needed that are already associated with your partner account.
Milestone 3: Development
Some of these milestones can happen concurrently. Development can effectively begin even prior to the first milestone and be migrated to the appropriate orgs later (or connect these existing orgs to your PBO via the Partner Environment Hub as needed).
At this point, you’ll likely have a development team working on code, have an established stand-up routine to review progress, blockers, and next steps and be able to start previewing the app to various stakeholders. You’ll likely have identified testing/QA roles and procedures.
Milestone 4: Release Preparation and Beta
The development of the app is concluding for the initial version. At this point, you’ll want to start polishing any beta documentation for customers as well as providing additional training material to the necessary parties. Remember those beta customers? Time to start lining them up for installs of a beta package into their sandbox orgs and solicit feedback based off of their experiences. The most important thing you can do at this point is ensure that the app works/meets their expectations, is painless as can be to install and configure, and any necessary complexities that might introduce confusion are well documented and communicated to the customers.
Concurrently, if not already started in a previous milestone, you can start building out the AppExchange App’s Listing in the Partner Community. For this step, take a look at other listings and then gather all the details that go into the App’s description, screenshots, videos, documentation resource, support information, etc.
Milestone 5: Initial Release
You’ve received beta customer feedback and made revisions. The teams involved feel that the app is as good as it is going to get for this version and you’re ready to produce a “Release” package. Once you do this, for many reasons, there’s no turning back. While the package was still a “beta” release, components could freely be added and removed; however, upon marking it as “released” the components included in your app are included for good. Some things can be removed with the right careful steps while others can never be removed - anything that customers can potentially build customization around using native platform features is likely to fall into that category. This protects them from developers that could otherwise remove key components from the app that have become essential to the customer’s business flow customizations.
Once released, beta customers can now install the app into their Production environments (betas can’t be installed in Production orgs). You can also begin the steps to submit the app to the Security Review process.
Milestone 6: Future Releases
Between the last milestone and now, you’ll be awaiting feedback from the AppExchange Security Review team and pursuing approval. This may require additional revisions and a few rounds of back and forths, but ultimately you’re striving to receive that “Your app has passed” email. Now you can flip the switch on your AppExchange listing to change it from “Private” to “Public,” meaning people can find it through the various categories or by searching on the AppExchange.
You’ll probably already have started next steps development, gearing towards a new v2 release. Start talking about your upgrade and patching strategy. Understand when it makes sense to schedule and push a new release to your customers and when it makes sense to notify users of a new version and allow them to upgrade as needed.
