I am working on a Managed package App that makes callouts to a well-known external REST API. Some of the Endpoints are asynchronous, meaning they just give back a Job Id. Currently, ugly Apex is polling a second endpoint to check whether the result is ready.

The obvious improvement would be that the External Service signals Salesforce that results are ready and technical solutions for that are listed below. Each have drawbacks that make me wonder what to do:

  1. Platform Events: It's Salesforce-specific signaling. The External Service would need to change something specifically for Salesforce-based clients. Something they don't want. I also fear the complexity of making that work from a Managed Package. I don't want subscribers to set up Connected Apps or other Auth artifacts.

  2. Apex REST Webhook: A nice generic solution but the Setup in Salesforce will be cumbersome and not fully automatable with code. To make the Endpoint reachable from the outside a Domain and a Site need to be created, configured and connected to a packaged Webhook class.

How did/would you decide? Are there other options? Did I miss something?

  • 1
    Apex continuations are only usable in the context of VF/LWC Controllers If I am not mistaken. If that would be the case, a simple setInterval would be worth to consider as well, but I do not think it is the case. @Robert Sösemann have you consider an autolaunched flow that pauses and resumes after specified time? As an alternative for schedulables or queueables Mar 25, 2022 at 10:28
  • 1
    Sure, I will ellaborate a proper question soon today Mar 25, 2022 at 12:14
  • 1
    What capabilities does this external platform have? Could it, say, send an email, which you could then set up an Email Service handler? You're allowed two minutes of callout time, maybe you could call some sleep hook for like 1:50 to keep Apex alive? Can the request complete in two minutes? Could you make it synchronous anyways? A Queueable chain might be convenient as well, or maybe a Batchable class that polls until it's done?
    – sfdcfox
    Mar 25, 2022 at 12:51
  • 1
    @GabrielSerranoSalas You are right, continuations make sense in Lightning/VF context only. I should have clarified that in my response whether the use case involved Lightning components. However, I'm curious to see how you would design this with flow pause/ resume functionality as it might have its own use case based limitations.
    – arut
    Mar 25, 2022 at 12:53
  • 2
    Connected App packaging is for 1GP I believe. There are problems trying to do this in a 2GP. Do you really have to have separate connected apps for each subscriber org? Could they not all use the same connected app? After all, it sounds like they are all connecting to the same external service. Each org would have to be connected to and refresh/access tokens obtained independently, through use of a single Connected App. We, as an ISV, do similar for a mobile app, with the Connected App existing on our PBO.
    – Phil W
    Mar 29, 2022 at 6:17

1 Answer 1


I would engineer this to leverage a Connected App, using a server-to-server authentication flow. Salesforce supports OAuth 2 JWT flow for this purpose.

The Connected App should not be packaged (I know there's a knowledge article mentioning packaged Connected Apps, but that is not a recommended approach in my book and doesn't work with 2GP), but instead created on the ISV's PBO (Partner Business Org). It can be shared by each and every customer of the ISV in the integration between the external service and their specific org - when the Connected App is first used against an org it gets set up in that org (if desired its use can then be monitored or even restricted or banned on that org).

The external service simply requires access to the necessary details for the Connected App (client ID etc.) and the correct end-point on the customer org. It performs whatever authentication is required, when required, then should invoke some API on the org with the necessary authentication token and data.

If you did package a Connected App in a 1GP, each install gets a unique client ID etc. which makes wiring it up with the external service far more complex.

  • Yes, this is the correct approach - you definitely do not want to have one connected app per customer as this would be a logistical nightmare. What makes this confusing is Salesforce's decision to have Connected Apps 'live' as metadata within an individual org. They should have created some separate portal like api.salesforce.com/apps similar to how other providers like Slack handle their developer apps. There's no putting that genie back in the bottle though, so the best thing to do is make sure they're created in an org you won't lose access to, ideally your PBO as @Phil W suggested. Mar 29, 2022 at 20:14

You must log in to answer this question.

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