ref:_00D90q6Cb._5002v2sALNR:ref
If a workflow contains a custom action from another environment, and then the workflow is imported into another environment, without that custom action. The import will fail.
Please implement a mechanism to cope with missing actions, so that the workflow can be imported in and give the end user the option to remove the incompatible action.
We’re excited to share that this feature is now available! For more details, please refer to the documentation on Copy an Xtension to another tenant.
This should really be a bug rather than a feature request. If you look at it from the analogy of deploying software, your Connection (to the registered extension) acts like a connection string that is referenced in your app abstracting knowledge of the connection details away from the app. The app talks to a known interface. This situation is like having to decompile your code after you've deployed it to production, changing it, and recompiling it. It completely destroys any possibility of automated deployments and is a major disincentive to expanding use of this product
It's difficult to exagerate how much of an impact the non-portability of xtension actions has on application lifecycle management. At the moment, moving a workflow from one environment (dev) to another (prod) requires that all xtension actions are reconfigured. Not only that, the variables used in a previous version of the xtension action cannot be re-used - they're orphaned with the old, invalid xtension - and any actions that use these variables must be reconfigured also. This means that deployments are highly prone to error and any upstream testing is rendered invalid.