If you answered “yes” to any of these questions, you might be ready to build your first app for the AppExchange.

This article will discuss where digital transformation product ideas come from, the differences between managed and unmanaged packages, and when one type makes sense.

This article will also cover how to transform your idea into an MVP (minimum viable product), find your first group of users, and prepare for and pass the Salesforce platform security review to launch your app on the Salesforce AppExchange.

Product ideas are everywhere

Often, ideas for apps come from everyday challenges end users face. These solutions can be for issues the end user solved at multiple employers throughout their career or a one-time experience that was very difficult to overcome.

Some of these solutions arise through using managed and unmanaged packages.

Managed Vs. unmanaged packages

Managed packages

Simply put, a managed package has its code builder hidden. The users of a managed package get all the package benefits, but they don’t have to worry about updating or accessing the code base for any reason.

You can think of a managed package as an app. Managed packages are typically what Salesforce ISV partners place on the AppExchange to sell and distribute to customers.

Managed packages are also fully upgradeable. However, to ensure seamless upgrades, specific changes (such as removing objects or fields) can not be made.

Some other features of managed packages include:

• Unique naming of all components to ensure conflict-free installations
• Versioning support for API-accessible components
• The ability to provide patches for previous versions and seamlessly push updates to subscribers.

Unmanaged packages

Unmanaged packages are typically used to distribute open-source projects or application templates to provide developers with the essential components needed for an application. Once these components are installed from an unmanaged package, they can be edited in the organization they are installed in.

Important differences

At first glance, you might think unmanaged packages are superior because – as the app’s end user – they are free to use. However, if you’re looking for an app that will be constantly developed, improved, and supported by its creator, the managed package should be your preferred choice.

From the viewpoint of someone building apps, while the unmanaged package takes less time and effort to develop, it doesn’t carry the Salesforce stamp of approval from the security review that the managed package does.

How to productize your idea and create your MVP

The first step in creating a software product is to determine what functionality and features are the ‘bare-bones’ – the minimum criteria necessary for the product to showcase its potential benefits to those who would use it.

Once you have developed this set of requirements, you have essentially created your minimum viable product (MVP). This process is usually done in-house with your company's product developers and testers. What you are building becomes your alpha version.

The primary purpose of an alpha version is to identify bugs and features that are not functioning as intended. Think of this as your ‘pre-release’ version – unavailable to people outside your organization.

Hopefully, along your journey, you have talked to some companies about your idea (your product) to help validate that your product will meet the needs of a gap identified in business processes.

You will also gain some interest from these companies in becoming one of your early (beta) test customers to install the app and put it to use with real-world scenarios.

Congratulations! It’s time for a celebration – you have a product being used by a customer. Now it’s time to scale your app for the masses (and public signups).

First and foremost is to consider the implications of building in a namespace. For example, metadata that cannot be easily packaged (such as connected apps), or efficiency expectations. As a customer of a managed package, I expect the logic to be quick and robust. Hence, as the creator of the managed package, I would likely prioritize Apex, a robust architecture, and unit tests over a Flow unless the logic is very basic.

Secondly, I would recommend being wise in terms of package upgradeability to make updates as smooth and quick as possible. For example, if a customer clones a permission set, package updates on the permission set won’t reach the cloned set that the customer is using. Therefore, we need to think about a more granular permission set strategy to ensure customers receive updates without needing to clone.

Third, but equally important, is to deeply understand the security review process to avoid losing weeks of rework when trying to list the package on AppExchange.

Manuel Moya

Technical Architect, Developer, and DevOps Engineer
Hutte

Source: Hutte

Get ready for the Salesforce security review

The security import review process helps identify vulnerabilities that hackers, malware, or other threats can exploit. The Salesforce security review team tests your cloud solution using threat-modeling profiles based on the most common web vulnerabilities. The review team essentially attempts to penetrate the defenses programmed in your solution.

Their goal is to extract or modify data they don’t have permission to access. Understanding what issues are scanned helps you prepare your application for the security review.

Prevent secure coding violations

All solutions published on the AppExchange must meet the exact security requirements. Some of the more common secure coding violations include:

• Loading JavaScript files from third-party endpoints: Avoid dynamically loading third-party JavaScript files from content delivery networks (CDNs) in favor of loading code from your package's static resources folder.
• Running JavaScript in the Salesforce domain: JavaScript code from pre-built reports and different vendors can run in the same origin. Vendor JavaScript code is sandboxed to prevent interference. Don’t break out of a sandbox or run code outside your origin. Use Visualforce, Aura, or Lightning Web Components as they run in the proper origin.
• Exposing private data when debugging: Logging sensitive data with debug statements in a production environment is a security vulnerability. Redact the data or omit it from the logs.
• Using sample code in production: Sample code should only be used as an educational tool in preparation for developing your application. Try to write the code yourself, and avoid copying code from sources you don’t directly control.
• Disabling Lightning Locker: Lightning Locker is a critical security feature for Lightning code. It provides component isolation, allowing code from many sources to execute and interact using safe, standard APIs and event mechanisms. Be sure to enable Lightning Locker for your AppExchange packages containing Lightning components or applications.
• Securing communication: Ensure your custom object solution is accessible only via secure connections, such as SFTP and HTTPS. Don’t use HTTP and FTP protocols that don’t encrypt the information that flows over the internet.

Prepare to launch your app

You’ve just received notice that your app passed the security review. Awesome! Now you’re ready to launch that app, right? It’s not that simple. Salesforce will want to review and approve your business plan first.

Salesforce must approve your business plan before you can launch your app on the AppExchange for list views. If you’re new to the AppExchange Partner Program, you can sign your partnership agreement with Salesforce after they approve your business plan.

Steps to publish your app on the AppExchange

1. Connect a packaging organization to the comprehensive dashboard publishing console
2. Create or edit your provider profile
3. Create or edit your AppExchange listing
4. Add a business plan to an AppExchange listing
5. Make your AppExchange listing effective
6. Select an installation option
7. Register your package and choose your license settings.

Now you are ready

Launching apps on the AppExchange can lead to market leader gains by helping other companies:

• Increase their efficiency
• Spend less time utilizing manual, outdated processes
• Improve security and decrease risk.

If you would like to enhance your app with Git-based Salesforce development – get in touch!