Managed Packages and the AppExchange

This is Part 35 of the Salesforce series. In the previous posts, we covered the Salesforce Mobile App and offline access capabilities. Now we turn our attention to one of the most practical topics for any Salesforce administrator: Managed Packages and the AppExchange. No matter how powerful Salesforce is out of the box, there will always be requirements that are better served by purpose-built solutions from third-party vendors. The AppExchange is where you find those solutions, and managed packages are the mechanism through which they are delivered. Understanding how to evaluate, install, configure, upgrade, and remove packages is a critical skill for every Salesforce admin.

What is a Package in Salesforce?

A package in Salesforce is a container that groups together a set of related metadata components — custom objects, fields, Apex classes, Visualforce pages, Lightning components, flows, permission sets, and more — so they can be distributed and installed in other Salesforce orgs. Packages are the primary vehicle for moving functionality between orgs in a structured, repeatable way.

Think of a package like a software installer. Instead of manually recreating dozens of components in a target org, a developer bundles them into a package, and an admin installs that package with a few clicks. The components arrive pre-wired, with their relationships and dependencies intact.

Salesforce supports two fundamental package types: unmanaged packages and managed packages. There is also a newer concept called unlocked packages that falls somewhere in between. Understanding the differences is essential before you start installing anything.

Unmanaged Packages

An unmanaged package is essentially a one-time snapshot of a set of components. When you install an unmanaged package in your org, the components become fully editable — they are no longer linked to the source org or the original developer in any way.

Characteristics of Unmanaged Packages

• Full editability — once installed, every component can be modified, renamed, or deleted. There is no intellectual property protection.
• No upgrade path — the developer cannot push updates to your org. If a new version is released, you would need to install it manually and reconcile changes yourself.
• No namespace prefix — components installed from an unmanaged package do not carry a namespace. They blend into your org as if you had built them yourself.
• No support tracking — Salesforce does not track the relationship between the installed components and the original package after installation.
• Free distribution — unmanaged packages are always free. They are commonly used for templates, sample code, open-source accelerators, and training materials.

When Unmanaged Packages Make Sense

Limitations of Unmanaged Packages

• Cannot be upgraded in place. Each new version is a separate install.
• Cannot enforce licensing or usage tracking.
• Source code (Apex, Visualforce) is fully visible and editable.
• No way to obfuscate or protect proprietary logic.
• Cannot be listed on the AppExchange as a paid product.

Managed Packages

A managed package is a more sophisticated distribution mechanism designed for commercial software distribution. Managed packages are created by Independent Software Vendors (ISVs) and are the backbone of the Salesforce partner ecosystem. When you hear about apps on the AppExchange, the vast majority are delivered as managed packages.

Characteristics of Managed Packages

• Namespace prefix — every managed package has a unique namespace (e.g., nforce, copado, conga). All components inside the package carry this prefix, which prevents naming collisions with your org’s custom components.
• Intellectual property protection — Apex code in a managed package is obfuscated. Subscribers cannot view or edit the source code. Visualforce markup is also hidden. Lightning Web Components can be partially obscured.
• Upgrade path — the ISV can release new versions, and administrators can upgrade the package in place. Upgrades are designed to be non-destructive, preserving your data and customizations.
• License management — managed packages support license keys and seat-based licensing through the License Management App (LMA) and the Subscriber Management App.
• AppExchange eligible — only managed packages (that have passed security review) can be listed as paid products on the AppExchange.
• Dependency tracking — Salesforce tracks which components belong to the package, making it clear what was installed versus what you built.

Namespace Prefix Deep Dive

The namespace prefix is one of the most important concepts in managed packages. When an ISV creates a managed package with the namespace acme, every custom object, field, class, and component in that package gets prefixed:

• Custom object: acme__Invoice__c
• Custom field: acme__Total_Amount__c
• Apex class: acme.InvoiceController
• Lightning component: acme:invoiceList

