Anyone seen any workaround (besides having multiple SDF project versions) to allow an SDF project to be deployed to both a one-world and non-one-world account, if the SDF project contains a custom list/record field of type Subsidiary? Bundles support this, but it doesn't appear SDF allows for this (outside of getting rid of the custom field before deploying)

I've used npm scripts to swap out

deploy.xml

and

manifest.xml

files to switch between OneWorld and Standard deployments. We had a 'support' folder that contained

deploy-oneworld.xml

and

deploy-standard.xml

and the npm script would copy the appropriate xml file to the

src

folder before deployment. Same for

manifest.xml

.

You can set the manifest required to false. It will remove the subsidiary field on the record. I've had issues on the form related to the records and currently have a support case open as it throws an error because the subsidiary field no longer exists

Interesting choice by NS to have the field be excluded automatically vs letting the Subsidiary field be created (since it appears to be technically possible). @Matt Bernstein I also see that SDF deployment breaks if another field's filters depends on subsidiary filtering.

Yes. I believe everything that filters must be done through scripting. You could always open a support case to get it supported as it would be beneficial

That would be another nice to have - ability to add fields before load to a form and define the filters via script (similar to defining the filters via the custom field UI)

I believe they should be the same. That's how I am deploying my suiteapp but I cannot currently test/deploy as there is a form issue with the subsidiary fiedl