First-Generation Managed Packaging Developer Guide

First-Generation Managed Packages
Why Switch to Second-Generation Managed Packaging?
Move to 2GP: Migrate Your Managed Packages with Ease
Register a Namespace for a First-Generation Managed Package
Create a First-Generation Managed Package Using a UI
Create a First-Generation Managed Package using Salesforce DX
Components Available in First-Generation Managed Packages
Behavior of Specific Metadata in First-Generation Managed Packages
Get Access to Agentforce in Your 1GP Packaging Org
Components Automatically Added to First-Generation Managed Packages
Protected Components in Managed Packages
Set Up a Platform Cache Partition with Provider Free Capacity
Package Dependencies in First-Generation Managed Packages
Metadata Access in Apex Code
Permission Sets and Profile Settings in Packages
Permission Set Groups
Custom Profile Settings
Protecting Your Intellectual Property
Call Salesforce URLs Within a Package
Develop App Documentation
API and Dynamic Apex Access in Packages
Manage API and Dynamic Apex Access in Packages
Configure Default Package Versions for API Calls
About the Partner WSDL
Generate an Enterprise WSDL with Managed Packages
Work with Services Outside of Salesforce
Connected Apps
Package and Test Your First-Generation Managed Package
Update Your First-Generation Managed Package
Publish Upgrades to First-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in First-Generation Managed Packages
AppExchange App Analytics for First-Generation Managed Packages
Developing and Distributing Unmanaged Packages
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Work with Services Outside of Salesforce

You might want to update your Salesforce data when changes occur in another service. Likewise, you might also want to update the data in a service outside of Salesforce based on changes to your Salesforce data. For example, you might want to send a mass email to more contacts and leads than Salesforce allows. You can use an external mail service that allows users to build a recipient list of names and email addresses using the contact and lead information in your Salesforce organization.

An app built on the Salesforce Platform can connect with a service outside of Salesforce in many ways. For example, you can:
  • create a custom link or custom formula field that passes information to an external service.
  • use the Platform APIs to transfer data in and out of Salesforce.
  • use an Apex class that contains a Web service method.

Don’t store usernames and passwords within any external service.

Warning

Provisioning a Service External to Salesforce

If your app links to an external service, users who install the app must be signed up to use the service. Provide access in one of two ways:
  • Access by all active users in an organization with no real need to identify an individual
  • Access on a per user basis where identification of the individual is important
The Salesforce service provides two globally unique IDs to support these options. The user ID identifies an individual and is unique across all organizations. User IDs are never reused. Likewise, the organization ID uniquely identifies the organization.

Avoid using email addresses, company names, and Salesforce usernames when providing access to an external service. Usernames can change over time and email addresses and company names can be duplicated.

If you’re providing access to an external service, we recommend the following:

  • Use Single Sign-On (SSO) techniques to identify new users when they use your service.
  • For each point of entry to your app, such as a custom link or web tab, include the user ID in the parameter string. Have your service examine the user ID to verify that the user ID belongs to a known user. Include a session ID in the parameter string so that your service can read back through the Lightning Platform API and validate that this user has an active session and is authenticated.
  • Offer the external service for any known users. For new users, display an alternative page to collect the required information.
  • Don’t store passwords for individual users. Besides the obvious security risks, many organizations reset passwords on a regular basis, which requires the user to update the password on your system as well. We recommend designing your external service to use the user ID and session ID to authenticate and identify users.
  • If your application requires asynchronous updates after a user session has expired, dedicate a distinct administrator user license for this.