This means you can have your own Invoice__c object alongside the ISV’s acme__Invoice__c without any conflict. The namespace acts as a container that isolates the package’s components from yours.

What Can and Cannot Be Modified

Managed vs Unmanaged: Side-by-Side Comparison

Unlocked Packages (Second-Generation Packaging)

Salesforce introduced unlocked packages as part of its Second-Generation Packaging (2GP) initiative. These are designed primarily for enterprise teams managing their own development lifecycle, rather than for ISV distribution.

Key Differences from Managed Packages

• Source-trackable — designed to work with Salesforce DX and source-driven development.
• Editable — components can be modified after installation (like unmanaged), but you still get versioning and upgrade paths.
• No code obfuscation — Apex code is visible and editable.
• Org-dependent or independent — can be built with or without dependencies on the target org.
• Namespace optional — you can assign a namespace, but it is not required.

When to Use Unlocked Packages

Unlocked packages are best suited for internal enterprise development teams that want the discipline of packaging (versioning, dependency management, repeatable deployments) without the restrictions of managed packages. They are not typically used for AppExchange distribution.

What is the AppExchange?

The AppExchange is Salesforce’s official marketplace for business applications. Launched in 2006, it was one of the first enterprise cloud marketplaces and remains the largest ecosystem of its kind. As of 2025, the AppExchange hosts over 7,000 listings — apps, components, consultants, and solutions — spanning virtually every business function.

Types of Listings on the AppExchange

The AppExchange is not limited to managed packages. It hosts several types of listings:

Free vs Paid Listings

Many AppExchange listings are free. These include open-source tools, community-contributed components, Salesforce Labs projects (built by Salesforce employees in their spare time), and freemium apps that offer a basic tier at no cost. Paid listings range from a few dollars per user per month to enterprise-level pricing that can run into thousands per month.

The Security Review Process

Before any managed package can be listed on the AppExchange, it must pass the Salesforce Security Review. This is a rigorous evaluation conducted by Salesforce’s security team (and sometimes by contracted third-party firms) to ensure that the package does not introduce vulnerabilities.

The security review covers:

• SOQL injection — ensuring dynamic queries are properly escaped.
• Cross-site scripting (XSS) — validating that user input is sanitized in Visualforce and Lightning components.
• CRUD and FLS enforcement — verifying that the package respects the org’s object-level and field-level security settings.
• Sharing model compliance — ensuring the package does not bypass the org’s sharing rules.
• Data exposure — checking that sensitive data is not logged, exposed in URLs, or transmitted insecurely.
• Remote callouts — validating that external API calls use HTTPS and do not transmit data to unauthorized endpoints.
• Apex security best practices — ensuring with sharing is used appropriately, SOQL is bulkified, and governor limits are respected.
• Lightning Locker Service compliance — ensuring components operate within their security sandbox.

The security review can take several weeks and often requires multiple rounds of revision. ISVs must re-certify their packages annually or whenever they release a major update.

Important: Passing the security review does not mean a package is bug-free or that it will not cause issues in your org. It means the package has met a baseline security standard. You should still perform your own testing.

How to Evaluate a Package Before Installation

Installing a managed package in your production org is not a decision to take lightly. Once installed, a package can consume governor limits, add triggers to your objects, modify page layouts, and introduce dependencies that complicate future changes. Here is a structured evaluation framework.

1. Define Your Requirements

Before you even open the AppExchange, document what you need:

• What specific business problem are you trying to solve?
• What functionality is required versus nice to have?
• What objects and processes will the solution touch?
• What is your budget (per user per month, flat fee, or free)?
• What is your timeline for implementation?
• Do you need the solution to integrate with other tools?

2. Search and Shortlist

Go to appexchange.salesforce.com and search for solutions. Use filters to narrow results:

• Category — Sales, Service, Marketing, Analytics, etc.
• Price — Free, Paid, or Free Trial.
• Rating — Minimum star rating.
• Edition compatibility — Ensure the package works with your Salesforce edition (Enterprise, Professional, etc.).
• Industry — Some listings target specific industries.

