Installing AppExchange Packages

Why Installing AppExchange Packages Matters

The Environment Management and Deployment domain of the Salesforce Advanced Administrator exam tests your ability to move functionality into an org safely, and AppExchange packages are one of the most common ways administrators extend Salesforce without writing code. Instead of building a document-generation tool, a survey engine, or a data-quality utility from scratch, an admin can install a pre-built solution in minutes. Because installed packages can introduce new objects, Apex code, permission requirements, and licensing obligations, the exam expects you to understand not just how to click Install, but how packages behave, what they consume, how they are secured, and how they fit into a sandbox-to-production deployment strategy. Expect scenario-based questions where you must choose the right package type, the right installation option, or the correct post-installation step.

What Is the AppExchange and What Is a Package?

The AppExchange is Salesforce's enterprise marketplace where partners (ISVs) and Salesforce itself publish apps, components, flow solutions, Bolt solutions, and consultants. A package is a container of metadata components (objects, fields, Apex classes, Lightning components, flows, reports, permission sets, and so on) that can be distributed from one org and installed into another.

The key distinction you must master is managed versus unmanaged packages:

Managed Packages
- Created by partners in a Developer Edition org with a registered namespace prefix (for example, dsfs__ for DocuSign). Every component is prefixed with the namespace, so they never collide with your own metadata.
- Upgradable: the publisher can release new versions, and subscribers can upgrade in place without losing data. Publishers can also perform push upgrades automatically.
- Intellectual property is protected: Apex code is hidden and most components are locked, so you cannot edit them (you can often add your own fields to packaged objects and create your own layouts, however).
- Can be licensed and tracked through the License Management App; many require a paid subscription.
- Components from managed packages that have passed the AppExchange Security Review generally do not count against your org limits for custom objects, custom tabs, and custom apps. This is a classic exam fact.
- Can be uninstalled as a single unit, which removes all packaged components.

Unmanaged Packages
- Essentially a template or starting point. Once installed, the components become part of your org as if you had built them yourself, and you can freely edit them.
- Not upgradable: there is no link back to the source, so the publisher cannot push fixes.
- No namespace prefix, so component API names could conflict with existing metadata.
- Components do count against your org limits.
- Often used for sample code, open-source tools, and Salesforce Labs apps.

You may also see references to second-generation (2GP) managed packages and unlocked packages, which are developer-centric packaging models built with Salesforce DX. For the Advanced Administrator exam, the managed versus unmanaged distinction is the critical knowledge, but recognize that unlocked packages behave like unmanaged packages in that components are editable, while still supporting version tracking.

Trust and Vetting: The Security Review

Every app listed publicly on the AppExchange must pass the Salesforce Security Review, a rigorous assessment of the code and architecture for vulnerabilities. Listings also show customer reviews, pricing model (free, paid, or discount), supported editions, Lightning readiness, and whether a Test Drive (read-only demo org) or free trial is available. Admins should evaluate these before installing. Apps distributed by a direct installation link rather than a public listing have not necessarily been security reviewed, and the exam may frame this as a risk consideration.

How the Installation Process Works

Follow this sequence and you will be able to answer almost any process question:

1. Prerequisites and Permissions
- The installing user needs the Download AppExchange Packages permission and Customize Application (System Administrators have these by default).
- Verify that your org edition is supported and that you have available storage and licenses.
- Best practice: install in a sandbox first, test, and only then install in production.

2. Locate the Package
- Browse or search the AppExchange, open the listing, and click Get It Now. Alternatively, a publisher may give you a direct installation URL (install link), or you can install from Setup > Installed Packages if a package is already present and an upgrade is available.

3. Log In and Choose a Destination
- You are prompted to log in with your Salesforce credentials and then choose Install in Production or Install in Sandbox. A sandbox install is strongly recommended for any package that is new to your org.
- Confirm the installation details and agree to the terms and conditions.

4. Choose Who Gets Access
This is heavily tested. The installation wizard offers three security options:
- Install for Admins Only: only users with the System Administrator profile (and users with Customize Application) can access the package components. This is the default and the safest choice for initial evaluation.
- Install for All Users: all internal custom profiles receive Full Access to the package components. Standard profiles other than System Administrator are not modified.
- Install for Specific Profiles: you individually set the access level (Full Access or No Access) for each profile. Useful when only certain teams should see the app.
Remember that these options set profile-level access. Many modern packages rely on permission sets delivered inside the package, which you must assign separately after installation.

5. Approve Third-Party Access
- If the package communicates with external endpoints (web services, APIs), you will be asked to approve third-party access, which creates the required Remote Site Settings. Declining this can break the app's functionality.

6. Installation Runs
- Small packages install almost immediately. Large packages run in the background and you receive an email notification when the installation completes. During this time the package shows as installing in Setup.
- If the package contains Apex, Salesforce may run tests; if a component conflicts with existing metadata (unmanaged packages) or a dependency is missing, installation fails and you receive an error message describing the issue.

