Building a connected app without a production instance to store oAuth keys

I cannot find any reliable advice on the best approach to on oAuth secret keys when you do not have a production license.

Background – I am creating an application that the community can use for free in my spare time, and it will connect to Salesforce using oAuth. As this is a hobby project, I do not want to create the connected application within my current employers instance.

Options

1) Create a dev org and store them there. With this approach, will I have to remember to log into my dev org every X number of days to ensure it doesn’t get deleted?

2) Can you request a connected app configuration from SFDC without an org? I am assuming not

3) Is there another approach you can think of that removes the need to keep a dev org live for the rest of the life of the application?

As a note. If option 1 is the only way, I am thinking of writing a component of the application that will log into the master instance one a month to keep it live.

Thanks

Answer

1) Create a dev org and store them there. With this approach, will I have to remember to log into my dev org every X number of days to ensure it doesn’t get deleted?

Developer accounts never, ever expire. I have a developer account that I log in to sporadically, and I’m pretty sure I once went well over a year without logging in, and it was still there. The only exception to this rule are accounts created on pre-release servers, which may be deleted at any time, if salesforce.com feels like it. Technically, you could set up the org once, create your connected app, and then just forget about the login forevermore. Although you’ll probably want to remember what it was so you can update the logo, endpoint, etc, as necessary.

2) Can you request a connected app configuration from SFDC without an org? I am assuming not

Correct. All connected apps live in an org somewhere. Where it lives is pretty much entirely up to you. I’d personally recommend a developer edition, since they never expire, cost nothing, and are fairly disposable.

3) Is there another approach you can think of that removes the need to keep a dev org live for the rest of the life of the application?

There are other types of orgs you may or may not have access to. For example, I set up a Salesforce Free org once, which was sort of a light-weight salesforce.com org with 100 user licenses that had no CRM functionality. This edition is sadly no longer available, but I’m pretty sure I can still log in to my free edition. However, all things being equal, a Dev Org should be perfectly acceptable.

As a note. If option 1 is the only way, I am thinking of writing a component of the application that will log into the master instance one a month to keep it live.

As stated above, there’s no need to do this. Sandboxes can be deleted if they’re inactive for a long time (I believe about a year or so), but a Dev Org never expires, and so you don’t need to worry about that. At the same time, you might continue to use the Dev Org for other purposes, such as logging into the community forums, doing the trailhead modules, submitting ideas on the IdeaExchange, and more. Having any sort of salesforce.com login is actually pretty versatile. You can even use it as an identity provider to log in to other services that support a salesforce.com login.

Attribution
Source : Link , Question Author : Autobat , Answer Author : sfdcfox

Leave a Comment