Create a shortlist of three to five candidates.

3. Review Ratings and Reviews

The AppExchange displays star ratings and written reviews from other customers. Pay attention to:

• Overall rating — A high rating with many reviews is a strong signal.
• Recent reviews — Focus on reviews from the last six to twelve months. Older reviews may not reflect the current state of the product.
• Negative reviews — Read these carefully. Look for patterns: slow support, buggy upgrades, poor documentation.
• Review count — A package with five reviews and a five-star rating is less reliable than one with 500 reviews and a 4.5-star rating.

4. Check the Publisher

• Who is the ISV? Research their company. How long have they been in business? Are they a Salesforce partner?
• Salesforce security review status — Look for the “Salesforce Security Reviewed” badge on the listing.
• Support model — What support is included? Is there a dedicated support portal? What are the SLAs?
• Documentation — Is there comprehensive admin and user documentation? Are there setup guides and release notes?

5. Evaluate Technical Fit

• Edition requirements — Some packages require Enterprise Edition or above.
• License requirements — Does the package require specific Salesforce licenses (e.g., Platform, Service Cloud)?
• API version compatibility — Is the package built on a recent API version?
• Dependencies — Does the package depend on other packages or features (e.g., Person Accounts, Multi-Currency)?
• Governor limit impact — Packages that add triggers, flows, and callouts to your objects will consume governor limits from the same pool as your code.

6. Test in a Sandbox

Never install a package directly in production without testing it first. Always install in a sandbox (preferably a full or partial sandbox that mirrors production) and test:

• Installation process
• Basic functionality against your requirements
• Interaction with your existing customizations (triggers, flows, validation rules)
• Impact on page load times
• User experience and adoption concerns
• Data migration or setup requirements

7. Review Pricing and Contracts

• Per-user pricing — Some packages charge per Salesforce user, others per “active user” of the package.
• Tiered pricing — Many packages offer multiple tiers (Basic, Professional, Enterprise).
• Annual vs monthly billing — Annual contracts are typically discounted.
• Free trial — Take advantage of trial periods before committing.
• Contract length — Watch for multi-year lock-ins.
• Overage fees — Some packages charge extra if you exceed certain usage thresholds (API calls, records processed, etc.).

How to Install a Managed Package from the AppExchange

Once you have evaluated a package and decided to proceed, the installation process is straightforward. Here is a step-by-step walkthrough.

Step 1: Navigate to the AppExchange Listing

1. Go to appexchange.salesforce.com.
2. Find the package you want to install.
3. Click Get It Now.

Step 2: Log In to Salesforce

1. If you are not already logged in, Salesforce will prompt you to authenticate.
2. Log in with the credentials for the org where you want to install the package. Use a sandbox org for initial testing.
3. Make sure you log in as an administrator with the Install Packages permission.

Step 3: Choose the Installation Environment

You will be asked to choose:

• Install in production — only do this after you have tested in a sandbox.
• Install in sandbox — recommended for initial testing and evaluation.

Step 4: Confirm Terms and Conditions

• Review the package’s terms of service and privacy policy.
• Some packages require you to grant third-party access (for external API integrations).
• Check or uncheck the box depending on your organization’s policies.

Step 5: Select Security Level

This is one of the most important decisions during installation. You have three options:

Best Practice: Always start with “Install for Admins Only.” You can expand access later through profiles and permission sets after you have configured and tested the package.

Step 6: Approve Third-Party Access (If Required)

Some packages need to communicate with external services (e.g., a document generation tool that calls an external rendering API). If the package includes remote site settings or named credentials for external endpoints, you will be prompted to approve this access.

Review the list of external domains carefully. If you do not recognize a domain or are unsure why the package needs it, contact the ISV before proceeding.

Step 7: Install

1. Click Install.
2. For simple packages, installation completes in a few minutes.
3. For larger packages with many components, Salesforce may process the installation in the background and send you an email when it is done.
4. You will see a confirmation page when the installation is complete.

