Hi @Phillip_Wild ,    Modularity is the key point here. I try my best to make every new thing modular and refactor everything I see has repetition as much a I can, but it's a hard case to argue to spend time changing something that already works instead of working on new things that bring new value.  Although... do they really work? Because I keep seeing cases where something set up years ago by someone else is now outdated or has stopped working and nobody knows or realizes.  The keys here would be: build it modular and document as @Carrie_Chandle1 suggests, perhaps even build alerts to know when something stops working (this can be quite tricky, but we are also trying). We just have a lot of debt in that respect I guess. Maybe because the team was always small, maybe because of rushing or simply not knowing better.    Do you have any tips for keep centralized and up-to-date documentation? I think the pain points with it is finding a system (confluence? Excel?), and a structure (Diagrams? Tables? Lists? just text?) that will be clear and easy for everyone and at the same time not a pain to update, otherwise there is the risk of skipping the documentation step, something even I do when I'm stressed or in a rush.    With the welcome email example, I guess you were spot-on: if we have a campaign that says " send welcome email". We have several, sadly. Because we have two types of customers (you could almost consider them different businesses), and also because there are several different welcome emails so be sent depending on country and entry point.  Our welcome emails are an example of something that clearly needs refactoring, there should only be one campaign sending welcome emails (or 1 per type of client) where the right filters / choice steps / segmentation will determine which email you get.    The reason I wanted to use segmentations for logic rather than just personalization (we only really personalize based on language anyway, for now...) is precisely modularity. Whether or not to use a segmentation or just the field in particular perhaps depends on how much the segmentation can be re used. As much as possible, my aim would be to just go to one place to make the changes, but maybe i need to present clear situations to explain what I mean.  ... View more

