I am thinking about using Feature Management and FMA parameters in my Managed Package app to allow more flexible licensing.

Which means we:

  • Add FMA Feature Parameter in the Packaging Org
  • Release a new Package Version with that Params
  • Wait until they are synched to out LMO org with the installed FMA app.

But how does this work together with an SFDX based development model where all code is developed in scratch orgs that have no idea about FMA and Packaging?

  • How do I test FMA parameters?
  • Do they exist in my scratch org?
  • Do I need to mock such FMA parameters?

To develop and test Feature Parameters with Managed 2GP (Second-Generation Managed Packages), you must work directly with the Feature Parameter metadata.

With that in mind, here are the answers to your specific questions.

How do I test FMA parameters?

This depends on whether you’re trying to do functional or integration tests.

For functional tests, you can manually change the FP (Feature Parameter) metadata as you develop in a namespaced scratch org. This will let you see how your code reacts to changes in Feature Parameter values.

Just make sure that you know what your “baseline” FP values should be so you don’t unintentionally pollute your published package versions with dev/test default values. Better yet, use source control and just discard your dev/test changes before publishing a package version.

For integration tests, ie. when you want to see how a change in a Subscriber-to-LMO FP might trigger some custom code running in your LMO, the only option is to create a managed-released package version and then install that package in an org.

Remember, you can’t do integration tests with managed-beta packages because the LMO/Subscriber connections aren’t wired up as part of beta package installs.

Do Feature Parameters exist in scratch orgs?

If you’re using a namespaced scratch org, they exist as if you were developing directly in a packaging org. If you’re looking for an LMO/Subscriber connection, though, you’ll need to build a managed-released package version and then install that package in the scratch org.

Do you need to mock Feature Parameters?

You shouldn’t need to mock Feature Parameters. They exist as metadata while you’re developing your packaged code. If you’re developing in a namespaced scratch org, the FP metadata will be deployed to your scratch org as part of your initial force:source:push.

However, if you build complex logic into your app that relies on certain Feature Parameter values, you may need to get creative in your test code to ensure that all logical paths are taken.


Feature Parameters are defined as XML in your source of truth. They will exist in your scratch org if you push them in as metadata. They can be tested, though the actual feature parameter value is not transmitted to the LMO in the test. We built a simple framework for these that we can use for testing though. We only develop in scratch orgs and only push up into the Packaging org upon a merge into master.

NPSP has examples of our Feature Parameters and classes that you may find helpful:

I hope this helps.


To add to this, I would also suggest just creating the Feature Parameter definition in the packaging org as you want it to be included in package, and then keeping them out of the code in the namespace folder, and instead store them with the unpackaged code that gets pushed to scratch org.

That way, you can set the feature param for that scratch org in the XML, and push it as 'on' (since there is no FM UI in scratch orgs) but not risk accidentally pushing the an incorrect activated default to your packaging org

  • Feature Parms can (and should) be in the managed package code. Since scratch orgs aren't linked to an Packaging Org or Licensing Management Org, any test values applied in that Scratch Org never leave the Scratch Org. Having them the definitions for them in your managed code though allow for a more accurate representation of your package in your repo and a single push into the orgs. Apr 21 '20 at 16:34
  • 1
    Think we might be talking about slightly different things. I am talking about something like the github.com/sfdx-isv/sfdx-falcon-template in 1GP. What I am saying is keep the FM folder IN the sfdx-source BUT not in the ns folder. Instead keep it in the unmanaged section. So yes, it is part of code that gets pushed to scratch, but if you change values in XML to enable in scratch org, they never accidentally get deployed to packaging org Apr 21 '20 at 18:15
  • I see. We're also still using 1GP and do keep the feature parameters in the src folder. However, we also only create new Feature Parameters directly in XML via our IDE. Then they're automatically pushed to the scratch org, and eventually to the Packaging Org when the branch is merged into master.. I supposed that technically either will work, though prefer to keep the parameters in a single place so that the the src in the repo is an exact match to what's in the packaging org. For the most part, I don't believe any of our unpackaged metadata is ever deployed into our packaging org. Apr 21 '20 at 18:22
  • Yeah, you have a much more robust deployment process than I have in place - so for something like this that should never change from release to release, I tend to just keep it out of anything that is deployed to the packaging org to avoid user error on my part Apr 21 '20 at 19: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.