Step 8: Verify Installation

After installation, verify that everything arrived correctly:

1. Go to Setup > Installed Packages — you should see the new package listed with its version number.
2. Check for the package’s tabs under the App Launcher.
3. Look for new custom objects, fields, and components associated with the namespace.
4. Review any post-install instructions provided by the ISV.

Post-Installation Configuration

Installing a managed package is just the first step. Most packages require additional configuration before they are ready for your users.

1. Assign Licenses

Many managed packages use seat-based licensing. After installation:

1. Go to Setup > Installed Packages.
2. Click Manage Licenses next to the package.
3. Add individual users or click Add All Users (if your license count allows).

If a user does not have a license assigned, they will not be able to access the package’s custom tabs and objects, even if their profile has the correct permissions.

2. Configure Permission Sets

Most well-designed packages include one or more permission sets (e.g., “Acme Admin” and “Acme User”). Assign these to your users based on their roles:

1. Go to Setup > Permission Sets.
2. Find the permission sets with the package’s namespace prefix.
3. Click Manage Assignments and add the appropriate users.

3. Update Page Layouts

Many packages include custom components or related lists that should be added to your page layouts:

• Add the package’s related lists to relevant page layouts (e.g., if the package adds a child object to Opportunity, add the related list to the Opportunity page layout).
• Add any package-provided Lightning components to your Lightning record pages using the Lightning App Builder.
• Consider creating new page layouts specifically for users who interact heavily with the package.

4. Configure Custom Settings and Custom Metadata

Packages frequently use custom settings or custom metadata types for configuration:

• Look for a Settings or Configuration tab provided by the package.
• Set API keys, default values, feature toggles, and org-specific parameters.
• Some packages provide a setup wizard that walks you through initial configuration.

5. Set Up Integrations

If the package integrates with external systems:

• Configure Named Credentials with the appropriate authentication details.
• Set up Connected Apps if OAuth is required.
• Verify Remote Site Settings are correctly configured.
• Test the integration in your sandbox before enabling it in production.

6. Data Migration

Some packages require initial data to function:

• Seed lookup tables or configuration records.
• Map existing data to the package’s custom objects if migrating from a manual process or another tool.
• Use Data Loader or the package’s built-in import tools for bulk data loading.

7. Test with End Users

Before rolling out to the full organization:

1. Select a small pilot group.
2. Assign them licenses and permissions.
3. Have them perform their daily tasks using the new package.
4. Collect feedback on usability, performance, and any issues.
5. Iterate on configuration based on the feedback.

Upgrading Managed Packages

One of the key advantages of managed packages is the ability to upgrade in place. ISVs regularly release new versions that include bug fixes, performance improvements, and new features.

How Upgrades Work

1. The ISV publishes a new version of the package.
2. You receive a notification (email or in-app) that an upgrade is available.
3. You navigate to the installation URL provided by the ISV or find the update on the AppExchange listing.
4. The upgrade process is similar to the initial installation — you choose the environment, security level, and approve any new third-party access.
5. Salesforce applies the upgrade, adding new components and updating existing ones without removing your customizations.

What Happens During an Upgrade

Upgrade Best Practices

• Always upgrade in a sandbox first. Test thoroughly before applying the upgrade to production.
• Read the release notes. ISVs typically publish release notes for each version. Look for breaking changes, deprecated features, and new permissions required.
• Back up your data. Export data from the package’s custom objects before upgrading, especially for major version upgrades.
• Check compatibility. If you have written Apex code or built flows that reference the package’s components, verify they still work after the upgrade.
• Coordinate with the ISV. For major upgrades, contact the ISV’s support team for guidance on the upgrade path.

Major vs Patch Versions

Salesforce managed packages follow a versioning scheme:

