A Top-Rope Dive Into Custom Objects and Velocity

Transcript

Sanford Whiteman here, Chief Technologist at Technical. But you know me as the Community Moderator on Marketo Nation and from my blog, blog.technical.com. Today we’ll be talking about Apache Velocity and both Marketo and CRM custom objects, followed by a Q&A on all matters velocity and CO. Apache Velocity, long time template language, is the heart of Marketo. You may not know this, you may know Velocity from its use in Velocity My Tokens and custom code written by Marketo users, but Velocity is actually the underpinning of the entire Marketo SMTP infrastructure. It’s not part of the rest of Marketo, the landing page infrastructure and the other elements such as webhook calls and so on, but Velocity does indeed power every single Marketo email, whether or not you write your own user land My Token. What I mean by user land is you open up the email script editor, type some code, test it, debug it and so on and you feel that you own that code that’s in your world as a Marketo user. But even if you don’t have any user land My Tokens, Marketo still compiles your entire email as one big Velocity template. The same concept that’s used in CMSs and all kinds of other apps that consume that same Apache Velocity engine. But again, within Marketo, Velocity is used for email content only. Velocity is the only way to output custom objects, period, anywhere in Marketo. You can of course use custom objects in smart list filters. You can sync them, both CRM custom objects and Marketo custom objects, which are imported via CSVs or using Marketo’s own REST API. But if you want to output custom objects, you can only use Velocity. That also means, by the way, you can’t output native custom objects or CRM synced custom objects on landing pages. But today we are talking excitedly, happily, about the email content world. Velocity is the only way, it is an absolute mandate, if you’re going to put custom object content in your emails. Velocity is also the only way to correctly URL encode other fields in Marketo. We won’t go as deeply, if at all, into that area today. But using the Velocity escape engine and escape tools is critical to using certain other fields in links. In brief, sort of, Velocity is a 20-year-old legendary template language. It was designed originally for Java developers to ease text output. We distinguish, in this case, text output from binary output or any other type of action that a language might take. Also it’s designed for CSV output, JSON output, SMTP and MIME output, as in a Marketo email, and anything else that you would consider textual. It can’t do things like write a PDF or write an image, but it is designed for anything text-based. So even back in the day, this is in the late 90s, we’re talking about Java developers, even expert Java developers, were frustrated by how hard it was to do basic text output from Java. So some of the most expert Java developers at the time, people who are still involved with the Velocity project to this day, which is great, put together the Velocity engine. The Velocity engine is for easing text output. It was originally designed to be used by Java developers. That’s in fact why there’s quite a learning curve. Today is not going to get us over that learning curve. If anything, it will just be a brief intro into what that learning curve can be, how you can make it a little bit less steep and some other things to look into. But indeed, if you consider Velocity as originally a Java developers tool, that should tell you the expectation of the original group. They put this together. Velocity supports dynamic data types, unlike Java, which is always strictly typed. However, as we’ll learn a few slides from now, it’s best to think of Velocity as strictly typed. You’ll mess up less if you think of it as strictly typed, like Java. Velocity also includes simple loops and conditions, the for each statement, the if statement, and so on. Specifically, the for each statement, which iterates over a collection, didn’t exist in Java itself at the time that Velocity was developed. So it was a huge advance, even for the Velocity and Java developer community to have Velocity at their disposal. Velocity also gives, and here’s a major reason why you shouldn’t think of Velocity just as a scripting language or something disposable, Velocity gives access to raw Java methods. That means that if you really look at everything that Velocity can do, you need to go way beyond the Velocity documentation itself and deep into the Java docs, the JRE6 docs specifically, and you’ll learn that there are 500,000, even 800,000 different methods you could possibly call from the Velocity engine itself. And that’s because it’s a bridge to Java. Let’s talk about what a template language is for a moment. I refer to Velocity as a venerable template language, right? Everybody loves it. It was loved back then. It’s still loved today. It’s still evolving. What is a template language? So a template language combines a data source with a template that includes both static data and dynamic instructions or code to create a final result. Here in the diagram on the screen, you can see we’ve got two different types of template. You’ve got one template in the upper right, which is your, I’m peering in to look at it myself. It’s your row output template that is able to combine Velocity code with a data source to create a CSV. The lower left, you see two different templates that are combined by the Velocity template engine to output one email. So it’s possible to use the same data source. In this case, this is the product info data source for an imaginary company. You can use that data source combined with different Velocity templates or any template languages templates. This is not Velocity specific, but rather how template languages always work. You can combine those templates with the languages own internal mechanisms to create any kind of text output you want. As you can imagine, that was a great opportunity for the original developers of Marketo to say, Hey, we’re going to have an underlying MySQL database, or let me not out it as a MySQL branded database, any SQL database or any index database of any kind. We’re going to have a template engine. We need something that’s trusted and we’re going to be outputting text. An SMTP message, aside from binary encoded attachments, which Marketo doesn’t do anyway, is a text message. It’s got a text plain part and it has a text HTML part, but those are both forms of text. So they’re perfectly suited for a template language, which is designed to take data, combine it with a mergeable template with its own internal content and come out with a final text product. Template language syntax always looks similar across the different template languages, but never identical. So here I have an example of doing roughly the same thing in Velocity, the top most example in JSP or Java server pages, another older template language format and handlebars, a very popular template language that has been designed only, I think in the last 10 years or newer. You can see that the syntax is somewhat different, but also generally focuses on the same idea, a limited set of iteration mechanisms and a concept of a loop. And finally inside the each statement in handlebars or the for each in Velocity or the for statement in JSP, you see a combination of static output and dynamic output. The static part are those opening and closing P tags. They’re just plopped right inside the template. That’s of course something you can’t do in most traditional languages. You can’t just put random text inserted among your code snippets. Here in a template language, we see a good example of how you can just put static text, opening and closing tags inside a loop that is accompanied by dynamic output. The dollar sign curly brace I in the Velocity example, the percent equals I in the JSP example, and finally the double curly braces classic handlebars output, by the way, that’s what we call that, the classic handlebars format for the act sign I, which is the name of the variable. In all three cases, we have a way of referring to iterator variables inside a loop. We have different ways of saying what’s code and what’s static, but in all three cases, there is a similar concept of looping structures, control flow concepts, and static and dynamic data together. So perfect again for outputting an email, which is ultimately a multi-part text output. Back to Velocity’s history for just a moment. And I do think it’s important to know this if you’re working with Marketo to know that it’s based on not only legendary, but rock solid technology now sponsored by the Apache Foundation. Originally, I think it was an offshoot separate open source project, but later was owned by the Apache Foundation, which is a great thing, as you probably know. The developers, original developers still work on it, which is almost disturbing in a sense. Some of them are even older than me and I see them in there on the community, still fixing bugs, coming out with new versions, the Velocity 3.0 version, which Marketo does not use yet, just has come out this year. Lots of great updates. It was designed, as I mentioned earlier, as an easier to use template language for Java Dev. So the people that wrote it, who wrote it in Java, if that’s not too confusing, were also trying to make their own jobs easier. It’s great that the original team is still there because some bugs here and there do come up. I found a bug in the MathMax method, for example, six months ago, and that was fixed in the latest version of Velocity. I haven’t blogged about it yet, but in Marketo you do need a bit of a work around. But having those original people involved in their great, very humble group of developers, unlike certain other open source projects where they may resist a pull request, it’s very easy to get the attention of the guys over in the Velocity project and say, hey, maybe we can have this new method added and so on. Velocity is also used by some major apps. I didn’t know that Amazon AWS API Gateway was using Velocity until I was writing this language and realized, hey, this has very similar syntax to a Velocity template that I’d already been working on in Marketo. I looked a little closer. I looked at some of the exposed methods and I realized, although it’s, well, sure, there’s a line item about it in the Amazon documentation, I hadn’t quite realized it’s exactly the same language. At API Gateway, you create templates to process incoming HTTP requests, pivot them, turn them into other JSON requests or form encoded requests, whatever you need to do to pass through an HTTP request to a remote gateway. That’s really what an API gateway is, right? It’s transforming text data that comes in in one format into a different presentation of that same text data. So again, perfect application for a template language. If you want to think about the solidity of Velocity as an engine, not only is it used to compile perhaps billions of Marketo messages a day, because every Marketo email is a Velocity template, but it’s also used to process, I would venture to say tens of billions and over the course of the year, maybe up into the trillions of messages that go through AWS’s API Gateway. It’s also used as a customization language for JetBrains who make IntelliJ and WebStorm and PHPStorm and so on. This Velocity language, far from being a Marketo only technology, is something that Marketo’s original designers very wisely incorporated into the product as the core way that emails are assembled. We still see it to this day being respected by other major vendors in different parts of the tech ecosystem. So somewhere else in your stack, there probably is something else using Velocity, or it’s somewhat similar contemporaneous technology called FreeMarker. Similarity there, I believe the Marketo community, which is based on a commercial hosted app, I believe that that community even uses FreeMarker that looks a lot like Velocity. So the context of Velocity is just everywhere around you. I know here that open source part is great for debugging. It’s good for me submitting a pull request and getting it updated in the latest version of Velocity. There’s a bit of a drawback, we must admit. The drawback is not that something is open source. The drawback is that open source makes you think that all the bugs have been fixed. There’s a difference, of course, between fixed and fixable. That’s why it’s great to have something that’s not only open source, but incredibly popular, well maintained. Again, those original engineers still in it who understand from top to bottom how it was originally built and how it can be fixed. So I think it’s great to have not only something that’s well known and well used, but something that you know is undergoing continuous revision and bug fixes, not just you could, but they do. Excited as I am about Velocity as a technology, my discovery that it is so respected and also is the underpinning of Marketo, one of my obvious specialties, we have to be realistic about the learning curve for Velocity. Velocity is not just an easy scripting language. As I mentioned earlier, there are hundreds of thousands of methods that you can call from Velocity. You’re not obliged to call them, but the fact that you can call them and that in many cases calling those methods is an alternative to either giving up or writing very, very convoluted built in Velocity code means that you have an automatic curve built into the back of your mind, even if you don’t need that for today’s project. The pessimist hearing what I just said says it’s code and runs away. And it’s true. I don’t want to tell anybody who’s writing Velocity that they’re not writing code. Quite the opposite. I think that if you master Velocity and its strict data types that it inherits from Java, you will be a much better coder than even, frankly, some of your fellows in the IT department or on the web team. No offense to those people. Of course, I’ve been those people myself. But when you use a dynamically typed language like PHP or JavaScript, both fine languages, JavaScript, I especially love, but you’re cushioned or buffered against the impact of type mismatches and type differences. So learning Velocity and understanding that if you treat it the right way, you learn about the difference between floats, currencies, longs, doubles, strings, date-like strings, Booleans and Boolean-like strings. Understanding those differences helps you communicate with your peers in the IT department, helps you communicate upstream to marketing leadership, martech type of people. And also helps you, quite frankly, in your career. The ability to go to any new company and say, I understand what a Boolean is. I don’t just say Boolean offhand. I really know that there’s a difference between a unique Boolean type, true or false, and things that we treat as Booleans, but actually have the string values, yes and no. Of course, if you are a long time veteran of Marketo, even using the UI or simply using Marketo forms, you already know about these nuances. You already know, for example, that true or false on a form for a checkbox is actually stored and passed on the wire as yes or no. But that’s just an entry point to the types of data type quirks or interesting experiences you can have in Velocity. But again, yes, you could say it’s code. I don’t want to be a coder. But of course, you probably wouldn’t be in this session if you felt that way. I will tell you without any exaggeration that if I meet another expert Velocity coder, I’m pretty sure that if that person hasn’t tried it yet, they could be a master Java coder, a master Python coder, even a strongly typed and traditional language like C++ or C, because having those data type awareness in your head is so important. SQL as well, understanding data types in SQL and how a date-like string is very different from a date as far as sortability and indexability. All of these things come into play. All of these things are things you need to know to write advanced Velocity code, not necessarily what you need to know to write basic Velocity code. So don’t get me wrong. You can write a few lines extremely successfully with just an ifs, else, and endifs. Extremely easy to do at that level. But I don’t want to frame the entire language as easy. That would be a gross misrepresentation. The optimist or I’d say a person trying to cushion the blow will say something like, it’s just if then else or it just does ifs and for-eaches. That’s not really fair either. And in fact, making the language appear to be easy to master ends up having blowback. If you tell someone, oh, you can do this, and then they put it into production, they don’t really understand what they’ve written. They don’t understand why sorting a list of custom objects on a nullable field and throw that out there is something we’ll explore perhaps in the Q&A, why that doesn’t work, then you’re setting them up for some degree of failure. Maybe they have to pull that campaign. They have to explain to their boss why it didn’t work or why some people in the campaign didn’t receive the expected personalized output. So you don’t want to say that a language like velocity is quintessentially easy. It is sort of neither easy nor hard. You can make it easier. You can make it very hard and very complex. So of course, I put myself in that third bullet there of the realist. The low end, you can do some easy stuff, but you always have to have in the back of your mind there’s some hard stuff waiting. And on a dime, your boss or other business requirements might dictate that you dive into the hard stuff. For example, someone might want a simple sort of the custom object list, or maybe just to print your custom object list in an email to your subscribers. And then somebody says, well, we really want to format the currency in the person’s known locale. All of a sudden you’ve gone from basic output of the field exactly as is in the Marketo database to using locales, which are a whole concept in and of themselves, using locale output, casting number like strings to true numbers, and then formatting them using the local aware currency capabilities of velocity and velocity, by the way, together with Java can do all those things. It can output currency in euros. It can’t do the conversion. Of course, we’re not talking about getting the up to date exchanges, but it can format using European language styles where the commas and the decimal points are used differently from where they, how they are here in the US. It can do all that stuff. But when you go from just a simple printed exactly as it’s stored in the Marketo database to format it slightly differently, according to the lead specific basically 47 language code region and language code. You can immediately leave from the basic side to at least the medium side and velocity. So be aware that’s always waiting for you in a great way. Means you can do a lot more and it means you don’t have to say to your boss, oh, I don’t think you can do that. It just prints stuff out. So again, being realistic means that you’ve got the strict type stuff to help you learn and better your career. You got some basic stuff too. You certainly can do basic if and else things, but it doesn’t stop there. Here’s some key tips. We don’t have nearly enough time today. I could do an entire presentation just on annotations. In fact, in a training session I did recently on velocity, I think I spent 40 whole minutes talking about the nuances of annotating your velocity tokens and annotation is merely a matter of doing consistently formatted comments. I mentioned here using the requires tokens annotation, the requires object fields annotation. I’ve been able to infect a few of my peers over at Percuto. Justin Norris has a nice piece where he talks about annotation, but those are my ideas. They’re not universal standards, but they make your life a lot easier. But again, this is just scratching the surface in a single line item on this slide in the Q&A and in future blog posts, I will be exploring all of these things. You need to stay hyper aware of data types. I know I said that just a few minutes ago, but if you blunder into thinking, for example, that a Boolean field is going to come out as true or false, as opposed to quote one, the numeric string one, or quote zero, the numeric string zero, you’ll mess up your comparisons. And of course, if that’s conditional data you’re sending to your leads, you’ll end up sending them the wrong data, the inverse of what you expected. Not to scare you, but you do need to keep data types always in mind. Data types also affect comparisons and sorting. You can’t sort on mismatched data types. You can’t compare fields for equality that have mismatched data types. So you can’t compare with accuracy, let’s say with full accuracy, you can’t compare a numeric string with a true number or a decimal with a numeric string that kind of looks like a dollar amount. So you need to know about these things. The third sort of keyest of all the key velocitives, and you can see this as something I put in the Marketo community all the time. When someone posts code that otherwise works, admittedly, I will almost always, if I remember I will remind them, use simple reference style. Simple reference style is just a dollar sign and then the name of a variable in Marketo, as opposed to the dollar sign and the curly braces that surround the variable. The formal reference style has its place in output, does not have its place when you’re doing sort of the more code lifting, method calling, reference nesting, all of that stuff you want to use the dollar style, which is the dollar and the variable name, not the dollar and curly braces side. So those are about the three. I could probably have 10 other tips that I consider, frankly, equally important, but I decided to select three key tips for learning velocity today. So every velocity variable is a Java object. It’s not a sort of simulacrum of a Java object or some sort of simplified version of a Java object. It’s a real live Java object. So if we create a string in velocity, we use the set method to do set dollar my string equals quote Sandy, right? I just dictated code out loud, not a really good way to learn code admittedly. But when I do that, I create a string. And when I say a string, I mean a true Java, Java version six, it’s JRE six still is in use the string. And you can see in this slide, just a tiny version of a tiny subset of the number of methods that every Java string has. It has methods like contains and index up and capitalize and to uppercase and conversion to Unicode, all manner of things you can do with these objects that are completely dictated by the Java docs for that object type. People often wonder why are the velocity docs so spare? Well, there are two things they’re spare and also kind of underwritten and difficult to understand. Perhaps that was three things. Perhaps the most notable part of the velocity docs is you go to the velocity site and you start clicking around and you think, is this all there is? Where’s the real documentation? Well the reason that there’s not any realer documentation than for the tools like escape tool, sort tool and date tool, those are part of velocity. The reason that there isn’t further documentation for concepts like string contains or string to uppercase is that all of that is expected to be found in the Java docs themselves. So this snapshot on this slide is taken from the Java docs over at, I think there’s still the older legacy docs at Oracle, but now there’s open JDK now that the JDK has been open source and so on. But these are, this is the JRE docs. So there’s a very good reason why velocity site itself doesn’t simply mirror or repeat this stuff. One of the reasons is, as I mentioned before, velocity was originally written for Java devs. So Java devs would know intuitively, Oh, this is a string. So I’m going to go to the JRE docs and look that up. But another reason is that even if you didn’t know that you’re sort of faced with the question, it wouldn’t make sense to simply repeat or copy and paste things from the Java site. That’s all open source. I suppose it could have been done, but the implication of the brevity of the velocity documentation is that you’re supposed to supplement that documentation with a superset of all the methods and all the hundreds of thousands of things you can do with these Java objects. So again, every velocity variable is a Java object. In this case, we’re looking at simple objects like string. If you create a number or see a number in velocity, it’s a true Java number. It could be a long, double, et cetera. You get all that information of what you can do with those numbers, extracting them, converting them to big integers, extracting bytes from them and converting them all every which way. You get that from the Java docs, not from the velocity site itself. But one thing that velocity did, and here we’re bridging into custom objects. That’s what today’s session is, of course, about both velocity and custom objects. I think it’s key that you understand what velocity is, be excited about it, understand how respected it is in the industry as a whole. But we also have to figure out why is it so intimately linked with custom objects. As I noted, velocity is the only way to output custom objects in Marketo or in Marketo email. So key to understanding that in turn is understanding what an object literal is in velocity. So velocity brought this concept of just creating an object in the simplest possible syntax to Java before Java itself had it. If you’re a JavaScript developer or to some degree, even like another language like PHP, you may be familiar. In fact, so familiar, you may not even think about it being rare. You may be familiar with the idea of setting a variable to a nested object. Maybe you have an array and inside that is a classic JavaScript object. And inside that is another array set to one of the properties. And you may think, well, that’s nothing special. Of course, I just set variable equals something simple, as we say here, similar to the first entry here, setting a variable called $ALIST, that’s the variable named ALIST, to this array like structure, quote one, quote two, quote three, an array of three strings, right? In Java, at the time that this became possible in velocity, you couldn’t do it in Java. So it’s not redundant. It actually was a tremendous advance at the time. Java has since caught up. So since Java 8, and especially since Java 10 and 11, and frankly, I don’t even know what the latest version is, 14 or 15. I don’t keep track of it because I know I have to keep my skills fresh for the old stuff. But in Java, at the time that velocity made its debut, you couldn’t do something as simple as declaring a variable and setting it to three strings and have that become a list. Similarly, you couldn’t create what looks like a JSON object or JS object in that similar way. Now you can. In velocity, you can do set the variable, a map dollar a map to this key value pairs. You’re very familiar, I’m sure, with this look where the left hand side is the key and the right hand side is a value. So its first name is Sam, last name is White. That’s incredibly obvious, right? But in Java, at the time that velocity brought this to the Java ecosystem, you couldn’t do that. You had to use methods like add and put and so on. And it was very Cody or what later became in fact thought of as like tools ish or even Java ish. There’s sort of a whole Java style of verbosity that velocity to some degree helped alleviate. Java is still verbose. I love it for that reason. It’s also linked to its strict typing and the controls that it places on the mistakes you can make. But at the time that velocity came out, this was a godsend for Java devs because they wanted to do rapid development. I suppose back then we would still say rapid application development, right? And say they want to do rad development of websites. And that’s kind of difficult in pure Java because it’s so verbose and it’s so exact. Whereas in velocity as shown here, they could declare an object easily, set keys and values and then start working with it within the template language. So really a tremendous advance for the time that you might not be aware of. Again, the objects so created are true Java objects, meaning that their documentation is the Java docs over on Oracle’s site. So custom objects and velocity have an intimate relationship. Velocity of course is the heart, as I mentioned, of Marketo. Custom objects are optional, but once you use them, you’re pretty much bound to using velocity to access them and put them in your emails. In fact, if you don’t have a little bit of knowledge of velocity, you probably shouldn’t go down the road of custom objects. You’ll just end up displeasing people who think that you have equivalent access to custom object fields that you would have to standard flat lead fields. You can output a lead field as a lead token that’s all built in. If you had a custom object, it can be very robust and have these great relationships you can see in smart lists, but you may not be able to output it unless you use velocity. Or I should say you will not be able to output it unless you use velocity. The complexity of that velocity is of course what flexes a bit with your business requirements. So in brief, custom objects in Marketo are a supplement to the flat fields you get on leads. They’re also a supplement to the new program member custom fields, which as you may know, are program level flat fields, let’s call them. They’re not as a whole flat because each lead has a variety of program memberships. And so from within each membership, you have another layer of flat fields, incredibly valuable by the way. And in fact, as I’ll note in a few moments, there are things you can now do with PMC apps that you used to have to do with custom objects and you no longer need to. So that’s great. But custom objects supplement the world of flat fields, those fields that we put in field management right on the person and PMC apps, which are a little bit more multidimensional. They’re a fully expandable, relational, user controllable compliment to the Marketo lead database. You can have one to many relationships between a lead and we’re going to favor those one dimensional relationships by the way. I do want to put that in your head right now. I love what a second level and multilevel relationship can do. I’m not going to talk about that in the CRM and the SFDC side, but in Marketo, from the velocity standpoint, you want to favor single level object relationships. And I’ll explain why in a moment. So again, this doesn’t defeat my love of multilevel custom object relationships, but just keep in your mind that probably an asterisk connects to the first level ones. But a one to many relationship is a first level relationship where a lead has a connection to an unlimited, let’s call it a practically unlimited spread of custom objects. And each of those custom objects has their own leads, strongly typed fields on those custom objects as well. A many to many relationship allows multiple leads to share connections to underlying objects. So many to many can mean that multiple leads each have access to a product list intermediate item, and then those product lists can be looked up in a list, a master list of the products in your catalog. For example, that would be one of an infinite number of second level relationships where each, again, each lead has a set of custom objects corresponding to their purchases. And those purchases have a relationship to a master product catalog. That would be that second level relationship. In CRM, ironically, perhaps, especially in Salesforce, you can have very complex master detail lookup relationships and have them still work in Marketo, even in velocity. If you use Marketo custom objects, though, you really want to use, and here’s where I told you to put that asterisk by the single level objects, in Marketo, you probably want to use first level relationships. Still, I’ll give you a kind of a comparison of the single level and the multi-level worlds. Here’s a quick example of different types of custom objects. In one case, we have a touch point custom object for attribution web activities. In the next, we have a list of purchases. We have the idea here of a lead that has a list of touch points, their first touch, their ongoing touches, most recent touches, important touches, interesting touches, and so on. Each of those would be multiple, fully flexible objects with their own leads detailing an exact event in time. And then, of course, purchases. Similarly, they capture an event in time and they’re not overwritten, unlike a lead field, which of course can only have one value at a time at any one point in time. So overwriting lead fields with this kind of information would be quite disastrous. Custom objects can maintain a chronological time series of data over time. That’s one way of looking at them. A time series of snapshots of data over time, all of which contribute to your leads engagement and what you want to do with that lead as you continue to nurture them through the process. So again, the example here is a lead that has relationships to two different first level objects. Touch point list is first level object and their purchase list is first level object. The multi-level schema represents, as I noted before, potentially a shared object. Here we have the product catalog on the right, that’s your product list. Then we have purchases. So multiple leads have multiple purchases over time. And each of those purchases link back to a master list of products in your catalog. As exciting and awesome as this slide is, from the standpoint of a presentation only about custom objects, I would say this is great. But a presentation like today’s that concentrates on velocity and custom objects, you really don’t want to do the multi-level. I apologize, and we can talk about it more in the Q&A, why and why not, but you’re going to want flat objects if you can. If you create a second level hierarchy with Marketo custom objects, it’ll work fine in smart lists. In fact, you can do really cool things with it in smart lists. Don’t get me wrong. When you go to output that data to tell someone, for example, let’s say they had a list of purchases and you want to also output the products that they purchased, suddenly you’ll reach a dead end. Those second level custom objects, that deeper level that’s the product catalog is not accessible from velocity when you use Marketo custom objects. For a time it was on the roadmap and I think that maybe that just got derailed. But now the only way to go to the second level or even second plus level stuff is to have it be CRM synced custom objects. So again, Marketo custom objects should be flattened. Purchases should include the copies of the product info. So you would still have your purchases, your purchase custom object, that’s a first level object, but each one would contain a copy of the product catalog data from that point in time. It’s unfortunate, but true at this point in time, we need to do that. CRM COs, as I mentioned, you can go way deeper, but make sure to test. The key point is the third point, and this is where I think what seemed to be simple velocity projects, even simple velocity output projects where you’re just doing a little if and else if can get way more complex. And that is that in a trigger context, in a batch context, and even the preview and the editable web preview within the editor, you can see different data. Sometimes you can see, I shouldn’t say different data, but in some cases missing data, either data or no data. There are rare cases, you can always ferret them out through sufficient testing, but there are rare cases where a custom object is viewable using the preview mode, but isn’t viewable using either batch or trigger mode. That only happens when the relationship is more complex than Marketo can really handle. And that can only happen in turn when it’s a CRM synced custom object. That will not happen ever, I should assure you. That will never happen with a Marketo custom object. A Marketo custom object has a far more replicable, predictable level of visibility. But CRM COs can do some interesting things where you think you’ve got them in all the places that you want, but suddenly you go to output them in a batch email and they’re missing or you go to output them in a trigger email and they’re missing and boy, that can be frustrating. But so test, test, test. And again, we know as a part-time SFTC admin, I’m sure some people watching are full-time SFTC admins, you know how many different interesting relationships you can drag around in SFTC from master detail and look up and formula and so on. So you know, you have all that flexibility in there. So every change like that definitely should go through a change management process because it can affect the visibility of those custom objects within Marketo. Talk about a few cases as excited as I am about custom objects in general, good and bad cases for custom objects in Marketo. A good thing, as I mentioned, would be the attribution touch points. Something like Bizzable, for example, does that same thing with SFTC objects that in turn could be synced over to Marketo, but you can build Marketo only structures for attribution touch points. Form submissions, as you may know, are not real first class objects in Marketo out of the box. If I submit a form with certain values for my flat fields and then submit another form later that very day or a few minutes later, it will overwrite the original values. That can be frustrating because we might think of a form submission as a unique unit of engagement. We want to encapsulate everything that was posted on that form at one time and not lose it just because somebody submitted another form that has similar fields or the same fields being used for the same purpose. So what you can do if you create the infrastructure to do this is you can have your form submissions turn into form submission custom objects. Then you have that many to one relationship and nothing gets overwritten. Asset downloads a similar idea. Sometimes a client will want to have every asset downloaded, have a timestamp, its source campaign and other things associated with it. If that’s not tied to a program, which it might also be, but if it’s not tied to a program, that’s a great example of where you create a custom object for every asset that somebody downloads so that you can then chart their progress based on those interactions. Products and warranties. I probably should have put this as my top most bullet point because more often than not it’s sales side stuff that’s stored as custom objects is so incredibly powerful for the marketer. So the product somebody owns, the products they’re interested in, which could be derived from machine learning or from their own choices, the warranties that they currently own for products in the past, all of these things are incredibly powerful. By definition are many to one with our leads. There’s no way that we say they only own one warranty at a time. There’s no way that we say they only are allowed to hold one product or that we have to create individual flat fields for each product or product interest. That is the golden zone for custom objects. Recommended content, cross referral info, where it can maintain how somebody is referred to your company on one lead and the lead that referred them can have a link back to that referral. That’s a great kind of setup for custom objects. Appointment bookings and other sort of isolated activities that may not be at the program level are great. So for example, we use Calendly. When someone books an appointment via the Calendly link in somebody’s signature, we write that back as an appointment booking custom object that gets attached to the lead. So that’s obviously a clear form of engagement. It’s usually with inside sales and so on, but it’s something that you could make a lot of use of in Marketo if you knew someone had not just clicked the link, but they had clicked the link to open up Calendly or similar software and created an appointment and then write that back to a Marketo custom object. It’s great. Of course, if you want to remind them about that and interact with them, you need to use Velocity. One area where I don’t think custom objects are necessary any longer is program member custom field stuff like attendance details at a webinar. Now that we have PMCFs, assuming that your provider or your custom integration can use program member custom fields, again, I am talking about the theoretical technical ability of PMCFs, not so much whether all integration support PMCFs, but they seem to be more purpose-built for this feature. For example, rather than creating a custom object for the number of minutes that somebody watched a webinar or the questions that they asked during the webinar or the classic idea of what their favorite food is back when we used to all eat in the same place at a buffet at an in-person event, that stuff now is totally geared for program member custom fields. So I encourage you to encourage and turn your integration partners, the people that you’re using for those services to start using program member custom fields because you really don’t need custom objects for them anymore. Language preferences, I just want to throw in something where you might think, oh, well, why don’t we use it for everything? One example of where you wouldn’t use it is something that’s actually universal to the lead. They may change their language preference, but there’s really no reason to have a one-to-many relationship for language preference. And there are basically anything where you’re doing just fine with flat fields and you’re not creating this proliferation of copied flat fields and constantly adding new ones, you’re probably doing it the right way without using custom objects. So to a certain degree, you probably know what you wish you could use custom objects for. Here are some great examples. As noted, first level objects are always going to be okay, whether they’re CRM synced, mirrored custom objects, or velocity custom objects, but the second level objects are only accessible if they’re CRM COs. Both can be used in smart list filters, but only the Marketo ones can be viewable in the lead UI. So it’s a great example for Marketo custom objects. You can pull down the list of custom objects and see what they own, see what they’re connected to. With a CRM sync custom object, you can’t do that in the UI, although, and this is a great reason to learn velocity, you can see the details of those if you use velocity. The velocity sort of substitutes for the Marketo custom object ability to drop down the list and see their currently attached records. You can use velocity to do a similar sort of interrogation. In this case, it would be more for you not to send to the end user, but something you use only in preview to see the details of their SFTC sync custom objects, incredibly powerful for that purpose. Again, the CRM COs are read only in Marketo. The Marketo COs can be by definition, upsurge on the Marketo side, but the only the CRM CO is going to appear on both sides. So it’s, again, a tough choice to make. I’m not going to say that I’m coming down specifically on the side of CRM COs or Marketo COs, but they’re definitely good and bad. Neither type can be updated in the UI, so they can be viewed in different ways. As I mentioned, you can view the Marketo COs directly from the dropdown list and the tabs in the lead editor, which is great. You can view the CRM COs using velocity, but you can’t update them in the UI. You can’t type in the new date value field for somebody’s custom object record directly in the lead UI, the way you can with the flat fields. Neither of them can be used on landing pages and neither of them can be used in web hooks. That latter case, if you know me, you know I love web hooks and I’ve been frustrated many times with that, but they really only exist in full in smart lists and in velocity. Now, as I mentioned before, object literals were not possible in Java at the point that velocity made its debut, late nineties or around 2000. So the ability to declare something as simple as what you see here in the slide to set the variable called the list to an array of objects or something that you couldn’t do simply. Now that code that you see on the screen right here, this is exactly the same outcome as when Marketo injects custom object records into the velocity context for you to use. When I create this at runtime with my own user land token, I create exactly what you see here. I am creating an array list of hash maps, technically an array list of linked hash maps. If you want to go there, let’s just call it to be sort of simple, an array list of hash maps. And that is exactly what Marketo gives you when it injects serum custom objects or Marketo only custom objects into velocity for you to use. So a great rate of practice, key to learning how these objects can be manipulated, how you can iterate over a list, sort it and so on is knowing how to create a custom object list on your own or a fake custom object list and then iterate over that. So you don’t even need to create a Marketo custom object to do this. You can go right in declare, as we see here, an array list of hash maps and work on that for each over it, sort it by different fields, coerce the data types to make it more sortable, filter it to another list and so on. I do a lot of my debugging this way because on the Marketo community, someone will ask me a question and they’ll say, I have a custom object that looks like this. And while I might be excited to create a custom object that looks exactly like that, and we can run one of my test instances and play around with that. It’s a lot easier to just write code like this, create a synthetic custom object with the same fields on it, and then work on that because it’s exactly the same thing that you get when you get the real custom objects in velocity. Literals can also be used as lookup tables. That’s almost a whole other thing. Maybe we’ll get to it during the QA, maybe not. Another key, I’m going to get back to data types because I keep saying this. That’s why I say that learning velocity is about learning data types. It’s not really as simple a language as many would have you believe, because you need to know the difference between a string and an integer that just happens to look like a string and so on. The properties of the lead object are all strengths. Confusing? Sure. But they’re all strings in velocity. That means that if you have even a number field or a currency field, it’s going to end up being a number like string in velocity. It’s different for custom object properties. Custom object properties are in fact typed differently, but not the same types that they have in field management and not the same types in turn that they would have in your CRM when you created them. Only with some deeper inspection, and I have some boilerplate code on my blog that you can check out right now, only with deep inspection can you find out what the real data types are. But you need to know what those data types are. You need to know this date is coming in. Well, we know that dates are always strings. That’s a JSON thing too. So nothing really weird about that. We have to know though that the Boolean that you created in Salesforce, I think it’s synced over to a Boolean in Marketo is actually going to be the numeric string one or zero. That’s going to make a lot of difference about how you compare to it. So always code with that data type awareness. As I mentioned, a velocity custom object list is a Java array list of linked hash maps. Now the methods attached to these two object types in Java are at least briefer than those attached to the string. As I mentioned before, I had to sort of fade out the screenshot of the string docs from Java docs, right? Here, at least I can fit it all on the screen, but there’s still plenty to learn. You still have to learn all the different methods on an array list like add and contains an index of and last index of and so on. That’s how you sort and filter and do advanced things like that. Linked hash maps. You also have to know things like whether it contains a key to use the contains key fields. The entry list entry set incredibly useful when filtering and figuring out what someone’s custom objects really look like in velocity and which ones you want to output and how. So again, a limited list of methods, but not so limited that you would say, oh, it’s just the most basic array that has like an index, like a zero based index. And that’s a lot more than that. And that’s because they’re living true Java objects. So the fact that a custom object list is in fact a Java array list of Java linked hash maps means you can do simple things with those collections like sort or sort. Sort or sort is part of the sort tool. It’s one of velocity’s built in so-called generic tools. That means they’re tools that are, well, they’re able to be bundled with the velocity engine. It doesn’t mean they’re always bundled, but Marketo thankfully does bundle them as a counterpoint in on AWS, where I mentioned velocity is used for AWS API gateway. There are no tools. So it’s possible to have a velocity engine that’s just velocity without the tools. Great thing for us is that Marketo includes the generic standard suite of tools that includes the sort tool. So because you’ve got the sort tool, which is usually called sorter, you can do a sorter sort on that list by any properties. The reason that works is it’s a type of Java collection. It’s not some special, again, I think what I’m trying to impart is it’s not some special velocity only notion. It’s not an object that only velocity understands. It’s that velocity is kind of easier to use dialect to create super potentially complex objects and infinitely nested, in fact, potentially infinitely nested lists of objects with lists and objects and so on. But it’s basic form because Marketo exports your custom object list as an array list of hash maps, you can use the sorter sort on it. You can also look out, as I mentioned, for null properties, you will need to convert them to sortable properties. I think the final message to leave us with today, because velocity has such a potential curve that I couldn’t say, oh, in the course of a 45 minute presentation, you’re going to go from zero to say 20. I would say you go from hopefully zero to curiosity or zero to some future comfort level, zero to interest. I hope that you now want to learn a lot more about velocity, which is your only interface with custom objects in Marketo, as we know, for outputting custom objects and emails. To give you an idea, to go way back to one of the earlier slides, when I mentioned that depending on the person looking at it, velocity is either easy or hard. Here we see three different things that all seem, well, they seem like they’re on a pretty smooth scale from simple to pretty simple. But doing something where you just iterate over a list, which is that first example, to sorting the list, to then finally filtering the list, sorting it and outputting it, you can see how we take the simple stuff that kind of optimists take, that it’s just going to be a few lines. Suddenly it’s seven lines. Suddenly it’s 15 lines. And it’s not just 15 lines, it’s 15 lines that involve conversion to integers and understand that again, that’s that type aware part that I always talk about. Many blog posts about that that I urge you to read. But this is to me, this is the velocity curve in a nutshell. You could get a new request from your boss, a new ticket open in Jira or whatever you use, that suddenly takes you from option one up there to option three. And if you’ve guaranteed that you can deliver it in the same period of time, you know you’ve got some work to do. So it’s an incredibly exciting language. One of my favorite languages to kind of wish that people would start with, ironically enough, even as simple as it looks. And I think you’ll have a great time with it. Time for some Q&A. Thank you, Sandy, for the dive into custom objects and velocity. That was extremely informative. Now I’ve been watching the chat and there are a number of questions for you, no surprise. Very interesting topic. So I’ll let you jump in, Sandy, and start answering them. Great. Thanks. Yes. Fabulous questions. Scrolling by on the left. Let’s start with some of the top voted ones. One that I think I predicted and maybe even tipped you off to a bit during the presentation itself. Is there a recommended resource or site to take a deeper dive into velocity? I wish that I had an upbeat answer for you, but kind of it’s like my blog is the place. I really have become, didn’t really plan to, but have become the subject matter expert on velocity within Marketo or what I call Marketo flavored velocity in the title of the presentation. So I wish I could say, sure, my esteemed colleagues on blog A or blog B have some great stuff. And in fact, there is good work. I don’t mean it that way, but for a concentrated Marketo fluent velocity set of guides, really my blog is the best. However, Mea Culpa, I have not really taken it to a beginner level yet. And that’s where I think another question comes in, which is, are there beginner classes? Are my training sessions, which I alluded to in the presentation as well, are my training classes available on video or online somewhere? They are not yet. As you can imagine, doing a sort of free form adaptive class, I usually do a set of like 12 sessions is a lot easier for someone at least like me, who’s not a big podcast prerecorded video person. To create those 12 sessions is going to be something that’s going to take some mental energy that I would love to invest. And I almost apologize to the wider community that it doesn’t exist yet. I have been leading people through individual Zooms and group Zooms for the last few years and would love to take that to the next level. But at the present time, there’s nothing that’s, I can’t say yes, we have even session one of one of these training classes online. So my apologies, but the answer is not really. I think sort of to expand on the idea of deeper dive or simple template language syntax, one thing I was trying to impart during the presentation is it really just isn’t that simple. I’m not trying to scare you because I do think we’ll get to the next question, which is about upscaling and where this works on a career track. I’m not trying to scare you. I’m trying to excite you and get you to want to learn velocity and bring it into both your in-house marketing operations and into your career track as a whole. But it’s not like an overnight thing. And I do try to be as candid as possible when people say on the Marketo community say, wow, this looks great. You just gave me five lines of code and it works. How do I take it to the next level? And I said, well, you know, you will if your boss and if your organization gives you enough time to immerse yourself in velocity, you can learn a lot. If you’re just doing it sort of in that way, that frenzied last minute deadline was yesterday kind of way is probably not the best way to learn velocity. I’ve been very fortunate to be a not just a marketing developer, but a developer as a whole and have it be my career. So I have more time. It’s an advantage that I wish more people had. I also have the time to work overnight on a lot of projects that were because I’ve been working sort of asynchronously for longer than a lot of people have before this work from home in this sort of whatever trend overtook the world for obvious reasons. But to move to the career track concept, one person asked, do I recommend a functional understanding of velocity for all Marketo admins or power users or just a specific like marketing ops track career track? I think you can be a power user of the Marketo UI and be a great campaign builder and obviously a great understander and communicator of business rules without knowing any velocity. This gets to the question that I think has been coming up for the last three or four years. I remember when I first sort of became the JavaScript with forms guy with Marketo, as many of you may know, that’s sort of like my other subspecialty. And people would say, I have to you know, I have to upskill my my JavaScript. I have to figure out how to be a marketing developer. And I did a couple of interviews at the time and a couple of kind of free form chats. And we were talking about like, is marketing developer going to be a thing? And wow, I said I thought it would be I hoped it would be. But I think in a sense, my skepticism has been borne out so far that three or four years later, there still aren’t that many organizations carving a role. Again, that’s that role where you get to say to your supervisor, I need today to learn this language. I need today to figure out how the custom object data types work on our new custom objects we’re getting from the product team in Marketo. That situation where you have I want to say that it’s like veto power, but that it’s in your job description that you’re learning to code, that you’re bringing your outside development experience in and trying to meld it with your responsibilities as marketing operations person. So I think some of the key is that you have to be empowered to do that within the organization. I think there there should be more of a marketing developer track. But what sometimes I see is that somebody gets hired. We see these crazy job descriptions. I’m sure that some of you have seen this. We see the job description that’s like, you know, must have five years of Marketo. And five years of JavaScript development experience and, you know, like a back end, Java full stack developer or something like that. And I go, that’s not really possible, especially, you know, certainly if you’ve been maybe working for a very long time and staggering your career across different slices of the industry, you could do that. But the idea that like you’ve been doing all those things, you’re not just a full stack developer. You’ve got the myth that all start and it all pains out and you understand the nuances of engagement programs and things like that. That’s sort of a rather. That’s key. And again, people are unwilling to stay at the head count their budget considerations or a million considerations. If you don’t know what you’ll get out of that person, then it’s hard to figure out how to build that role. But yeah, I think so to sort of round up my answer there, there should be a career track. That track is marketing developer, I guess. Also, someone who can move fluidly in between the IT group. I used to be an IT person, as you can imagine, move fluidly through the IT group, get better communications going with all of your infrastructure team, also outside integrations, being able to speak fluently and get what you expect and figure out how those how and if those integrations actually work. There is a role there within marketing operations groups, absolutely within marketing groups. Are people, as I said, are people carving that out? Are they adding it to the org chart? It’s kind of like a catch them to write. I want it to exist, but if it doesn’t exist, we can’t prove that it should.