That looks really interesting! Thank you for sharing 🙂 That would mean you can create a token where you define variables, then include it inside the email (even if it doesn't really output anything, just contains variables) and start referencing when appropriate.  For instance:  {{my.contentVariations}} - contains &varA_EN, &varB_EN, &varA_ES and &varB_ES of the content (probably also a default value). {{my.emailBody_EN}} - contains {{my.contentVariations}} and a code that based on some criteria references &varA_EN or $varB_EN {{my.emailBody_ES}} - contains {{my.contentVariations}} and a code that based on some criteria references &varA_ES or $varB_ES ...   Then you would need an email containing {{my.contentVariations}} whose body is another script, similar to a switch in javascript, where the cases are your preferred language, and for each case you serve a different {{my.emailBody_**}}. Is that more or less the direction? What you meant with adding levels of dynamism by referencing tokens inside tokens?  ... View more

Sorry for taking this long, I was expecting an email notification.    A Velocity-powered email can be  way  more dynamically personalized than "Dynamic Content" allows - for example, using the intersection of multiple fields + multiple segments at the same time to determine final content. With regard to this, I think I see what you mean. In a dynamic email you can basically use one segmentation, like say language. But if you had content A and B in each language, you couldn't reach that depth, and you would need a more complex segmentation combining both language and somehow also A and B contents. So I take it that this would be achieved making use of your "tokenception"?  Have contents A and B in a script and have one version of this per language, then reference that token based on language segmentation (for instance) and let the script token give your lead A or B based on whatever rule in the script?  Maybe even ditch the segmentation altogether and use a script token (or several) for the email body that changes based on your country field.  Is there an example of tokens referenced in tokens that you can show me? Even a simple one? Maybe in your blog?  Do they have to be on the same folder (scope) ?  This is perhaps what you mean https://nation.marketo.com/t5/Product-Discussions/Referencing-local-tokens-in-an-email-Velocity-email-script-token/td-p/44812 ... View more

Hi @Iryna_Zhuravel4 ,    Could you maybe share an example of how scripted tokens make things more scalable or an example use case?  I think tokens can be intimidating for a lot of people using Marketo, and script tokens even more so.    The way I understand it is:  Instead of making emails dynamic you use a static version of them and all text blocks are a script tokens?    How do you handle common "tokens" like dates and times ? Do you reference the field directly from the code? Because you can't put tokens inside tokens (sadly). And the blocks... do they look at some translation file for each email to show based on some "preferred language" field on the record? Or maybe you are using localized tokens?    Also @SanfordWhiteman did that infographic ever see the day of light? Or maybe a blog post? 🙂     Thanks!  ... View more

Hi Lauren,  You can go to "Field Management" in the admin tab, look for your field and then check the "Used by" section.  This will give you a (non-exportable, sorry) view of everywhere that field is used, including lists, campaigns, forms etc.  According to Sanford's feedback, it is not recommended to mass update forms.  It is recommended to use (a couple) "global" forms, where you control which fields to hide or display depending on context. You need development for that approach though...  The "used by" section will probably be your best option to at least have a comprehensive reliable list of everything that needs changing. ... View more

Not only is this useful when discarding a field, but when troubleshooting, and very useful when you inherit an instance and you are not familiar with it. ... View more

Say we have a case of "Episode II: The GDPR Strikes Back" and we need to modify ALL forms with an additional checkbox... Episode V tho. Haha, yes, sorry I meant "the first, second movie" that was released. I guess the fact that they started with the fourth movie confused me for life... It's possible to mass modify all forms with this same modification via API? Yes, but it's certainly not worth learning the Forms REST Asset API for this. It would be easier to add the field using the Forms JS API (in the browser). Even so, how many forms do you have?  This is a good reason to have < 10 global forms, or centralize your forms starting now. So, learning how to use REST Asset API for this is a worse investment than doing Forms JS API with a reduced number of global forms? Yes, I would love to use less forms, but at the moment we have way more than 10... We are in the process of cleaning assets as I said. I take it you mean by using JS, you can transform your global forms into any other form you need by hiding or showing what is asked (how do you handle different "mandatory field" requests like this?), giving them different shapes according to the situation. Are you also using a "dynamic label" solution for this? I mean changing labels according to country using something like a translation file. The advantage of JS API would also be that you are "reading" and not "writing"? So you are chosing to show or hide something on the fly, but not actually modifying the base form? I'm unfamiliar with this method, could you share a resource to check out? Your solution seems to work by sending something like a "heartbeat" for every form right? How are you collecting and reporting on that? Right. A synthetic Visits Web Page event to be exact. Then run a Web Page Activity report. I'm also unfamiliar with this. I know how to pull a Page activity report, but what is a synthetic "visit web page" event mean? Did you tweak that event (unfamiliar with "events" in Marketo I have a very high level understanding of this concept in general: a specific circumstance you can somehow listen to and trigger actions from once it happens) so that it shows form id on the report? Or you tweaked the report? You said you are using the Munchkin API to generate an activity on people's logs showing the form that was loaded? ... View more

Hi Sanford, I'm very interested in two of the answers: Are we able to append fields to existing forms using the update endpoint You add with the /fields.json endpoint. Say we have a case of "Episode II: The GDPR Strikes Back" and we need to modify ALL forms with an additional checkbox... It's possible to mass modify all forms with this same modification via API? (If yes, I wish I had known and I really need to look into becoming a developer) I imagine that this would also be a case of "With great power comes great responsibility" since you could also break all of your forms in one fell swoop, which would bring me to another question: Could you export all of your form's current settings / setup as a backup? Is it possible to see what non-Marketo pages are using our forms? No, not if you haven't already set up some kind of auditing process (i.e. using the Munchkin API to send an activity to Marketo when a form is loaded). This a very interesting setup, could you share a little more information on this? I'm a total stranger to the API world, but I feel like I should get to know it better. Currently we are in the process of "spring cleaning" (#globalwarming) and would like to inventory all of our assets to determine which ones are currently active. With landing pages we could run reports, but with forms I'm not sure about how to determine the ones currently in use, so I suggested we (and by we I mean them, our developers) build something like a web crawler that looks for all embedded forms (since this seem to be a preferred method for injecting them) in our website and lists at least their form ID. Your solution seems to work by sending something like a "heartbeat" for every form right? How are you collecting and reporting on that?  Thanks! ... View more