5

I try to deploy a custom Platform Event MyEvent__e and a Flow MyFlow referencing it as Resume event for a Pause Element. Both worked perfectly in my non-namespaced developer org but when deploying to a namespace org it fails with

[Flow FlowName] OnResumeEvent (Pause Configuration) - Resume event type "MyEvent__e" doesn't exist or isn't supported by your org.

9
  • Clarifying: is a "namespace org" a namespaced scratch org, a 1GP packaging org, or something else?
    – David Reed
    May 19 at 13:48
  • 1
    If it is intended to be included in the package, you need it to be namespaced - I've noticed that flows include namespace prefixes in API name references when created on namespaced orgs. This is fine for both 1GP and 2GP managed package development as long as you develop on scratch orgs with the package namespace. If you are developing 1GP on dev orgs, you're going to have to do namespace twiddling.
    – Phil W
    May 19 at 13:57
  • 1
    BTW, in namespace twiddling, when we used to do 1GP on dev orgs we set a bespoke namespace on each dev org and simply ran global search/replace between the official and dev org namespace prefixes. This was made easier by using Illuminated Cloud which has built-in support for this (but only as long as your dev org has a namespace too; see the "Substitution Rules" part of that documentation).
    – Phil W
    May 19 at 14:03
  • 1
    Hey @RobertSösemann, I guessed - since you changed Shivankar's question so quickly :)
    – Phil W
    May 19 at 15:18
  • 1
    @RobertSösemann not sure how to improve the question to improve later search. Perhaps "Flow developed on no-namespace org cannot be deployed to namespaced org" as the title?
    – Phil W
    May 19 at 15:25
3

If it is intended to be included in the package, you need it to be namespaced - I've noticed that flows include namespace prefixes in API name references when created on namespaced orgs and don't cope well when these prefixes are omitted**. This is fine for both 1GP and 2GP managed package development as long as you develop on scratch orgs with the package namespace. If you are developing 1GP on dev orgs, you're going to have to do "namespace twiddling".

Namespace twiddling is required when doing development of 1GP managed packages on dev orgs. In this case you need to set a bespoke namespace on the relevant dev org(s) and simply run global search/replace between the official and dev org namespace prefixes on retrieve or before deploy.

This was made easier for us by using Illuminated Cloud which has built-in support for this, but only as long as your dev org has a namespace too; for some cases we also needed to use "Substitution Rules" to ensure substitution of the namespace didn't also affect irrelevant parts of the code. These are covered in the IC2 documentation).

**: Most packaged metadata copes without namespace prefixes well (though some don't, such as Aura components and now Flows). It was actually adding Aura components to our package that forced us to adopt first namespace twiddling then switch to SFDX and scratch orgs with namespaces.

5
  • Isn’t that Salesforce bug we need to raise attention of? By the way are you on Twitter?🥸 May 19 at 15:19
  • 1
    @RobertSösemann this isn't the first metadata that needs those namespace prefixes, as I have now added to the answer. Aura components were the first, and a major pain in the a**e. As to twitter, not yet. I think I need to so I can get that way of accessing SF product managers and dev team like you suggested!
    – Phil W
    May 19 at 15:22
  • 1
    We (Salesforce.org) cope with this problem by injecting tokens in the metadata that are replaced by either a blank value or the actual namespace when deploying, to avoid having to always develop in namespaced environments. Flows are particularly prone to namespacing problems - please file Cases when you find such problems, even if you have a workaround! It helps people like me to be able to find those Cases and use them as fuel in conversations about getting those issues prioritized.
    – David Reed
    May 20 at 17:34
  • @DavidReed out of curiosity, is there a reason to support development of a package in a no-namespace org (or even to not shift to scratch orgs with SFDX)? Is it a pure investment issue (as in don't have the time and resource to make the switch) or is there a different driver for it?
    – Phil W
    May 20 at 18:07
  • 1
    There's a couple of reasons. One is that it allows community development of open source products (like NPSP and EDA). Another is that, well, I really hate namespaced scratch orgs - because there's no boundary in an NS scratch org between the package and outside metadata, some classes of dynamic Apex bugs can slip through, and I've seen some really weird edge cases with how the NS gets applied. (To clarify, we are 100% in scratch orgs, but almost all non-NS scratch orgs).
    – David Reed
    May 20 at 18:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.