Packaging Invocable Actions
Author Credit: Eric Smith assisted in the development of this material
Because invocable actions make great building blocks, there’s an increased risk that you’ll have a collision if you’re using unmanaged packages, so managed packages are generally recommended (and unless you have IP you want to keep confidential, we also recommend you simultaneously make the source code public and post about it).
It’s easy to create managed packages. If you’re not familiar with it, the basic process is:
- create a new free developer edition org to serve as the host for your package. Don’t use this org for anything else and give it a My Domain name that makes its purpose clear, like ‘managedFindRecordsHost’.
- deploy your project to this org.
- create an unmanaged package on this org and test it out. (When orgs are created, they create unmanaged packages. Once you convert the org to be a builder of a managed package version of your project, you can’t create unmanaged versions of that project on that org any more. )
- decide on a namespace. This will be highly visible to everyone who installs and uses your action. It’s an opportunity for branding, but try not to make it too long or cryptic, and keep in mind that every project you package will get its own namespace and they all have to be unique (so if you give the namespace ‘alexprojects’ to your very first package org, you won’t be able to use that for your second project. Therefore alexprojects_quick or alexprojects_1 might be a better bet)
- In Package Manager, convert the org to be a managed package host of your project, using the unmanaged project you built and your chosen namespace.
- Test out the resulting package by installing it on another org. I often spin up more free developer edition orgs to create clean environments for verification. Make sure that your actions can be seen in Flow Builder (see Troubleshooting below)
Troubleshooting Action Packaging
My package installs fine, but I don’t see my action in Flow Builder!
First, verify that the action does show up in Developer Console. If it doesn’t something went wrong with deployment and packaging. If the action is visible in Developer Console but not in Flow Builder, the problem probably lies in the interface between Apex and Flow.
One reason this might happen is that you didn’t use global for your class and methods. Only global invocable methods appear in Flow Builder and Process Builder in the subscriber org. More info.
You might be using a variable type that is legal in Apex but not in Flow, like Map or Set. Generally, this will be caught earlier in the process. Try simplifying your inputs and outputs until your class does show up in Flow. If your package is unmanaged, you can make the changes directly in Developer Console, an example of why Step 3 above recommends starting with an unmanaged package.
Note that you also have to use global on your invocableVariable input and output variables if you want them to show up. That’s discussed here.