7. Post-Installation Configuration
Installation is rarely the finish line. Typical follow-up tasks include:
- Reviewing the Installed Packages page (Setup > Installed Packages) to see package name, publisher, version number, namespace, install date, and component list.
- Clicking Manage Licenses to assign package licenses to specific users when the package is license-restricted. If a user lacks a license, they cannot access the packaged objects or tabs even if their profile permits it.
- Assigning packaged permission sets or permission set groups.
- Adding packaged tabs to apps, adjusting page layouts, and setting field-level security.
- Configuring custom settings or custom metadata types that control the app's behavior.
- Reviewing sharing settings for new custom objects, which default to the OWD you choose during or after install.
- Following the publisher's post-install instructions or configuration guide. Some packages include a post-install Apex script that runs automatically.

Managing, Upgrading, and Uninstalling

- Upgrades: for managed packages, go to the listing or install link for the new version, or respond to a notification. Upgrades preserve data and your customizations to packaged objects. Publishers may also push upgrades, which can be scheduled during maintenance windows; admins can see push upgrade history on the Installed Packages page.
- Package Versions: the Installed Packages page shows the current version. Releases use a major.minor.patch scheme.
- Uninstalling: from Setup > Installed Packages, click Uninstall. You must first remove any dependencies you created (for example, your own custom fields that reference packaged objects, or reports built on packaged objects). Salesforce lets you choose to save a copy of the package data; the exported data ZIP file is available for 48 hours on the Installed Packages page before it is deleted. After uninstalling, all packaged components and their data are removed.
- Sandbox Refreshes: when you refresh a sandbox from production, installed packages are copied along with the metadata, so the sandbox mirrors production's package state.

Packages and Deployment Tools

A frequently tested nuance: you cannot deploy a managed package itself through a change set. If production needs the package, it must be installed directly in production. However, once the package is installed in both source and target orgs, you can include your own customizations that reference packaged components (such as a custom field you added to a packaged object, or a flow using a packaged Apex action) in a change set. The change set will fail if the target org does not have the package, or has an older version lacking the referenced components. The same principle applies to the Metadata API and Salesforce CLI deployments.

Common Pitfalls and Considerations

- Installing directly to production without sandbox testing.
- Forgetting to assign licenses or permission sets, leading to users who see nothing after the admin confirms the install.
- Choosing Install for All Users when the app handles sensitive data, inadvertently exposing it.
- Unmanaged package name collisions with existing metadata.
- Exceeding storage or custom object limits with unmanaged content.
- Removing a package without exporting its data first.
- Ignoring that an unmanaged package cannot be upgraded, so bug fixes require manual rework or reinstallation.

Exam Tips: Answering Questions on Installing AppExchange Packages

Tip 1: Decode the package type from the scenario. If the question mentions upgrades, hidden code, a namespace prefix, licensing, or protected intellectual property, the answer involves a managed package. If it mentions editing the components freely, a template, sample code, or Salesforce Labs, it is unmanaged.

Tip 2: Know the three installation access options cold. Install for Admins Only (default, most restrictive), Install for All Users (all custom profiles get Full Access), Install for Specific Profiles (granular). When a scenario emphasizes evaluation or caution, choose Admins Only; when it emphasizes a specific department, choose Specific Profiles.

Tip 3: Users cannot see the app after install? Think licenses and permission sets. The most common correct answer to this scenario is to assign package licenses via Manage Licenses and assign the packaged permission set, not to reinstall the package or change the OWD.

Tip 4: Sandbox first is almost always the best practice answer. Any option that proposes installing straight into production for a new, untested package is a distractor.

Tip 5: Remember what change sets cannot do. A change set cannot carry an installed package to another org. The package must be installed separately in each org, and the same or newer version must exist in the target before deploying customizations that depend on it.

Tip 6: Org limits. Components in managed packages from the AppExchange that passed Security Review do not count against custom object, tab, and app limits. Unmanaged components do count. If a question asks how to add functionality without consuming custom object limits, the managed AppExchange package is the answer.

Tip 7: Uninstall details. Dependencies you created must be removed first, you can export package data during uninstall, and the export file is retained for 48 hours.

Tip 8: Third-party access prompts mean Remote Site Settings. If an app that integrates with an external service does not work after installation, the likely cause is that third-party access was declined or a remote site setting is missing.

Tip 9: Watch for the Security Review as a trust indicator. When asked how an administrator can confirm an app is safe, the answer references the Salesforce Security Review, customer reviews, and testing in a sandbox or Test Drive, not simply trusting the publisher.

Tip 10: Eliminate answers that over-engineer. The exam rewards the simplest declarative, supported approach. If a managed package solves the requirement, choices involving custom Apex development, manual rebuilding of objects, or data loader workarounds are usually wrong.

Practice Scenario

A company installed a managed document-generation package in production. The administrator can use it, but sales reps report they cannot see the new tab or generate documents. What should the administrator do first?

Walk through it: the package is installed (so no reinstall is needed), the admin can use it (so the install succeeded), and only non-admins are blocked. This points directly to access: check Manage Licenses to assign licenses to the sales reps and assign the package's permission set or adjust profile access. Options such as refreshing a sandbox, deploying via change set, or uninstalling and reinstalling for All Users are distractors.

Summary

Installing AppExchange packages is about more than clicking Get It Now. For the exam, master the managed versus unmanaged distinction, the three installation access choices, licensing and permission set assignment, the sandbox-first deployment rhythm, the limits of change sets with packages, and the uninstall and data export rules. With those concepts firmly in place, you can confidently reason through any package-related scenario the Advanced Administrator exam presents.