3

We are considering leveraging headless (no-UI) flows created using the Process Builder in a managed package. The managed package would contain some fixed logic and call out to flows (named in some configuration) at defined points so customers can add their own custom logic.

A block to this appears to be that the necessary creation/referencing at runtime (by name) is not supported as described in this idea Dynamically obtain a Flow Interview instance from within Apex. (Please vote for that idea if it makes sense to you.) The flow name and the interview itself has to be known at compile time as illustrated in the Interview Class documentation.

Or is it possible to include a version 1 of the flow in the managed package (that essentially defines the interface but has a default or empty implementation) that is always called and then for version 2, 3, 4 etc of the flow to be created in the org that the managed package is installed in containing the specific implementation?

Any insight appreciated.

4
  • Flows once packaged cannot be subscriber updated, nor new versions created over the packaged ones by the subscriber. developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/…. I'm working on a response though to this, around using either a REST API callout (where there is a Dynamic Flow API) or something I prototyped in my LittleBits Connector, that dynamically generates a Apex Flow Factory class. This requires the use of the Metadata API to configure as a system level thing each time a new Flow is introduced. Commented Jul 15, 2016 at 23:25
  • But the effect at runtime does not have the overhead and DML complications a HTTP callout to the REST API option has. I'll hopefully get an answer added over the weekend... Commented Jul 15, 2016 at 23:25
  • @AndrewFawcett Thanks for getting back on this - will be very interested to see what you've come up with.
    – Keith C
    Commented Jul 15, 2016 at 23:36
  • Just finished this blog here, let me know your thoughts, andyinthecloud.com/2016/07/19/introducing-the-flow-factory Commented Jul 19, 2016 at 4:56

1 Answer 1

3

So to answer your second question first... "... is it possible to include a version 1 of the flow in the managed package (that essentially defines the interface but has a default or empty implementation)" I'm afraid not, as per the doc here, default/empty flow is not editable nor can the user create a new version of it (i tested this scenario).

This leaves the following options...

  • Calling the Flow REST API from Apex. There are many examples of using the Salesforce REST API's from Apex. However all require the Remote Site setting setup for the package installed instance, since the endpoints vary. Thus this has to be a post package install task or some form of semi-automation as described here. The other drawback is it will impact the structure of your code due to the restrictions around DML and callouts.

  • Dynamically Injected Flow Factory Apex Class. This option leverages the ability for packaged code to dynamically call code defined in the subscriber org and the use of the Apex Metadata API. In order to dynamically generate a factory class in the subscriber org that explicitly references the Flow instances defined in the org, instantiate them and pass them back into the packaged code. While you still have to go through the Remote Site and HTTP call out dance, once the factory class is generated this only applies to the administrator user and then only when Flows are created. The runtime aspect remains 100% Apex native so no HTTP and DML complications.

Both options are workarounds, if you want to vote for a platform solution please do so here.

You must log in to answer this question.

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