2

We use a Connected App to allow our clients (from different organizations) to authorize and provide our platform API access to their data.

Our original developer set this Connected App up on our Developer Instance.

Is there any difference between having it on the Developer Edition vs creating one on the Enterprise Edition?

We use the REST API only so does this have any impact on the speed of API requests made?

I figured it doesn't because we use our client's instance (from the OAuth response) which is a production instance. However, I was wondering if SF does something behind the scenes, for example prioritizing it lower since it's a "development" Connected App.

Is there a best practice on creating Connected Apps on specific Editions?

2

Is there any difference between having it on the Developer Edition vs creating one on the Enterprise Edition?

No. The first time it is used, it is "installed" into the client's Enterprise Edition Org so that admins can control access to it, so it doesn't really matter where you put it. Obviously, don't put it in a sandbox, because you'll lose that Connected App if you refresh.

We use the REST API only so does this have any impact on the speed of API requests made?

No. The REST API has similar performance using any session Id. It doesn't matter if this came from a Connected App, a browser session, SOAP session, etc.

I figured it doesn't because we use our client's instance (from the OAuth response) which is a production instance. However, I was wondering if SF does something behind the scenes, for example prioritizing it lower since it's a "development" Connected App.

No. Every connected app is treated identically. If that were untrue, most ISVs would be crippled because their API connections would suffer.

Is there a best practice on creating Connected Apps on specific Editions?

If you're using the connected app for yourself, put it in your production organization; it'll be copied to all Sandboxes during each refresh. If you're acting as an ISV, place it in your managed package's Developer Org. This way, you'll know exactly where it is. There's no need to add it as a member of your managed package, though.

  • That all makes sense, I figured as much but wanted to double check. We're acting as an ISV so I'll keep it in our Developer Org then. Thanks for the speedy answer! – Danesh Feb 1 '17 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.