Skip to main content

Best practices in a Salesforce app development for 2nd generation packaging

About Us
Published by JET BI
09 September 2024
24

Best practices for developing Salesforce apps using 2nd generation packaging

 

Introduction

Any Salesforce developer has to deal with the concept of "2nd generation packaging" in the process of professional development, or at least even when preparing for an important interview. But, nevertheless, even after several years of work in that sphere, not everyone succeeds in getting practical experience in developing such an  application at all stages of its creation. The necessary steps for building the package, its further maintenance and updating are described step by step and in detail in the documentation, and we will not stay on it here. 

The topic of this article is the answer to the question: “What should you pay attention to when developing a Salesforce application for 2nd generation managed packaging in order to spend less extra effort and time on it?”
 

Key points

When creating your solution, you should pay attention to all aspects of planning and development, but in our case it is worth highlighting the following points:

  • Metadata Management
  • Namespace Management
  • Testing
  • Security
  • Documentation

Let's focus on each of them. This approach will help us understand the details more clearly.

 

Metadata Management

At the stage of developing the technical design of the solution, it is necessary to consider which metadata should be protected from viewing and modification by customers. First of all, of course, these are your proprietary components, as well as sound business logic. 

You need to think about which Custom Metadata Types and Custom Settings will be included in the package: you should not include unnecessary ones there. Also set a strategy for naming metadata components, as this makes the metadata easier to understand, helps avoid conflicts and ensures consistency across packages. 

If your application depends on the installation of other packages, declare the dependencies in the "sfdx-project.json" file. This way you will protect the user from errors caused by the missing required metadata.

 

Namespace Management

When creating Salesforce managed packages, the namespace must be used: since they involve subsequent distribution, you need to make sure that all components are uniquely identified and do not overlap with other packages and customizations. It is worth remembering that you need to think through the naming aspects at an early stage of planning, because the name space configured and used in the package cannot be changed.

It is a good practice that the namespace should be short, memorable, and associated with your product or brand. 

Pay attention that in the Salesforce 2nd generation packaging it is possible to share the name space between applications. This can be useful in the complex development of several packages.

 

Testing

As you know, testing helps ensure that your app functions correctly and meets user requirements.

The main idea in testing applications developed for the 2nd generation of bundling is that you need to make sure that it works correctly after installation in the customer's environment, so in addition to the usual UAT and End-to-End testing, it is important to pay attention to checking the isolation of your application. For the latter, testing in a sandbox environment is best suited, while it is preferable to use empty Scratch orgs to check whether all the necessary components are in the package and how they work correctly.

It is also worth mentioning that the required unit test coverage is at least 75%, but it is worth aiming to initially exceed this figure - in the future it will be easier to comply with this requirement when releasing updated versions of the application, especially when developing a modular solution. 

Also think about testing security as well, You can find more information about security in the next section.

 

Security

Security is a very important part of any product. Surely many of you know that when you place your package on AppExchange, you need to go through a security review. It is best to initially take this aspect into account when creating a product. 

Make full use of the opportunities offered by Salesforce for solutions based on their platform, for example, such as field-level security, encryption and sharing rules to protect sensitive data.

In general, it will be very useful to read the available materials regarding the security review before starting development. You can find them here.

 

Documentation

For any product on the market, you just need properly created and detailed documentation that will help any of your customers use your solution for their needs in the best way. After all, it greatly enhances the attractiveness of your app. 

It is better to create and supplement documentation at all stages of development, as this optimizes the amount of resources required for this. It also eliminates possible gaps.

 

In conclusion

Proper testing, including security, will help ensure that your application works correctly in various environments, and clear and comprehensive documentation will improve usability and adaptation. Planning ahead will save time and effort for future updates and maintenance. 

Much more detailed information than in this brief review can be found in the Second-Generation Managed Packaging Developer Guide
If you need our professional consultation, please, leave a request and we will happy to help you.


Alex Husachok
image
Expertise
Question to the expert
image

We have available resources to start working on your project within 5 business days

1 UX Designer

image

1 Admin

image

2 QA engineers

image

1 Consultant

image
Related Articles
All articles
image
Is Salesforce Winning the Public Sector Race?
An analysis of Salesforce's rapid expansion into the U.S. public sector, tracing its path from cautious early government licensing deals in the 2010s through the launch of Government Cloud in 2012, its pivotal role in COVID-19 vaccine rollouts, and its 2025–2026 push into military and intelligence work via Agentforce and Missionforce. The piece covers major 2026 contracts — including a $5.6 billion Army deal, a $1.6 billion VA agreement, and Pentagon Impact Level 5 authorization — alongside real-world case studies like California's REAL ID processing and the UK's NHS back-office operations. It also examines the structural obstacles still facing Salesforce and other vendors in government tech: legacy IT systems decades old, outdated federal procurement rules, budget constraints, and organizational caution around AI adoption, plus the competitive pressure from Palantir, Microsoft, and Oracle in the race for public sector AI spending.
28 August 2026
image
Why Your Salesforce Flows Are Agentforce's Biggest Problem
This article argues that the most underestimated risk in Agentforce deployments isn't data quality — it's the automation layer: years of overlapping Flows, Process Builder processes, Apex triggers, and managed package logic that no one has reviewed end-to-end. It explains why AI agents inherit automation complexity without the tribal knowledge human admins carry, why technical debt only becomes visible after an agent hits it in production, and why a clean demo is no indicator of production readiness. The article closes with a concrete, tool-by-tool inventory approach using Flow Trigger Explorer, Salesforce Optimizer, Setup Audit Trail, Apex Debug Logs, Agent Builder, and Health Check — scoped to the specific processes the agent will actually use rather than the whole org.
23 July 2026
image
How to Wire Multiple Salesforce Projects in One Org Without Breaking Everything
This article maps the real integration patterns that emerge when multiple Salesforce projects — both managed packages and unpackaged code — share a single org. It covers four concrete patterns: attaching custom triggers to package-owned objects, calling global members exposed by managed packages, writing directly into another project's objects, and runtime-guarded reads of package data. It then addresses access control for authenticated and guest users, including the Master-Detail wall and the without sharing elevation pattern. The piece closes with eight concrete risks (compile-time dependencies that block uninstall, upgrade coupling, silent cascade failures, access invisible to admins) and six actionable recommendations for keeping cross-project coupling manageable.
08 July 2026