And and then there’s a question of what is the zigzag of that person? How does this person move up? I’d say the mobility there is possibly more into the IT group or building out bigger warehousing, working in the warehousing space, that space within the company, maybe not within marketing itself. So much bigger, interesting questions can happen. But as I said, I haven’t seen the move that people were hoping for, I’d say, four to five years ago. There would be like a marketing developer in every marketing group. I haven’t seen that. That’s the person that needs to know velocity for sure. And the person was able to say, I think had a slide on this.

The person was able to say, instead of going, I don’t think Marketo can do that. You have in the back of your mind, if we have velocity, if we have JavaScript, then yes. And so you round that up to yes. And you start saying that Marketo as a whole can do things that in a sense, out of the box, if you just looked at the docs, it couldn’t do them. But you can create much more confidence in the product and in your own work, because you know that with a couple of hours work, flipping some switches in velocity and so on, building out custom objects, as you mentioned also in the presentation, that you can you can make it happen. So I think that’s really it’s just really important to gain that the confidence that other people in the organization have. And it sort of ends up crediting Marketo, your platform choice and your own work with these great advantages. Right. Someone asked, of course, whether I hold velocity training sessions. Those are usually things that have been done, I think, internally within companies. So I don’t think I’ve ever had one that’s like multiple people attending one public one. But that may certainly may happen.

