Thariq Latheef

Thariq Latheef MSc DS&AI (R), B.Eng (Hons), BSc (Hons) IT | MarTech Engineer | 3X Salesforce Certified | Google UX Design Certified | Design Enthusiast

SFMC rejected my field with “invalid Length.”The field didn’t even support a length.It was a Date field.That one error c...
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?

🚫 Myth:“DISTINCT removes duplicates.”I still see this assumption in Salesforce Marketing Cloud SQL, and it can lead to d...
18/07/2026

🚫 Myth:

“DISTINCT removes duplicates.”

I still see this assumption in Salesforce Marketing Cloud SQL, and it can lead to duplicate journey entries, inaccurate audiences, and unreliable sends.

Deduplication isn’t about removing duplicate rows. It’s about selecting the right record.

In several SFMC projects I’ve worked on, the goal wasn’t simply to return unique customers.

The real challenge was identifying the latest quote, the correct policy, or the right customer record before it entered a Journey or send.

That’s where many developers get caught out.

DISTINCT only removes identical rows. If a customer has multiple valid records, those rows are still different, and they’ll still be returned.

A better approach is to rank the records first, then select the one that actually matters.

That small shift in thinking makes SQL far more reliable and helps prevent duplicate journey entries while delivering a better customer experience.

One of the biggest improvements in my own SQL skills came when I stopped asking:

“How do I remove duplicates?”

and started asking:

“Which record should actually be used?”

That question completely changed how I write SQL in Salesforce Marketing Cloud.

What’s one SQL lesson that changed the way you build audiences in SFMC?

“SOAP is outdated. Just use REST.” I hear this a lot in SFMC, and it’s cost teams real integration failures.Here’s the t...
17/07/2026

“SOAP is outdated. Just use REST.”

I hear this a lot in SFMC, and it’s cost teams real integration failures.

Here’s the truth: SFMC isn’t a REST-first platform with legacy SOAP leftovers. Both APIs are current, supported, and built for different jobs.

The question is never “Which is newer?” It’s “Which fits the task?”

✅ REST API is best for:

• Journey Builder events (Event Definition API)
• Transactional Messaging
• Content Builder assets
• Data Extension row data (Data Events, Async API)
• Modern JSON-based external integrations

✅ SOAP API is best for:

• Creating Data Extensions & modifying their structure
• Subscriber and list operations
• Managing Triggered Send definitions
• Complex filtered retrieves of platform objects
• Email configuration and metadata

A real example from my own work:

I recently built a CloudPage tool that adds new fields to existing Data Extensions. REST simply can’t do that, DE schema changes are SOAP territory, so the whole thing runs on WSProxy.

But when the same integration needed to push rows into a DE? REST Data Events, no question.

That’s the pattern: strong SFMC solutions don’t pick a side. They use REST and SOAP together, each where it actually performs best.

Don’t choose the newer API. Choose the right one.

Where does SOAP still earn its place in your SFMC projects?

API Developer

Your email looks perfect in Preview.Then you send it…And suddenly, some subscribers receive:* Missing names* Empty dynam...
16/07/2026

Your email looks perfect in Preview.

Then you send it…

And suddenly, some subscribers receive:

* Missing names
* Empty dynamic content
* Broken personalization

Sound familiar?

The biggest lesson I’ve learned in Salesforce Marketing Cloud is this:

Preview is for validation. Production is the real test.

Here’s why 👇🏼 (see image)

Preview doesn’t always replicate your live send environment. Differences in subscriber data, send context, and real Data Extension records can expose issues that weren’t obvious during testing.

Before activating any journey, I always check:

✅ Test with real subscriber data
✅ Verify Data Extension values
✅ Check fallback logic (EMPTY(), AttributeValue())
✅ Review dynamic content conditions
✅ Send test emails to multiple scenarios

A few extra minutes of testing can prevent hours of troubleshooting later.

What’s one issue that only appeared after a production send?

MarTech

One of the most common questions I see from developers getting into Salesforce Marketing Cloud is:“Should I use AMPscrip...
15/07/2026

One of the most common questions I see from developers getting into Salesforce Marketing Cloud is:

“Should I use AMPscript or SSJS?”

The answer isn’t “which one is better.”

It’s which one is the right tool for the job.

Here’s the rule I follow 👇🏼 (see image)

✅ Use AMPscript when you’re personalizing email content using subscriber or Data Extension data. It’s fast, purpose-built for email rendering, and easier to maintain.

✅ Use SSJS when your solution requires more complex logic, API integrations, JSON processing, or CloudPage server-side functionality.

Could you use SSJS for everything? Technically, yes.

Should you? Usually not.

Choosing the right language keeps your solutions simpler, more maintainable, and easier for the next developer to understand.

After building production solutions in SFMC, I’ve found that using the right tool for the right task often matters more than writing clever code.

Which do you find yourself using more in your day-to-day work, AMPscript or SSJS?

MarTech

I’ve seen one missing attribute quietly break an email for thousands of subscribers.No error. No warning. Just “Hi ,” la...
14/07/2026

I’ve seen one missing attribute quietly break an email for thousands of subscribers.

No error. No warning. Just “Hi ,” landing in inboxes.

The fix isn’t a hack, it’s a habit.

Instead of referencing subscriber attributes directly, use AttributeValue().

Why it matters 👇🏼 (see image)

If the attribute is missing, AttributeValue() returns an empty value instead of causing your personalization to fail. Pair it with an EMPTY() check and a fallback like “there”, and your emails remain professional even when data isn’t perfect.

It’s a small change, but at scale, small habits are often the difference between a smooth send and a late night production issue.

What’s one AMPscript habit that’s saved you in production?

Address

Kalagedihena

Alerts

Be the first to know and let us send you an email when Thariq Latheef posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to Thariq Latheef:

Shortcuts

Share

Category