• Major version (e.g., 2.0 to 3.0) — can include breaking changes and new components. Requires explicit admin action to install.
• Minor version (e.g., 3.0 to 3.1) — typically adds features without breaking changes. Requires explicit admin action.
• Patch version (e.g., 3.1 to 3.1.1) — bug fixes only. ISVs can push patch versions automatically to subscriber orgs (if configured to allow it).

Uninstalling Managed Packages

Sometimes a package no longer serves your needs, or you are migrating to a different solution. Uninstalling a managed package removes all of its components from your org.

Before You Uninstall

1. Understand the data impact. Uninstalling a managed package permanently deletes all data stored in the package’s custom objects and custom fields. This data cannot be recovered from the Recycle Bin.
2. Export your data. Before uninstalling, export all data from the package’s custom objects using Data Loader, reports, or the package’s built-in export tools.
3. Check for dependencies. If you have built custom components (flows, Apex classes, validation rules, reports) that reference the package’s objects or fields, you must remove those references before you can uninstall. Salesforce will not allow you to uninstall a package if there are dependencies outside the package.
4. Review integrations. If the package is integrated with external systems, disable those integrations first.

How to Uninstall

1. Go to Setup > Installed Packages.
2. Click Uninstall next to the package you want to remove.
3. Salesforce will display a list of all components that will be removed. Review this list carefully.
4. You will be asked whether you want to save a copy of the package’s data. Select Yes — Salesforce will email you a CSV export of the data before deleting it.
5. Check the confirmation box and click Uninstall.
6. Uninstallation can take several minutes for large packages. You will receive an email when it is complete.

Common Uninstallation Errors

Popular Managed Packages on the AppExchange

The AppExchange ecosystem is vast. Here are some categories of widely-used packages that many Salesforce administrators encounter:

Document Generation

Packages that automate the creation of PDFs, Word documents, and proposals from Salesforce data. These tools pull data from records, apply templates, and generate professional documents without manual formatting.

E-Signature

Solutions that allow you to send documents for electronic signature directly from Salesforce records. They typically integrate with external signature platforms and update the Salesforce record when the document is signed.

Data Quality and Enrichment

Tools that help you deduplicate records, enrich contact and company data with third-party sources, and maintain data hygiene across your org.

DevOps and Release Management

Packages that provide version control, deployment automation, and release management for Salesforce metadata. These are popular with teams that manage complex orgs with multiple developers.

Project Management

Solutions that add project management capabilities — tasks, milestones, Gantt charts, resource allocation — directly inside Salesforce, connected to your CRM data.

CPQ (Configure, Price, Quote)

Tools that streamline the quoting process by allowing sales reps to configure complex products, apply pricing rules, and generate professional quotes.

Analytics and BI

Packages that extend Salesforce’s native reporting with advanced analytics, dashboards, and data visualization capabilities.

Communication and Telephony

CTI (Computer Telephony Integration) adapters that connect phone systems to Salesforce, enabling click-to-dial, screen pops, and automatic call logging.

Mass Email and Marketing

Tools that extend Salesforce’s native email capabilities with template builders, campaign management, tracking, and analytics.

Salesforce Labs

Salesforce Labs deserves special mention. These are free, unsupported apps and components built by Salesforce employees. They are available on the AppExchange and can be incredibly useful, but they come with important caveats:

• No official support — Salesforce Labs apps are provided “as is.” If something breaks, you are on your own (though the community is often helpful).
• May not be updated — some Labs apps are actively maintained, others have not been updated in years.
• Great for learning — many Labs apps demonstrate best practices for package development.
• Free forever — there are no licensing costs.

Popular Salesforce Labs apps include record cloning tools, mass update utilities, dashboard enhancers, and admin productivity tools.

Governor Limits and Package Considerations

One of the most important technical considerations when installing managed packages is their impact on governor limits.

Shared Limit Context

By default, managed package code (Apex triggers, flows, and classes) runs in the same transaction context as your org’s code. This means they share the same governor limits:

• 100 SOQL queries per synchronous transaction
• 150 DML statements per transaction
• 10 synchronous callouts per transaction
• 6 MB heap size