If you don’t have the link to my blog, by the way, blog.technical.com, I think it’s on the first slide. Definitely look there, because that’s the broader that’s the answer to sort of the deepest dive, the simplest, unfortunately, I think that’s the simplest way that this information has ever been imparted is on my blog. And even so, I will acknowledge that I probably started at a sort of intermediate level. I’m trying to get better at that. I know how hard it is to go from the idea that it’s a mild scripting language to me. Telling you that it actually is a strictly type Java dialect. And I know that that can be kind of intimidating.

Someone asked, is it possible to create one script token that works for both triggered emails and scheduled emails? Absolutely. Actually, I think I have a blog post about this from a few years ago where I show how to use the trigger object to switch between the trigger object, which is the special object that only exists in trigger mode. And if that trigger object doesn’t exist, if it’s null, we switch to, say, the most recent or the most interesting object in the custom object list. And you can switch that within one token. So definitely look for my blog on that, on automatically switching between the trigger object and batch mode.

Someone asks, is there a plan to add token usage in smart lists? Well, I’m not on the engineering team at Marketo, much as I do a good impersonation of such a person. But I don’t believe that there is any plan for that. Really, as a templating language, it wouldn’t be perhaps the most efficient language to look to use in that environment. If one were to add like an embedded method call within smart lists, I would love for it to happen. But I would say there’s almost no chance that it will happen. But boy, would I be happy. I think we’d all be happy. After a newsletter goes out, someone asked, after a newsletter goes out, can you change the link using velocity script? Well, the link that’s in somebody’s inbox can never be changed. That’s the, you know, once it’s received, that’s carved, burned into the received email. Interestingly, velocity is executed in page mode, though. So the answer, I mean, it’s 99 percent. No, I guess one percent is if somebody views that email using the view as Web page link that appears at the top or well positioned in every email, then you could make changes in velocity on the back end and it would dynamically change the links in the rendered email. But of course, that’s true of links in an email that are just regular links in the email asset as well. Those also get updated in real time. So that’s not really anything new. But no, velocity, like all changes to the sort of burned or flat body of an email, that can’t change what’s in somebody’s inbox and the redirection link that Marketo builds for using your branding domain that cannot be changed using velocity.

