+ Start a Discussion
Andrew WeinsteinAndrew Weinstein 

"Cannot deserialize instance of complexvalue from null value null" - metadata field with CLI and tooling API

as part of a scratch org setup script, i'm trying to create and/or modify records through the tooling API - things like remote site settings, outbound messages, etc. these objects all have required "Metadata" fields.

using a remote site setting as an example: if i do this through the restforce gem for ruby, it works fine. i can execute:
resp = sf.create!('RemoteProxy', Metadata: {disableProtocolSecurity: false, isActive: true, url: 'https://www.my-site.com', urls: nil, description: nil}, FullName: 'test_remote_site')
and it creates the site correctly. if i try to do this through the CLI, though:
sfdx force:data:record:create -t -s RemoteProxy -v "FullName='test_remote_site' Metadata='{"disableProtocolSecurity":false,"isActive":true,"url":"https://www.my-site.com","urls":null,"description":null}'"
it fails with error: "Cannot deserialize instance of complexvalue from null value null or request may be missing a required field." I get the same result if I serialize the JSON. The data I'm providing is the same, so the problem isn't with the data or the API itself; it seems like either I'm not using the correct format, or something in the CLI is not serializing the JSON and/or building the request correctly.

Anyone else encounter a similar problem or find a workaround? In what format am I supposed to provide the metadata for a request like this?

Mike RichmondMike Richmond

I'm trying to accomplish the same thing and I'm running into the same error. Were you able to find a resolution for this?

Andrew WeinsteinAndrew Weinstein
Hi Michael,

Kind of. I didn't find a way to create/modify these records, but I did figure out more or less how to achieve the configuration I wanted.

I think that, when I posted this, I hadn't quite figured out the flexibility of the SFDX project directory structure. If you haven't looked at the Falcon Project Template (https://github.com/sfdx-isv/sfdx-falcon-template), I'd start there. Your actual package should be in force-app/, but you can create other parallel directories in your project, which can be forceignored or gitignored as you wish. So basically, my solution was something like this:
  • leave the packaged remote site settings/workflows/etc. alone and keep them in the force-app (default) directory
  • create an unpackaged/ directory, which contains metadata that will be checked into source control and pushed to/pulled from scratch orgs, but NOT included in the actual package
  • create an untracked/ directory, the contents of which are gitignored, that contains developer-specific files created by a scratch org setup script
  • include a remote site setting in the unpackaged directory with a path like "http://SUBDOMAIN.my-site.com," and forceignore this metadata file so it doesn't get pushed to the scratch org
  • have the scratch org setup script copy that unpackaged, forceignored remote site setting into the untracked directory and replace (use sed or whatever) SUBDOMAIN with an env var set by each developer
if that's all set up correctly, the unpackaged version of the remote site setting will get included in your repo as a template, but the customized version generated by your script will get pushed each time someone creates a scratch org.

Hope that helps!

Mike RichmondMike Richmond
Hi Andrew,

We do follow a similar approach for our scratch org specific configurations. I guess my problem is a little different though, as I'm trying to create a script that will dynamically change the Remote Site Settings after a Developer Sandbox refresh. 

Maybe I'll reach out to the DX Trailblazer group to see what the actual format of the metadata fields needs to be for the CLI, or if it's even a supported feature. The examples in the CLI reference are pretty trivial.

Andrew WeinsteinAndrew Weinstein
Gotcha. Yeah, in that case, sorry I don't have much to offer. I'd think your best bet might be to update the local metadata file and push it back up to the scratch org, instead of trying to modify it remotely via the CLI, but I'm not sure if that's possible with your workflow.

I'll watch for answers in that group as well.