Dynamics fields showing hashed values in Marketo sync

[Robert_Kelen3]

This isn't news, but since I had a hard time finding the answer when I went looking the first time, I thought it would be worth jotting it down for the next person...

Are you seeing cryptic values in Marketo fields sync'd to Microsoft Dynamics (this sort of thing: 0c295e0f-de32-e011-b241-0050568c1347)?

It's a known issue that picklist type fields in Dynamics will, in Marketo Support's words, "show a friendly value to the user but provide a GUID value to Marketo...There currently isn't a way to get this to display the friendly value in Marketo instead of the GUID. The work around is to write to a different field that isn't a picklist or drop down and sync that to Marketo instead."

The good news is that a fix for this is on Marketo's implementation plan, but with no ETA as yet.

There's also a Product Idea to vote on here: Show Value of Lookup Fields NOT GUID for Dynamics CRM Integration​

[Dan_Stevens_]

Yep, this is expected behavior whenever you sync any Dynamics custom entities - like the "Owned By" region from Dynamics to CRM.  Just the GUID syncs natively.  This isn't true for simple select fields in CRM - like Industry, Country, etc. - just custom entities. 

Every lead record has an "owned by" field - which is essentially the geographic region that owns the lead:

The goal is to sync this value back to Marketo once a lead is assigned in CRM.  Normally, you can only get it to return values like "c5b372c4-1259-e511-80fd-c4346bb5a81c" instead of the meaningful name.

Back to CRM.  Here's the schema and the field name of the fields for this object:

With this info in hand, we then setup a smart campaign to convert the GUID value to the meaningful value - using a munction formula (see mor on Munctions here: Re: Documentation on munctions?

The way we have implemented today is whenever the "owned by" field changes (CDV trigger):

...it triggers off the following flow step:

Here's the full Munction string (the salesforce.com reference is used for both SF and MSD; and "ava_region" is the name of the "owned by" field in CRM):

##LOOKUP({{lead.Owned By (l)}},'salesforce.com ava_region','ava_regionid','ava_regiondisplayname','Unknown')##

Here's a sample result:

Here are the object properties for the Region custom entity in Admin after we configured it in Marketo:

And finally, the fields that we use to grab the ID and friendly name within the Munction:

[Robert_Kelen3]

Super helpful. Thanks Dan!

[Grégoire_Miche2]

Hi Both,

a quick note: Dan's solution uses munctions, which never was a full production feature, only a Beta one, and is now discontinued.

I am afraid that you will  have to go through a webhook or rest api. Look at

• flowboost from Etumos. Contact Edward Unthank (Etumos)
• CalcItNow. Contact Diederik Martens
• Hoosh. Contact Fab Capodicasa
• BrightHooks. Contact Rajesh Talele​

You will have to see in details which ones can provide you with the capability to leverage custom objects though a lookup function.

-Greg

[Robert_Kelen3]

Thanks Greg!

[Dan_Stevens_]

Greg, has Marketo officially stopped activating these for customers that request them?  If so, then that's too bad given some of the extended functionality this provides for transforming data.  Fortunately, they still work and haven't been disabled for those of us whose instances are able to use them.

[Grégoire_Miche2]

Hi Dan,

I have not tried asking for activation of munctions recently, so I cannot tell you. But this is the info I got from a couple of posts in the community.

But all my customers that are using them still can, AFAIK.

-Greg

[John_M]

I'll try to get the official word on this.

[Dan_Stevens_]

Thanks John Mattos (W)​.  While you're checking, can you also try to get some insight on this idea (which has been marked "working on it now" for some time now)?  .   Especially if Marketo decides to one day completely disable Munctions, it's going to negatively disrupt existing workflows that are based on them. 

[SanfordWhiteman]

Have had all of our requests denied. So yeah.