Components Available in First-Generation Managed Packages | First-Generation Managed Packaging Developer Guide

Each metadata component that you include in a managed 1GP or 2GP package has certain rules that determine its behavior in a subscriber org. Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is created and installed.

Components

A component is one constituent part of a package. It defines an item, such as a custom object or a custom field. You can combine components in a package to produce powerful features or applications. In a managed package, some components can be upgraded while others can’t.

For details about components supported in first-generation and second-generation managed packages, see Components Available in Managed Packages in the Second-Generation Managed Packaging Developer Guide.

Attributes

An attribute is a field on a component, such as the name of an email template or the Allow Reports checkbox on a custom object. The attributes associated with a non-upgradeable component are editable by both the package developer and the subscriber. On an upgradeable component in a managed package, some attributes can be edited by the developer, some can be edited by the subscriber, and some can’t be edited by anyone.

Components Automatically Added to First-Generation Managed Packages
When adding components to your first-generation managed package, related components are automatically added. For example, if you add a Visualforce page to a package that references a custom controller, that Apex class is also added.
Protected Components in Managed Packages
Developers can mark certain components as protected. Protected components can’t be linked to or referenced by components created in a subscriber org. A developer can delete a protected component in a future release without worrying about failing installations. However, after a component is marked as unprotected and is released globally, the developer can’t delete it.
Set Up a Platform Cache Partition with Provider Free Capacity
Salesforce provides 3 MB of free Platform Cache capacity for security-reviewed managed packages. This is made available through a capacity type called Provider Free capacity and is automatically enabled in all Developer edition orgs.
Package Dependencies in First-Generation Managed Packages
Package dependencies are created when a component references another component, permission, or preference that is required for the component to be valid.
Metadata Access in Apex Code
Use the Metadata namespace in Apex to access metadata in your package.
Permission Sets and Profile Settings in Packages
Permission sets, permission set groups, and profile settings are all ways to grant permissions and other access settings to a package. Only use a profile setting if permission sets don’t support the specific access you need to grant. In all other instances, use permission sets or permission set groups.
Permission Set Groups
You can organize permission sets into groups and include them in first and second-generation managed packages. Permission set groups can be updated when you upgrade the package.
Custom Profile Settings
Create profiles to define how users access objects and data, and what they can do within your app. For example, profiles specify custom object permissions and the tab visibility for your app. When installing or upgrading your app, admins can associate your custom profiles with existing non-standard profiles. Permissions in your custom profile that are related to new components created as part of the install or upgrade are added to the existing profile. The security settings associated with standard objects and existing custom objects in an installer’s organization are unaffected.
Protecting Your Intellectual Property
The details of your custom objects, custom links, reports, and other installed items are revealed to installers so that they can check for malicious content. However, revealing an app’s components prevents developers from protecting some intellectual property.
Call Salesforce URLs Within a Package
The URLs that Salesforce serves for a target org vary based on the org type and configuration. To build packages that support all possible URL formats, use relative URLs whenever possible. If your package functionality requires a full URL, use the Apex DomainCreator class to get the corresponding hostname. This method allows your package to work in all orgs, regardless of the org type, My Domain settings, and whether enhanced domains are enabled.
Develop App Documentation
To help your subscribers make the most of your app, provide documentation about how to configure and customize your app.
API and Dynamic Apex Access in Packages
Apex Package components have access via dynamic Apex and the API to standard and custom objects in the organization where they’re installed.
Connected Apps
A connected app is a framework that enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. Connected apps use these protocols to authenticate, authorize, and provide single sign-on (SSO) for external apps. The external apps that are integrated with Salesforce can run on the customer success platform, other platforms, devices, or SaaS subscriptions. For example, when you log in to your Salesforce mobile app and see your data from your Salesforce org, you’re using a connected app.