Package Installation
Package installation is the process of adding a Salesforce package into an org so its bundled components and functionality become available to users.
Definition
Package installation is the process of adding a Salesforce package into an org so its bundled components and functionality become available to users. A package is a container of metadata (objects, fields, Apex, Lightning components, automation, and more), and installing it deploys those components into the target org. You start an install either from an AppExchange listing or by opening a direct installation URL the package publisher gives you.
During the install you confirm the target org, agree to the publisher's terms, and choose which users get access. Salesforce then deploys the components and runs any post-install steps the package defines. Once it finishes, the package shows up on the Installed Packages page in Setup, where you manage it later.
How a package install actually works
Two ways to start an install
There are two common entry points. The first is AppExchange. You find a listing, click Get It Now, sign in to the target org, and follow the guided flow. AppExchange is the marketplace path, and listings there have passed the Salesforce security review, which gives you some baseline assurance about the code. The second entry point is a direct installation URL. Publishers and developers share a link shaped like /packaging/installPackage.apexp?p0= followed by the package version Id (the 04t identifier). You paste that link into a browser where you are logged in to the right org, and it opens the same installer. Use login.salesforce.com for production and Developer Edition orgs, and test.salesforce.com when the target is a sandbox. The URL method matters when you install a beta version, a version not listed publicly, or an unlocked package that lives outside AppExchange. Both paths land you on the same install screen, so the difference is only how you arrived. Pick whichever the publisher documented for the version you need.
Choosing who gets access
On the install screen you pick one of three access options, and the choice controls which profiles receive the package's permission settings at install time. Install for Admins Only grants access to system administrators and to users with the Customize Application permission, which is the safest default while you test. Install for All Users grants access to every internal user with a standard or custom profile. Install for Specific Profiles lets you map each profile to a package access level, so you decide profile by profile. This choice is not permanent. After install you can still assign the package's permission sets or adjust profile settings to widen or narrow who can use the app. Many teams install for admins only first, validate the app in a controlled way, then roll access out to business users through permission sets. Permission sets are usually the cleaner long-term answer because they add access without editing every profile. Think of the install-time choice as the starting point, not the final state of your access model.
Sandbox first, then production
Installing into production without testing is risky, because a package adds metadata and can interact with your existing customizations, automation, and data model. The standard practice is to install into a sandbox or a Developer Edition org first. There you confirm the package installs cleanly, check that it does not clash with existing fields or Apex, run the publisher's setup steps, and test the features your users actually need. You also see the real storage and component footprint before it touches production. When the package supports it, you can use the same installation URL in both environments, just swapping the login host. After the sandbox round looks good, you repeat the install in production during a low-traffic window. Treat the production install as a deployment event: note the package version, record who installed it, and have a rollback plan in mind. Some packages cannot be cleanly uninstalled if data depends on them, so testing first is not optional discipline, it is how you avoid a problem you cannot easily undo.
Approvals the installer may ask for
Some packages need extra approvals during install, and the screen surfaces them so nothing connects silently. If the package calls external services, you may be asked to approve third-party access, which lets the package reach the endpoints it lists. Packages that make callouts ship with remote site settings or named credentials that define the allowed external URLs, and you confirm these as part of trusting the app. Password-protected packages add another step: the publisher gives you a password or installation key, and you enter it before the install proceeds. This is common for private or licensed distributions that are not meant for the open marketplace. Read each approval prompt rather than clicking through, because you are granting the package the ability to act in your org and reach outside it. If anything in the approval list looks unfamiliar or broader than the app should need, pause and check with the publisher. These prompts are your visibility into what the package will be allowed to do once it is live, and they are easier to reason about before install than after.
What happens after you click Install
When you confirm, Salesforce deploys the package's components into the org. For a package with many components this can take a few minutes, and large installs may finish in the background, with Salesforce emailing you when the deployment completes. The platform compiles Apex, creates the objects and fields, and applies the access settings you selected. If a package defines a post-install Apex script, that script runs to seed data or finish configuration. Once it is done, the components are live and the package appears on the Setup page named Installed Packages. From there you see the version number, the namespace, the publisher, and management actions. Installation is not the same as configuration, though. Most apps still need setup work after install, such as assigning permission sets, adding components to page layouts or Lightning pages, configuring custom settings, and pointing the app at your data. The publisher's getting-started guide usually lists these steps. Plan time for this configuration and user enablement, because an installed but unconfigured package delivers nothing to your users on its own.
Package types change the install behavior
The package type affects what you can do during and after install. A managed package, whether first-generation or second-generation, uses a namespace and locks down most of its internals, so you install it, get upgrades from the publisher, but cannot freely edit its code. Managed packages are how ISVs distribute commercial apps, and you typically upgrade them by installing a newer version over the existing one. An unmanaged package has no namespace and no upgrade path; its components drop into your org as editable metadata, so it suits templates and sample code more than ongoing products. An unlocked package, a second-generation type, is often used for a company's own internal tooling and can be installed by URL and upgraded in place. Knowing the type tells you what to expect: whether you will receive vendor updates, whether you can modify the components, and whether reinstalling a new version is an upgrade or a fresh copy. Check the listing or the publisher's notes so the install and your later maintenance plan match the package you are actually adding.
How to install a package
These steps cover installing a package through the standard installer, whether you start from AppExchange or from a direct installation URL. Run it in a sandbox first, then repeat in production.
- Open the installer
From AppExchange, click Get It Now on the listing and pick your target org, or paste the publisher's installation URL into a browser already logged in to that org. Use login.salesforce.com for production and Developer Edition, and test.salesforce.com for a sandbox.
- Confirm the target and terms
Verify you are installing into the correct org and the right environment type. Enter an installation password if the publisher provided one, then agree to the terms and conditions and continue.
- Choose who gets access
Select Install for Admins Only, Install for All Users, or Install for Specific Profiles. Choose Admins Only while you test, so business users do not see an unconfigured app.
- Approve any external access
If prompted, review and approve third-party access and the package's remote site settings. Read each entry rather than approving blindly, since you are granting the app the ability to call external services.
- Install and wait for completion
Click Install. Small packages finish in seconds; larger ones run in the background and Salesforce emails you when done. Confirm success on the Installed Packages page in Setup.
- Configure and enable users
Follow the publisher's setup guide: assign permission sets, add components to layouts or Lightning pages, set custom settings, and then enable the users who need the app.
Grants access to administrators and users with Customize Application. The safest starting choice while you validate the package.
Grants access to every internal user with a standard or custom profile. Use only when the app is meant for the whole org.
Lets you set the access level per profile, giving the finest control over who receives the package's permissions at install time.
An optional key the publisher supplies for private or licensed packages. Enter it before the install proceeds.
- Some packages cannot be cleanly uninstalled once data depends on them, so always test in a sandbox before production.
- The install-time access choice is a starting point, not the final access model. Refine it afterward with permission sets.
- Installing is not configuring. An installed package usually needs setup work before users see any value.
- For sandbox installs use test.salesforce.com, not login.salesforce.com, or the URL targets the wrong environment.
- Managed packages upgrade in place, but unmanaged packages have no upgrade path, so plan maintenance around the package type.
Prefer this walkthrough as its own page? How to Package Installation in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Package Installation.
Hands-on resources to go deeper on Package Installation.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. During Package Installation, which choice does the admin make about who can use the package?
Q2. Why do mature orgs run a Package Installation in a sandbox before production?
Q3. After a Package Installation completes, how do the package's components appear in the target org?
Discussion
Loading discussion…