I think I'm familiar with the difference between a connected app definition and its consumption:

As the vendor, my Connected App definition lives by himself in a dev org forever:


For the users, in other orgs they can see (or revoke) any Allowed apps from their user record:


The Connected App does not need to be in the package for users to 'Allow' access to it.

But Salesforce also make it possible, in a release org that has a namespace prefix and a managed package, to add a Connected App definition to a Managed Package:

Packaging a Connected App

After creating a connected app or a new version of an existing app, package it to make it available to users on other Salesforce organizations. You can add a connected app to a managed package in the same way as, and along with, other components such as custom objects, Visualforce pages, or Apex classes. This makes it easy to distribute a connected app to other Salesforce organizations. As a packageable component, connected apps can also take advantage of all other features of managed packages, such as listing on the AppExchange, push upgrades, post-install Apex scripts, license management, and enhanced subscriber support.


What is the use case for this, as opposed to the definition existing only in the release organization?

3 Answers 3


Packaging the connected app allows administrators who install the app to control which of their users can use the application.

Rather than the coarse ability to block or not block an app (seen in Setup -> Manage Apps -> Connected Apps Oauth Usage), you get the ability to control the security settings for the app in a more finely grained manner (seen in Setup -> Manage Apps -> Connected Apps -> Select App). By default Salesforce have installed packages for apps such as Chatter Desktop and Salesforce1 in all orgs.

For example:

  • you can select profiles or permission sets which can use the app
  • choose if IP policies are enforced (or ignore if 2FA has been used)
  • choose PIN policies for a mobile app

If the Connected App is not packaged by its provider, then administrators will only have the binary option of blocking or allowing the app.

A good article on managing these permissiong can be seen here: Managing External Apps with Connected Apps | Cloud Sherpas

  • This nails the nuances of the question, particularly the difference between a connected app in isolation vs in a package. Thank you! Dec 23, 2014 at 20:03

Let's say that you have a salesforce application that communicates with an API you've developed. That API connects to salesforce using the Consumer Secret and Consumer Key of your connected app, and it is used to grant access to the org using OAuth.

Now you package that app and start distributing it through the appexchange. Every time somebody installs your app, the connected app is deployed preserving the same Consumer Secret and Consumer Key, and will be able to communicate with your API.

Each OAuth grant is based on users and orgs; so the fact you granted access to that connected app on a costumer org does not grant you access to other costumer orgs also obviously.

  • Valuable input, Bruno. Given the customer users can 'Allow' the Connected App without the Connected App being a member of a managed package, what do you think is the motivation to add it to the managed package? Dec 22, 2014 at 15:35
  • 2
    The main benefit is to preserve Consumer key/secret across multiple orgs. When you develop an external implementation that can communicate with unlimited orgs with one set of key/secret. Otherwise you'll need to configure your external solution with key/secret every time (creating new connected app each time also, and adding more configuration overhead). Dec 22, 2014 at 15:40
  • Yes, every time you create a new connected app, a new set of key/secret is generated. Dec 22, 2014 at 15:44
  • This is a misleading answer that doesn't answer the original question. You can still create a connected app, not package it, and still have the ability for customers to authenticate with the app using the same client key/secret by just having all customers navigate to the same URL that begins the authorization flow. help.salesforce.com/s/… So what is the benefit to packaging it vs not packaging it? Apr 14 at 1:06

For me,

The connected app allows my managed package to connect to the users org via oAuth using the single credentials defined in the connected app that is packaged. This access was required for specific purposes that could not be achieved via Apex but had to be done via tooling or metadata API.

The user still has to grant Access via the oAuth flow but we do not need to use the username / password flow.

Not sure how much this helps or not but that was my use case.

Each connected APP gets its OWN key and secret.

Another answer to the question maybe:

Connected App in Managed Package

  • 1
    Thanks Eric this is helpful. I guess what I'm struggling with is the fact that we could still do that without the Connected App being a part of the managed package. Dec 22, 2014 at 15:20
  • 1
    @bigassforce - Good point, now I am wondering. I am curious, if I never packaged the connected app would I have still been able to use the key and secret to utilize oAuth.
    – Eric
    Dec 22, 2014 at 15:23
  • You got it. Editing this comment to reflect that the key/secret are indeed the same in all orgs for an installed Connected App. Dec 22, 2014 at 15:25
  • 1
    @bigassforce - Same key and secret for all installed orgs (same as in de org). See link in answer for a similar question
    – Eric
    Dec 22, 2014 at 15:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .