Managed package and namespace prefix
A managed package is a bundle of Salesforce metadata distributed to other orgs and upgraded by its publisher. Its namespace prefix is a unique identifier of 1 to 15 alphanumeric characters that Salesforce adds to the API name of every packaged component, such as acme__Invoice__c, so it cannot collide with the subscriber's own customisation.
How the namespace works
In second-generation packaging, the namespace is assigned to a managed package when it is created and cannot be changed afterwards. Several managed packages can share one namespace, but a single package cannot belong to more than one. In the installing org, the prefix is how you tell a packaged field, object or class from one built locally.
Salesforce positions managed packages for ISV partners who distribute to many customers; for a company packaging its own metadata, unlocked packages are the recommended tool.
What a subscriber can see and change
The code in an Apex class, trigger, Visualforce or Lightning component that is part of a managed package is obfuscated and cannot be viewed in the installing org, except for methods declared global. By contrast, the details of custom objects, custom links, reports and other installed items remain visible to the subscriber, and the data of a protected custom setting is hidden.
Manageability rules decide, component type by component type, whether the publisher's upgrades update a component, whether the subscriber can delete it, whether the publisher can remove it, and whether it has intellectual-property protection that hides its metadata.
Why it matters when you inherit an org
Namespaced components can make up a large part of an org's metadata while being out of your control: you can depend on them, but not read or change their code. Separating what the org owns from what installed packages provide is usually the first step of understanding it.
How aprity helps
aprity reads the org's metadata read-only and computes its dependency graph, so the components your own automation depends on are visible whatever their origin. Objects, fields, automations and business rules are documented in business language, each rule linked to the component it was read from.
Related terms
- Salesforce Dependency API — The Tooling API object MetadataComponentDependency, which returns which metadata components in an org reference which others.
- Salesforce technical debt — The accumulated cost of past configuration and code shortcuts in a Salesforce org that makes every future change slower and riskier.
- Apex trigger — Apex code that runs automatically before or after records of an object are inserted, updated, deleted or undeleted.
Sources
Official Salesforce documentation this entry was checked against. Platform behaviour changes between releases; the linked page is the reference.