Question is simple what is the main reason to use project-scratch-def.json VS settings. They overlap a lot and I don't know when I should define features in scratch-def.json, and when to push them in settings?

A little bit of background. I am migrating an existing enterprise project to SFDX and they have a lot of features enabled:

enter image description here

Now I added settings to .forceignore to avoid push errors. But I don't feel it's right to exclude settings. For example, Knowledge.settings-meta.xml has a ton of settings which I am not sure possible to add in scratch-def.json (and why would I? I want to keep Knowledge.settings-meta.xml in my version control since this is metadata and, in the end it will be deployed to org, not scratch-def.json):

<?xml version="1.0" encoding="UTF-8"?>
<KnowledgeSettings xmlns="http://soap.sforce.com/2006/04/metadata">

But my question is Do I still need to replicate all of these in the scratch-def.json file? Or just some of them? What is the best way to handle this?


The scratch-def.json file is necessary for Unlocked Packages. Features must be enabled in this file in order to create Unlocked Packages that depend on specific features. Eventually, you'll want to migrate your settings to the JSON file in order to produce Unlocked Packages to simplify deployments. Any features that can be set in this file should be. Not all settings can be converted to the JSON file, so those should remain as they are, at least until these settings become available in the Scratch Org Definition file.

| improve this answer | |

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.