Someone said for the data sources, we obviously can pull from our internal Marketo database, but can we tie into an external data source? The answer is not anymore. A few years ago, you could pull in, you could do some cool stuff, you could pull in like an external Webhook based feed via velocity. It was, however, causing a tremendous amount of resource overhead. Thinking about the idea of using velocity to execute a remote HTTP caller database query for every outbound email was completely over the top in its usage. So we can’t do that anymore. You can, of course, use something like a Webhook to pull database. We do this a lot, actually.

Use a Webhook to pull records from a database into another velocity token using the WorkoutOS REST API. That’s a shared velocity token that would be like, I think I alluded to this, like the idea of a product catalog or a central dictionary of information, like it could be an RSS feed that you build out this way so you can build out like an RSS syndication type of feature. But you can’t do it with just velocity. You do need some sort of external integration. Like I said, you use a Webhook to trigger sort of loopback using the WorkoutOS REST API and write it to my token. Or you could use a scheduled task. It’s nothing you do with the Webhook and just writes it to a my token and then use that my token within velocity. So certainly possible velocity itself cannot pull from an external DB.

Finally, just about out of time, can we format dates in the LEED’s local language using the built in date tools? Absolutely. That’s like I feel like it was a planted question, but it was a real question. Sorry, that’s perfect. That’s that. Yes, absolutely. You can use Java’s locale awareness. It even has the awareness of the translations for the world’s major languages for all the months and days and all the months and all that’s built in. So you don’t need to build your own translation tables and things like that. So it’s perfect.

Are all and I think the final question really, so this is perfectly rounded up. Are all the methods in JRE6 and Java 6 available for use in Marketo scripting? Well, anything that hangs off an object that you can access in velocity? Yes. There’s no method. If you have an object of that type, there’s no method that’s defined that you’ll see in the Java docs that you can’t call, but you can’t access all kinds of objects. So I think the answer is.

Geez, I want to end on a good yes. Yes, you can if you can see the object, but not if you can’t create objects of that type and philosophy or access them for other just coincidental security reasons. But that’s it for today. Thanks very much for attending and guess we’re set.