Field merges would always bring in the "actual" value stored on the field. The picklist display field would only really appear if you're using it in a form or accessing the record via the UI.
Would you be able to detail how this information flows into your CDO? Otherwise right now the "quick" and dirty way is to either use CDO data services to run it into a program builder / canvas asset to do a "lookup" and update an "email field merge" field in your CDO. I'm also half guessing it's very appropriate for a contact to have more than 1 insurance policy "inquiry", so is this always going to be running after a particular form submit?
If it is from the form submit, and the submit creates a new CDO record every time - you can configure a CDO Services step for "new records" that always adds them to a program canvas, run an update rule that looks up on the insurance code and inputs an english value into a separate field, then add the linked contact into the appropriate email campaign.
Please let me know if this got some gears running, if not, would love to know more about the process so I can give you more distinct instructions.
Hong Tai Lee
The info flows into the CDO via the SFDC sync with Eloqua. It can come from a form submit but can also come from manual entry, via our sales agents. There is a Record Type on the SFDC Insurance Quote object which maps to the Prospect-Product Interest field on the CDO in Eloqua.
I was thinking the same thing in regards to the latter solution. Essentially, an update rule/lookup table solution on the program with the CDO record service feeding it and I've started to build that out. CDO Processing Step screenshot below:
Update rule screenshot below:
My plan was to just update the Prospect-Product Interest field in the update rule and then build a Field Merge off of said field. Is there a better way to do this? I got slightly confused when you said "and update an email field merge field in your CDO". Not sure if that matters since I'd like to go for the second solution you proposed.
Apart from what HongTai proposed you could just use Dynamic Content instead of Field Merge (if there are many options in this picklist, I would consider using API to upload the pairs). It might be just the easiest solution to your problem - but changing CDO might be better for long-term, depending on your data model planning.
I agree with Mateusz Dabrowski, Dynamic content!
Thanks BK and Mateusz. Dynamic content has been (and will be) part of the plan for our future.
Apologies for the delay, it has just been a very crazy past couple of days. It's awesome that we were thinking along the same lines, but there is a distinct issue of using dynamic content. If I were to actually have had two policies, the dynamic content would literally stop at the "top" one that was listed on the very FIRST successful lookup. Unless you have very specific conditions on each dynamic content with a time parameter (even then it's open to not functioning properly if I were to have viewed multiple policies / submissions). Dynamic content doesn't do the lookup from the CDO, just from the contact record and checks if ANY records satisfies the condition plus in the order listed in the Dynamic Content list.
As such, what you're doing with the data object service / new record service would be the best since the NEWEST submission would always make it into the contact record.
Another apology for sometimes using odd wording, I was pretty much referring to the field merge asset that refers to the field in the CDO - had my tongue tangled up there. On top of that, by using new CDO services, you could add the CDO to even program builder assets and send out emails that directly reference the CDO record without having to use the "newest, most recently modified" and etc parameters on the field merge. I'm sure this might come in handy with insurance renewals, quotes, and etc as a contact would likely have more than one of those at any given time.
In any case, I heavily do advise against using Dynamic content loosely like this. There has been MANY use cases where we were called in to do a lot of fire fighting on such issues, as extensive lists of dynamic content conditions were built and folks only discovered this "hierarchy" issue 2-3 months after implementation with contacts already receiving 2+ copies of bad emails.
Hong Tai Lee
I totally forgot about the hierarchy issue with Dynamic Content. Thanks for pointing that out!
Great point, HongTai!
Indeed, if there is either:
- no retention policy on CDO records that has been already e-mailed or
- no datestamp column (that would allow utilising date logic within dynamic content)
- you expect multiple orders even within a very short timeframe (leading to datestamp within the last logic not giving confidence)
then dynamic content may fail by showing older records and indeed - your approach will be best.
The only other alternative I can come up now would be using a technical field in the data model to be populated (via CDO services) with the product code and then, on a campaign, before e-mails are sent, modifying this value by data tools / contact washing machine. But again - that's quite a dirty solution.