19/07/2026
SFMC rejected my field with “invalid Length.”
The field didn’t even support a length.
It was a Date field.
That one error cost me nearly an hour of debugging, and taught me more about WSProxy than any tutorial.
⚙️ The context:
I was building a CloudPage tool where users could add new fields to existing Data Extensions. Search for a Data Extension, review its schema, define new fields, and submit.
Data Extension schema changes are SOAP only territory, REST can’t touch them. And writing raw SOAP requests inside SSJS gets painful fast.
WSProxy gave me a much cleaner way to do it, with just a few readable lines instead of hand-built XML.
Everything worked.
Until…
⚠️ “invalid Length.”
Here’s the unwritten rule I eventually uncovered:
Text and Decimal fields must have a length.
But Number, Date, and Boolean fields must not carry a MaxLength or Scale property at all. If those properties are present, even when they’re empty, Salesforce Marketing Cloud rejects the entire request with that cryptic error.
I couldn’t find this behavior documented in the official references I checked.
The fix was just three lines of code (shown in the image 👆🏻).
The debugging was an hour of my life.
One thing this project reinforced for me is that WSProxy makes working with Salesforce Marketing Cloud metadata much cleaner. But abstractions don’t remove platform rules, they just make them easier to work with.
What’s the most cryptic SFMC error you’ve ever had to reverse engineer?