If your org already has triggers and flows on the Account object and you install a package that also fires triggers on Account, the combined total must stay within governor limits.

Certified Managed Packages

Packages that have passed the Salesforce security review and are listed on the AppExchange are considered “certified.” Certified managed packages get some governor limit benefits:

• Separate SOQL and DML limits — in some contexts, certified managed packages operate in their own limit context, meaning their SOQL queries do not count against your org’s 100-query limit.
• Higher API call allocation — certified packages may receive additional API call allocations.

However, this separation is not absolute. Certain limits (like total CPU time and callout limits) are still shared. Always test the combined behavior in a sandbox.

Best Practices for Limit Management

• Audit existing customizations before installing a package. Know your current governor limit consumption.
• Test package installation in a sandbox with realistic data volumes.
• Monitor debug logs after installation to identify any limit issues.
• Contact the ISV if you observe governor limit warnings — they may have configuration options to reduce limit consumption.

Security Considerations for Installed Packages

Beyond the Salesforce security review, there are additional security factors to consider.

Data Access

When you install a managed package, you are granting it access to your org’s data. The package’s Apex code runs with the permissions of the running user (if using with sharing) or with full system access (if using without sharing). Understand what data the package accesses and why.

External Callouts

If a package makes callouts to external servers, your data may be transmitted outside of Salesforce. Review the ISV’s privacy policy and data processing agreement. Ensure compliance with your organization’s data governance policies and any applicable regulations (GDPR, HIPAA, etc.).

Connected Apps

Some packages install Connected Apps that grant OAuth access to your org’s APIs. Review these Connected Apps in Setup and ensure you understand the scope of access being granted.

Permission Set Security

Review the permission sets included with the package. Some packages request broader permissions than strictly necessary. Understand what object and field access each permission set grants before assigning them to users.

Regular Audits

• Periodically review installed packages in Setup > Installed Packages.
• Check which users have licenses for each package.
• Review the Connected Apps and Remote Site Settings associated with each package.
• Monitor the package’s version — stay current to receive security patches.

Managing Multiple Packages

As your Salesforce org matures, you may find yourself managing a dozen or more installed packages. This introduces complexity that requires careful management.

Package Inventory

Maintain a spreadsheet or internal wiki that tracks:

• Package name and namespace
• ISV name and support contact
• License count and assigned users
• Version currently installed
• Renewal date and cost
• Purpose and business owner
• Dependencies on other packages

Interaction Between Packages

Multiple packages can interact in unexpected ways:

• Trigger order — if two packages have triggers on the same object, the execution order is not guaranteed. This can cause logic conflicts.
• Field conflicts — two packages might try to update the same field, leading to race conditions.
• Layout conflicts — multiple packages may want to add components to the same Lightning record page.
• Limit stacking — each package consumes governor limits, and the combined effect can push you over limits.

Conflict Resolution Strategies

1. Test packages together — install multiple packages in a sandbox and test their interactions before deploying to production.
2. Use custom triggers with a framework — implement a trigger framework in your org that controls execution order, including package triggers where possible.
3. Contact ISVs — if two packages conflict, reach out to both ISVs. They may have known compatibility issues and workarounds.
4. Document dependencies — keep a dependency map showing how packages relate to your custom components and to each other.

AppExchange for Consultants and Components

The AppExchange is not only for managed packages. Two other important listing types are consultants and Lightning components.

Finding Consulting Partners

If you need help implementing Salesforce or a specific package:

1. Go to the AppExchange and click Consultants.
2. Filter by location, industry, expertise, and Salesforce product.
3. Review ratings, customer reviews, and the consultant’s certified team size.
4. Request quotes from multiple consultants before making a decision.

Lightning Components

Some AppExchange listings are standalone Lightning components rather than full applications:

• A chart component for dashboards
• A Kanban board for record management
• A signature capture component for mobile
• A calendar component with drag-and-drop scheduling

