SOLVED

Alternate field/token value if a token value is empty - looking for workaround

Go to solution
Anonymous
Not applicable

Alternate field/token value if a token value is empty - looking for workaround

We send emails on behalf of sales reps worldwide, and in Japan/Japanese, the custom is to sign off as Lastname Firstname if you have a Japanese Name (in japanese characters).  My thought is to use a custom lead owner field for "lead.Lead Owner Last JP" and "lead.Lead Owner First JP". Problem is that about half of our leads/users with a Japanese language preference are owned by non-Japanese reps (with no Japanese name).

Ideally, I'd do something like:

{{lead.Lead Owner Last JP:default={{lead.Lead Owner First Name}}}}  {{lead.Lead Owner First JP:default={{lead.Lead Owner Last Name}}}}

 
Tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions
Anonymous
Not applicable

Re: Alternate field/token value if a token value is empty - looking for workaround

Hi Ray,

Sanfords advice is probably the best. 

A script token could be useful too for something similar - Go to the tokens section of your program and pull the Email script into your tokens section.
0EM50000000TDRH.png

Call this something like script-sig-jp 
0EM50000000TDRC.png

If you now click on edit, you can now write a script with IF clauses: (I'm not sure of your exact syntax, but should be something like this):

#if ("${lead.Country}" != "Japan")
{{lead.Lead Owner Last JP}} {{lead.Lead Owner First JP}}
#else
{{lead.Lead Owner First Name}} {{lead.Lead Owner Last Name}}
#end


In your email you can reference your email script token using
{{my.script-sig-jp}}

View solution in original post

6 REPLIES 6
Rachit_Puri2
Level 7

Re: Alternate field/token value if a token value is empty - looking for workaround

As far as I know, MKTO doesn't allow use of Tokens within a token. Subscribing to this thread, to see if someone has an alternate solution.
SanfordWhiteman
Level 10 - Community Moderator

Re: Alternate field/token value if a token value is empty - looking for workaround

@Ray H In this particular case, why not just have the Japanese fields set to the same as the European/American fields by default (reversed of course), instead of leaving them empty? 

When there's a Japanese rep you override the default.

That way when you send a Japanese-language email the same two fields will be usable no matter what.
Anonymous
Not applicable

Re: Alternate field/token value if a token value is empty - looking for workaround

Hi Ray,

Sanfords advice is probably the best. 

A script token could be useful too for something similar - Go to the tokens section of your program and pull the Email script into your tokens section.
0EM50000000TDRH.png

Call this something like script-sig-jp 
0EM50000000TDRC.png

If you now click on edit, you can now write a script with IF clauses: (I'm not sure of your exact syntax, but should be something like this):

#if ("${lead.Country}" != "Japan")
{{lead.Lead Owner Last JP}} {{lead.Lead Owner First JP}}
#else
{{lead.Lead Owner First Name}} {{lead.Lead Owner Last Name}}
#end


In your email you can reference your email script token using
{{my.script-sig-jp}}
Anonymous
Not applicable

Re: Alternate field/token value if a token value is empty - looking for workaround

Thanks Philipp - I haven't explored email scripts, but looks promising.

@Sanford - Can't do the reverse Japanese name thing because our Japanese reps also deal with English leads as well. So when I send an email in Japanese on their behalf, it should be using their Japanese name, but when sending in English, it needs an English spelling.

Ahh, the joys of globalization. I mean globalisation.

SanfordWhiteman
Level 10 - Community Moderator

Re: Alternate field/token value if a token value is empty - looking for workaround

But you have 2 options. And you will always know what language the email is in. So in one case you use field1 and field2. In the other case you use field3 and field4.

SanfordWhiteman
Level 10 - Community Moderator

Re: Alternate field/token value if a token value is empty - looking for workaround

I'd turn it around and say using Velocity like @Philipp does is better over the long haul because more people should be getting into it. 🙂