The purpose of this idea is to gather all requirements for the next level of program token management. Here they are :
New types of tokens required :
Furthermore, we should be able to access campaign/program member values as tokens, including SFDC custom fields on the campaign member object (see )
We should also be able to access all SFDC campaign fields as tokens in Marketo programs. See , , , and this one and this one: .
Of course, all these would be used in flow steps (such as change data values, interesting moments, SFDC task creation, etc...) and in assets
Token management also needs some significant improvement :
Finally, token usage should also be strengthened :
All these improvements, combined, would lead Program + tokens technology to a unmatched productivity tools for marketers in small to very large teams.
This is a great list. Since your level of knowledge on this is way above mine, I couldn't tell if the specs above include the ability to use a token incorporating a Velocity script to resolve & assign a value to a field vs. just using a similar script for dynamic email content (for example, we use a script to alter email content by time of day -- during business hours TRUE or FALSE; would like to be able to use that same logic to change a field data value with that result).
No, the list above does not include this feature. Having some possibility to update field values is something that, IMHO, does not relate to Velocity. The only way to do it for the moment is to use some webhooks and an external server to do the computation and return it to Marketo.
There are a few posts and ideas on the community on this topic, and I, as many other, think that this is one of the weakest point in Marketo. E.G. https://nation.marketo.com/message/92320#comment-92320
This doesn't have Token Security on it. I'd like to see user specific / role specific security so I know someone isn't accidentally changing something they're not supposed to change.
Whoops. I see it now.
Token security is there :
Token definition should be separated from token value entry. We should be able to control who can create / delete tokens or edit token names or settings (see Make the right to create or delete program tokens, as well as change token names, a specific permiss...)
But I agree with you that security on token setting could be completed with security on who would have the right to change token values. I added it
Thanks Greg. Having to do a round trip to/from an external server for
simple computations is definitely as less-than-ideal situation : - (
On Thu, Feb 25, 2016 at 4:47 PM, Grégoire Michel <
Change the Date Token to a DateTime. When I'm using this for a webinar it'd be nice to be able to put in the time of the webinar, not just the date. I know the calendar file has it but I'd like to use the token on my reg page.
I'd also like to see a Time Token that automatically parsed it into local timezones. If I set the token for 12:00 CST it'd be nice if it showed up as 1:00 EST on the landing page, based on their locale.
Allow for an easy way to get the Calendar Token link from the Token page. I'd like to be able to easily test it.
Also, track users who have downloaded the calendar token.
If I change the Calendar Token, does it automatically update the users calendar entry?
I like these 2 a lot. THx!
and thx again.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.