These are lighter-weight than full managed packages and can be dropped into your Lightning pages via the App Builder.

Package Development Considerations for Admins

While admins do not typically build managed packages, understanding the development side helps you evaluate and work with ISV products more effectively.

ISV Partner Program

ISVs that build managed packages typically participate in the Salesforce ISV Partner Program, which provides:

• Free development orgs — Partner Developer Edition orgs with higher limits than standard Developer Edition.
• Environment Hub — tools for managing multiple development and test orgs.
• Security review process — structured process for getting packages listed on the AppExchange.
• License Management App (LMA) — tools for managing subscriber licenses.
• Revenue sharing — Salesforce takes a percentage of AppExchange sales (varies by agreement).

How ISVs Build Packages

1. Development — ISVs build their solution in a Developer Edition org or scratch orgs using Salesforce DX.
2. Packaging — components are added to a managed package and assigned a namespace.
3. Testing — the package is installed in test orgs across multiple Salesforce editions to verify compatibility.
4. Security Review — the package is submitted to Salesforce for security review.
5. Listing — once approved, the ISV creates an AppExchange listing with descriptions, screenshots, and pricing.
6. Distribution — customers install the package from the AppExchange and the ISV manages licenses through the LMA.
7. Maintenance — the ISV releases updates, patches bugs, and responds to security vulnerabilities.

Common Pitfalls and How to Avoid Them

Pitfall 1: Installing in Production Without Testing

Problem: You install a package directly in production, and it breaks existing functionality.

Solution: Always install in a sandbox first. Test against your specific customizations and data volumes. Only move to production after thorough validation.

Pitfall 2: Ignoring License Costs at Scale

Problem: A package costs five dollars per user per month and seems reasonable. But you have 500 users, and the annual cost is thirty thousand dollars.

Solution: Calculate the total cost of ownership before committing. Factor in implementation costs, training, and ongoing administration.

Pitfall 3: Not Planning for Uninstallation

Problem: You build extensive customizations on top of a managed package (custom fields on packaged objects, flows referencing packaged components). When you later decide to uninstall, removing all dependencies is a massive effort.

Solution: Minimize dependencies on packaged components. Use wrapper objects or intermediate fields where possible so that your customizations are not tightly coupled to the package.

Pitfall 4: Skipping Release Notes During Upgrades

Problem: You upgrade a package and discover that a feature you relied on has been deprecated or changed.

Solution: Always read release notes before upgrading. Test in a sandbox. Have a rollback plan (though Salesforce does not support rolling back package upgrades, you can contact the ISV).

Pitfall 5: Ignoring Governor Limits

Problem: After installing a package, you start seeing limit errors in production.

Solution: Monitor governor limit consumption before and after installation. Use debug logs and the Apex Governor Limit monitoring features in Setup.

Pitfall 6: Over-Relying on Unsupported Packages

Problem: You build critical business processes around a Salesforce Labs app or an abandoned package that is no longer maintained.

Solution: For critical processes, use only actively maintained, commercially supported packages. Check the package’s update history and ISV responsiveness before relying on it.

Best Practices Summary

1. Always test in a sandbox before installing any package in production.
2. Install for Admins Only initially, then expand access after configuration and testing.
3. Read reviews and check ratings on the AppExchange — focus on recent feedback.
4. Verify the security review badge — never install a package that has not passed security review in a production org.
5. Understand the pricing model — calculate total cost at your org’s scale.
6. Document every installed package — maintain an inventory with version, cost, owner, and renewal date.
7. Assign licenses deliberately — do not give every user a license if only a subset needs access.
8. Monitor governor limits — test combined limit consumption in a sandbox.
9. Stay current on upgrades — apply patches and minor updates promptly for security fixes.
10. Plan for the exit — before installing, consider what uninstallation would look like. Minimize tight coupling.
11. Review ISV support — understand the SLA and support channels before you need them.
12. Audit regularly — review installed packages quarterly. Remove packages that are no longer in use.

