Email Personalization - Custom Object Related to Account

[OlgaKhadieva]

We need to build personalized emails using Custom Object data via a Velocity script. However, the Custom Object in question is related to the Account in SFDC, not directly to the Contact. Unfortunately, SalesOps has been unable to create a new custom object that would mirror this data and relate directly to the Lead or Contact.

Is there another way to achieve our goal? Specifically, could we sync the custom object data into Marketo and then use a Smart Campaign to populate custom Person fields, which could then be used as personalization tokens in the email?

Also, the current Marketo instance has only two custom objects provisioned, and one is already in use.

[SanfordWhiteman]

You’re right that this isn’t a good situation to be in.

---

Specifically, could we sync the custom object data into Marketo and then use a Smart Campaign to populate custom Person fields, which could then be used as personalization tokens in the email?

---

If you import the data as (Person-linked) Marketo Custom Objects, you don’t need any other fields. You can use first-level Marketo COs directly from Velocity.

However, your hurdles — and this would be the case no matter how you got the data into Marketo, same with JSON fields — are:

(1) Making sure you remove the data from people who no longer have the CO in SFDC. That is, you can’t just update Marketo people whose Account-linked COs were added/updated. You also need to track those whose COs were removed.

One elegant way to do this is add a Current As Of field to the Marketo CO. This is a Date field that you set to the current date whenever you do an import. Then import every SFDC CO, every day. In Marketo, filter on people whose CO has a Current As Of = today. People whose Current As Of is in the past implicitly had their SFDC CO deleted! It’s pretty cool because you don’t actually have to remove any records, they self-age-out.

(2) Overall volume. If you have millions of records, you won’t be able to import them all every day as suggested in (1). You have to do smarter change tracking to get adds, changes, deletes. This makes the SFDC queries trickier, e.g. you need to check the Recycle Bin.

The project seems quite doable for someone familiar with both APIs, provided you give yourself a couple weeks to test the process. But YMMV.

[PeeyushSachdeva]

Hi @SanfordWhiteman,

I was thinking of an alternate solution that might work for scenarios where custom object data exists at the Account level (in SFDC), but we need to use it for email personalization in Marketo.

If we implement Lead-to-Account (L2A) matching, once a Lead or Contact is matched to an Account, we could use Salesforce automation (e.g., Flows, Apex triggers, or ETL tools) to copy key Account-level custom object fields—or a summarized version—directly into custom fields on the Lead/Contact record.

This would allow us to use standard {{lead.token}} personalization in Marketo emails without relying on additional custom objects or Velocity scripting.

Pros of this approach:

• Utilizes the existing SFDC-Marketo sync, so we don't consume an extra custom object slot.
• Works for both Leads and Contacts, even before they’re converted.
• Simplifies email scripting—tokens like {{lead.Partner_Tier__c}} can be used directly.
• Well-suited for 1:1 or flattened/summarized data from Account-level custom objects.

Would love to hear if there's a different perspective on this.

[Jo_Pitts1]

@PeeyushSachdeva ,

one obvious problem with your idea is if the CO against the account is a many:one relationship. 

Granted, that can still be worked around by using packaging the data up into a single field in SFDC and cascading it to the contacts, but that then removes the ability to use {{lead.token}} to get the data into emails (at least partially, and possibly completely, resolvable with Velocity), or to use the data in smart campaign filters.

Cheers

Jo

[PeeyushSachdeva]

Hi @Jo_Pitts1,

You're right—many-to-one relationships definitely complicate things, especially when we try to flatten that data. I agree, concatenating values into a single field could work in simple scenarios, but it does limit filtering and dynamic personalization.

It’s definitely a trade-off, and probably more suited for straightforward use cases or as a temporary workaround when custom object slots are limited.

Thanks for pointing that out!