Create the Managed Package

Create the managed package for external distribution or internal testing. Distribute the managed package so that customers can download it to install and use Interaction Service APIs. Before you create the package for external distribution, you can create a beta test version first to internally test and validate the package. If you don’t have any managed packages in your org, if you’re using a scratch org to test the managed package, or if you’re using an external client app for authentication, create a second-generation Bring Your Own Channel for CCaaS managed package. If you’ve developed apps in the org using first-generation managed packages or you’re using a connected app for authentication, create a first-generation Bring Your Own Channel for CCaaS managed package.

Create a second-generation managed package if you don’t have any managed packages in your org, if you’re using a scratch org to test the managed package, or if you’re using an external client app for authentication. We recommend that all new packages are created using second-generation managed packaging (2GP).

A standard Salesforce project has the following structure. This structure is created by default when you use the Salesforce CLI to generate a new Salesforce project.

Key components:

  • force-app/: Contains all source code and metadata for your Salesforce org.
  • sfdx-project.json: Defines project settings, package directories, and namespace.
  • config/: Optional directory for scratch org definitions and other configuration files.
  • .gitignore: Specifies files and directories to exclude from version control.

When working with Bring Your Own Channel packages, your project structure includes additional metadata types in the force-app/main/default/ directory:

  • conversationChannelDefinitions/: Channel definitions for contact center integration. Always required.
  • conversationVendorInformation/: Vendor information metadata. Always required.
  • objects/: Platform event objects for real-time communication. Always required.
  • externalClientApps/: External client applications. Required when using an external client app for OAuth authentication, typically when connectedAppType is Partner in the Conversation Channel Definition.
  • extlClntAppOauthSettings/: OAuth settings for external client apps. Required together with externalClientApps/ when using ECAs.

When using an ECA for OAuth authentication with connectedAppType set to Partner, your folder structure looks like this.

Key components:

  • externalClientApps/: Contains the External Client App metadata file. Required when connectedAppType is Partner.
  • extlClntAppOauthSettings/: Contains the OAuth settings for the External Client App. Required together with externalClientApps/.
  • conversationChannelDefinitions/: Channel definition that references the External Client App.
  • conversationVendorInformation/: Vendor information configuration.
  • objects/BYOEvent1__e/: Platform event object with EventType and Payload fields.

Include both externalClientApps/ and extlClntAppOauthSettings/ when using ECAs with connectedAppType set to Partner. The OAuth settings file name typically follows the pattern: {ExternalClientAppName}_oauth.ecaOauth-meta.xml.

When using an ECA for OAuth authentication with connectedAppType set to Customer, your folder structure looks like this.

Key components:

  • conversationChannelDefinitions/: Channel definition with connectedAppType set to Customer (no External Client App reference).
  • conversationVendorInformation/: Vendor information configuration.
  • objects/BYOEvent2__e/: Platform event object with EventType and Payload fields.

When connectedAppType is Customer, don’t include the externalClientApps/ and extlClntAppOauthSettings/ directories in the package. The customer provides their own ECA configuration outside the package.

Create a first-generation managed package if you’ve already used first-generation managed packages to develop apps in your org or if you’re using a connected app for authentication. Otherwise, create a second-generation managed package.

  1. From Setup, in the Quick Find box, enter Package Manager, and then select Package Manager.

  2. Click New.

  3. Enter a package name for your managed package and then click Save.

  4. In the package you created, click the Components tab.

  5. In the Component Type picklist, select Conversation Channel Definition, and then click Add to Package.

    All foreign keys are also added to the package.

  6. If you created a sample outbound flow for AI agents, complete these steps.

    • In the Component Type picklist, select Flow Definition. Select the outbound flow that you created for escalating from an AI agent to a rep, and then click Add to Package.

  7. If you created a sample Einstein Bot and associated Omni-Channel flows, complete these steps.

    • In the Component Type picklist, select Bot, select the sample Einstein Bot that you created, and then click Add to Package.
    • In the Component Type picklist, select Flow Definition. Select the outbound flow that you created for escalating from an Einstein Bot to a rep, select the automatically created inbound flow for routing to an Einstein Bot, and then click Add to Package.

  8. In the Component Type picklist, select Connected App, select the interaction service connected app you created, and then click Add to Package. If you created multiple connected apps, select them all. If you require admins to set up and configure their own connected app instead, don’t include a connected app in the package.

    • To create the managed package for distribution to customers, select Managed - Release.
    • If you want to test and validate the package internally or with select customers before creating the formal “Managed - Release” version, select Managed - Beta.

  9. Click Upload.

  10. After the upload is complete, copy the installation URL and send it to your customer, who can install the package and set up the product in their orgs.