Hands-On Exercise: Evaluate and Install an AppExchange Package

Let us walk through a practical exercise to reinforce the concepts covered in this post.

Scenario

Your sales team has requested a tool to mass-update records directly from list views. Rather than building a custom solution, you want to evaluate whether an existing AppExchange package can meet this need.

Step 1: Define Requirements

• Ability to mass-update fields on multiple records from a list view
• Should work with standard and custom objects
• Must support Salesforce Lightning Experience
• Budget: free or under ten dollars per user per month
• Must have passed Salesforce security review

Step 2: Search the AppExchange

1. Go to appexchange.salesforce.com
2. Search for “mass update” or “inline editing”
3. Filter by: Lightning Ready, Free or Paid
4. Sort by rating

Step 3: Shortlist and Compare

Create a comparison matrix:

Step 4: Install in Sandbox

1. Select the best candidate from your shortlist
2. Click Get It Now on the AppExchange
3. Choose Install in Sandbox
4. Select Install for Admins Only
5. Approve any third-party access requests
6. Wait for installation to complete

Step 5: Configure and Test

1. Go to Setup > Installed Packages and verify the package is listed
2. Assign yourself a license if required
3. Assign the admin permission set
4. Navigate to a list view and test the mass update functionality
5. Test with both standard objects (Accounts, Contacts) and a custom object
6. Verify that field-level security is respected (restricted fields should not be editable)
7. Check debug logs for any governor limit concerns

Step 6: Pilot with Users

1. Select two to three sales team members for a pilot
2. Assign them licenses and the user permission set
3. Ask them to use the tool for one week
4. Collect feedback on usability and any issues
5. Make configuration adjustments based on feedback

Step 7: Deploy to Production

1. If the pilot is successful, install the package in production
2. Start with Install for Admins Only
3. Configure settings to match your sandbox configuration
4. Assign licenses and permissions to the full sales team
5. Communicate the rollout with a brief training session or documentation

Expected Outcome

After completing this exercise, you will have hands-on experience with the full lifecycle of an AppExchange package: evaluation, installation, configuration, testing, and deployment. This process applies to any package, from simple utilities to complex enterprise solutions.

Key Takeaways

• Unmanaged packages are open, editable, and free — great for templates and samples, but they offer no upgrade path or IP protection.
• Managed packages are the foundation of the AppExchange ecosystem — they provide namespace isolation, IP protection, upgrade paths, and license management.
• Unlocked packages serve internal development teams that want packaging discipline without the restrictions of managed packages.
• The AppExchange is a rich marketplace with apps, components, consulting partners, and solutions for virtually every business need.
• The Salesforce Security Review is a critical quality gate, but it does not replace your own testing and evaluation.
• Installation is just the beginning — proper post-install configuration, license assignment, permission management, and testing are essential for a successful rollout.
• Upgrades should be treated like any other deployment — test in a sandbox, read release notes, and plan carefully.
• Uninstallation has consequences — data in packaged objects is permanently deleted, and you must remove all dependencies first.
• Governor limits are shared — packages consume the same limits as your org’s custom code, so test the combined behavior.
• Documentation and auditing — maintain an inventory of all installed packages and review them regularly.

This post covered everything you need to know about managed packages and the AppExchange as a Salesforce administrator. We walked through the differences between package types, the security review process, a structured evaluation framework, step-by-step installation and configuration, upgrade and uninstallation procedures, governor limit considerations, and best practices for managing a growing portfolio of packages. The AppExchange is one of the biggest advantages of the Salesforce platform — knowing how to leverage it effectively sets you apart as an admin.

In the next part of our Salesforce series, Part 36: Data Cloud and Agentforce for Admins, we will explore two of Salesforce’s newest and most transformative technologies — Data Cloud for unifying customer data across systems and Agentforce for building autonomous AI agents. These represent the cutting edge of the Salesforce platform and are rapidly becoming essential knowledge for modern administrators. Stay tuned!