Hi, guys. I hope you are marvelously well. Welcome to this Marketo Office Hour dedicated to Vertify, a cloud solution that will allow you to integrate Marketo and different CRMs very easily, in record time and that will give you complete control of your integration. I will first briefly come back to the native integration just to have in mind what are the functionalities of those and explain to you what could be the business cases where the native integration with Salesforce and Dynamics, for instance, are not sufficient. Let's start. Let's start with a brief recap of what we have regarding those native integrations with Salesforce or Dynamics, which is more or less the same, a bit behind compared to Salesforce. Basically we have a bi-directional integration between the Marketo persons and the CRM lead and contact. And you know that the conversion between lead and contact will be correctly propagated to Marketo. So Marketo will know when a person is converted in Salesforce or in Dynamics into a contact. So we have these uni-directional flows between accounts, opportunities and users here. All the accounts, opportunities and opportunity contact roles plus users will be copied to Marketo only. You will not have the move back from Marketo from the companies in Marketo or the salesperson, or the opportunities, it's not possible. We have these bidirectional flows between campaigns and campaigns members to Marketo programs and program members. I've put campaigns here, but it is the same. And we also have all those custom objects that you have created in your CRM, provided that they are a child or grand-child of contacts or accounts, that will be pushed to Marketo, only those you choose, obviously. So for instance, if like me, you've created projects into your CRM, you can have these custom objects projects in Marketo. Salesforce will push and insert updates and delete all those projects into Marketo, and you will be able to include those projects into your scoring, into your segmentation. So a trigger campaign based on the fact that a person is associated with a new project or that the status of a person has changed on a project. We also have bidirectional integrations between activities in Marketo and Salesforce, so some of your activities in Marketo can be pushed to Salesforce, and Marketo will listen to those task elements in Salesforce and move them back into Marketo. This is something we don't have with Dynamics. I think that's the main difference we have. This is a pretty nice integration. And thanks to Marketo we have those, and they are working pretty well. But there are some business cases where you may want to go a bit further than that. Let's see that. Let's review oldest business cases where the native integration is not sufficient. The first big case we have very often is that we have duplicates in some cases. Why is that? You know that when you import a person into Marketo through a file, a CSV file or that a person enters the form, the key, the unicity key will be email. And that's great because a person entering twice the form with the same email will be recognised and will be updated to Marketo and will not create duplicates. But for the integration, whereas it's for Salesforce or Dynamics, the unicity key will not be the email, but the ID, the CRM ID. Meaning that, if a person is created into Marketo and exists in your CRM but has not been created, for instance, a sales enter a person and at the same time the same person enters a form, the integration will not recognise the person into Marketo having a CRM ID and will push this person into the CRM, creating with this process duplicates with the existing person the sales has just entered. And the very frequent case we have is companies starting using Marketo not synching at once the CRM. So they dump into Marketo huge parts of the database into Marketo from the CRM, then start working, doing campaigns, for instance, for six months. That's great. And at some point the IT guys become available and they decided to integrate Marketo and the CRM. And that's where we connect both. The integration will look at what exists into Marketo and will not recognise all those leads and contacts into the CRM, will not recognise those into Marketo because they don't have any CRM ID. CRM ID is a system field, you cannot update it. So everything will be pushed back into Marketo, and that's not something you want. There are ways to do better than that, but it's very tricky. And on the long run, it may happen that, for instance, you sync a person between Marketo and the CRM, and you know that Marketo, the price of Marketo is driven by the number of contacts you have into Marketo, so you may want to limit the number of useless contacts, useless persons into Marketo. So you do some cleaning into Marketo, whereas you let those contacts into the CRM. So you have a person existing in the CRM and not existing into Marketo at some point. This person comes back into Marketo, whereas they enter a form or they are imported through a list, and the integration will not recognise this person as the same one in both systems. So as soon as you push this person from Marketo to the CRM, all the CRM updates don't update in the CRM on this record. The person will be pushed in the other system, and a duplicate will be created. That's very frequent and that's one of the main pain points we have regarding those native integrations. The solution would be to keep the ID as the first unicity to key but to add a second one, for instance, the email or a chain of fields we would create that would help to reconcile some persons. So we want to be more granular than the native integration. A second case that also happens, especially if you are using the attribution model from Marketo, you may want to filter the records from the CRM or from, especially, for instance, on the opportunity contacts roles where you don't have much control. Because as soon as you sync an opportunity into Marketo, all the contacts associated with this opportunity will push to Marketo. And if, for instance, you have, like me, persons on your opportunity that are not related to this customer, for instance, I put all my opportunities, the employees that will certainly work on this opportunity or this project, or the partners I'm working with on this opportunity. The attribution model of Marketo will distribute some revenue from the opportunity to these contacts and then to the campaigns, those contacts have been through with success. And so some of the revenue will be diverted from the actual marketing campaign to some campaigns that I don't want to be allocated in terms of revenue. So I would like to filter, for instance, some opportunity contact roles based on those roles and say to the integration: please don't push those roles into Marketo. I cannot do that because I don't have the control on this flow. Another thing you may want to do that you cannot do with the native integration is to transcode data. For instance, some of the country codes in some CRMs are stored in numeric values and not alphanumeric values. So you don't have France, Germany or Australia; you have 13, 15 and 17. And you know that Marketo exchanges data based on what's in the database, not what's on the screen. So you will have in Marketo those numeric values, 13, 15 and 17. And that will be a nightmare for the marketing because you don't want to create segmentation trigger campaigns or smart lists based on those numerically, because that doesn't mean anything. You want to transcode that before arriving to Marketo into real country names. So that's something you could do with Vertify. For instance, you could also replace some parts of the text. You may want to truncate some fields, you want to put the company names in uppercase or lower cases. You may want to format the last name, the first name. So all those things you cannot do into the integration because you don't have that. We may also want, for instance, for the acquisition fields, we may want not to update the field if it's already filled out. You know that in the native integration, the principle is that, as soon as a field that is synced is changed, the record is pushed to the other side and that replaces everything, basically, unless you have locked some fields in updates, but there are not many controls you have on the granularity of the field. So this is something we may want to do. We also would like sometimes to sync both ways the custom objects. For instance, if you have connected your Marketo with quizzes, with webinars, with videos, and those systems push to Marketo some new leads or updated leads, and on top of that, add some custom activities or custom objects, for instance, let's imagine that in a webinar, a person has voted on the poll that you've done, has chatted, has asked questions and your webinar system pushes you, pushes to Marketo all those pieces of information and stored them into custom activities or custom objects. It may be both or one of the them. You may want to push to yourselves that really valuable information, and that's something you cannot do because the flow between custom objects is one way unidirectional from the CRM to Marketo, and Marketo cannot push information to the CRM. So you may want to do that. Something really frequent with the Dynamics native integration. As soon as we have an error, it's really complicated to know exactly what happened, because the error messages are so confusing. You may not understand basically what the error is, so we would like to have clear messages and have a way to rerun, to correct the errors and make sure that all the records that were not pushed to the other system will be taken into account and pushed the other way. That's not something happening with the native integration when we have an error. The recall will not be pushed again to the CRM or to Marketo, unless there is a new update on the record. That's something really painful because we have to monitor really closely the errors and do a lot of manual operation to make sure that everything is pushed on the other side. The last thing that could happen is not very frequent, but in a big organisation it may happen. You may have two CRMs with one Marketo. Why is that? Because you may have two Business Units with very different business models and you have two Salesforce or two Dynamics for those two BUs, and you don't want to merge them because it would be too big a project. But Marketo, on the other hand, the data model of Marketo is pretty much the same for all the customers, except the custom objects. But you may work within the same Marketo with two different BUs with different business models. That's not an issue at all. One Marketo, two Salesforce, that's impossible for the native integration because it's designed in such a way that it's only one Marketo, one CRM, one Salesforce or one Dynamics. And on top of that, once the native integration is in place, it locks the APIs for the companies' opportunities, sales users, number of objects. So even if you use the native integration for one of your CRMs, the other one would be only able to access the person to Marketo, which would be a very feeble integration, not very useful. It would be a first step, not as rich as we want. The only way to connect two Salesforce or two Dynamics with one Marketo would be to use a solution like Vertify. So let's deep dive now into Vertify. Vertify is a cloud solution, a US-based company. And they have pre-integrated into their system a number of marketing automation solutions plus a number or CRM solutions. For instance, Dynamics, obviously Salesforce, Pipedrive, SugarCRM, Zoho, NetSuite… And we also have other solutions – eCommerce solutions, sales engagement solutions. What we will see in this demo would be Marketo plus Zoho integration. I connect to my sandbox here and basically… we don't have any data into this sandbox, so I will not be able to move anything, but I can show you the build of the integration. Let's go directly to this Define menu where I have these straightforward processes: Connect, Collect, Map, Translate, and Manage. Let's see that. Here I see the two connected systems. I have, on the one hand, Marketo connected here with the classical client ID, client Secret and the REST endpoint. We also have some filters on Activities we want to push to the CRM, and some other parameters. And we define that it will be a bi-directional integration. And the same for Zoho, we have a pre-integrated connection. We only need to fill out the client ID, client (inaudible), the token and the URL and it will be connected. That's the first step. What we see here is that we can connect a very large number of different systems. You see here Amazon systems, CSV files – we can connect to CSV files, for instance – , Dynamics, Eloqua, HubSpot, we have Magento here, Marketo, and we have NetSuite. We also have ODBC connectors, meaning that if your system is on-premise, meaning you have an internal database CRM, we can connect to this system through an ODBC client that will be on the sense on as your CRM, and this client will communicate with Vertify. We also have here SFTP. So we could also imagine the integration only based on files that would be exchanged on secure FTP servers. So that could be a possibility if the pre-integration is not found in this list. We have a number of those. The second step here once we have connected all our system would be to collect the data. And this is where Vertify will read the data mobile of both systems. Here, for instance, for Marketo, we have already collected some data. We have all the tables from this Marketo. And for those of you who don't use a lot the API from Marketo, it may be strange because the names of the tables are not straightforward. For instance, the person table would be the LeadRecord table here. Opportunity, OpportunityPersonRole, that's straightforward, Program also. But we have some custom objects here, like the Borrower Loan, the Co Borrower Loan. I assume Campaign is also a custom object. I'm not sure of that. I don't know they are Marketo, but we have some standard tables and some custom tables, plus all the fields behind. You see here, you recognise some of the standard fields from Marketo. And we also have obviously some custom fields. I am not sure here… Let's go back. Email, EmailDomain… I am not sure. All right. So first step, collect the data. We can hide some of the tables we don't want to work with. So, for instance, if we don't want this table, we could hide it. And we will find the table here. Let's unhide it. I don't want to mess the sandbox. And the same for Zoho. We have plenty of tables here. I am not sure... there are not hidden tables. First step, connect. Then collect the data model and some data, so we could also collect some real data. Here, if I collect, I could collect the data model only or the changes of data. So that will bring some records into Vertify, that will not push the data into the other system. So it just helps me to understand what the data looks like, so that I can better integrate the fields together, make sure that the type of the field is a text or a numeric value. The third step, which is the most interesting from my point of view, would be to map easily the source and the target. So here, for instance, I have taken this LeadRecord, so the person table into Marketo, and I've drag and drop that on to my Zoho contacts and my Zoho leads. After I've created this flow from Marketo to Zoho leads and this flow to Zoho contacts, I want to create the flow the other way around here. So what I need to do is to take my Zoho contact here and to drag and drop that, it's already done, to my LeadRecord on to Marketo. First step, we map all the flows we want by taking the source object and bringing it to the target object, very easy. Once we have done that, for instance, if I go to my contacts Zoho to Marketo, we can define for this flow the filter we will use and the unicity key we will use. So the filter will be: what are the Zoho contacts we want to push to Marketo. So here, we could say, for instance: I want only the contacts in Zoho who have an email. I'm not sure exactly how we would say. I would have to look exactly at the documentation, because I'm not sure, but I think that would be different from there because we don't have the 'is empty' here. So I suppose we should use Null. So that would not push the Zoho contacts without any email into Marketo, which I don't want, obviously. It's very easy. We can put filters for all the flows in all the directions, and we can also define exactly how we will merge the record together based on which key. For instance, the obvious choice we would have for the native integration would be to use the ID. And here we would specify, for instance, the Zoho ID here, and in Marketo, we would have to create this CRM original contact internal ID. So that would be a field that we have created in Marketo to store the CRM ID. And if the integration, if Vertify finds into Marketo a person with the same ID, the same Zoho ID into Marketo, obviously it will update this person. But better than the native integration would be to use ID plus Fuzzy plus Exact. So Fuzzy would be a method to recognise text chains based on the similarity. So let's imagine we create a chain of characters based on the first name, last name and company name. And we wanted to compare that into Zoho and into Marketo, because if the ID is not matched, we may want then to compare this chain to see if maybe Sylvain Davril from Merlin/Leonard exists already into the other system and we may want to create duplicates, we want to associate the two records together, even if the IDs are not shared. So that's something that Vertify could help us with. And you see here, we have plenty of rules to reconcile different records together. So that's great. I haven't seen anything I would be missing here. I think I could imagine all the rules… I could apply into Vertify all the rules I have already in mind, that's great. So once we have defined our filters and our unicity keys or the way to merge records together, we have to map the fields. And you see, that's so easy that that could be at the hands of the marketing ops operation. Usually, integration is the property of the IT team, but here the IT team could let the marketing ops team map at least the fields, maybe not the object, because there would be security to make sure, but at least the field would be a very good way to let the marketing play with integration. So here, for instance, I've got my first name into Zoho. I've dragged and dropped the first name to the Marketo, first name and same for last name. And I would do the same for every field I wanted to mark between both systems. Very easy, very quick, and it can be done in a matter of like one hour. What I want? I may want, once I have mapped, for instance, those first two names, to create operations on this field for this flow. So here, I would define, for this flow and this field, what is the method to pass the information. On Add Update would be the default one, meaning that we can add and update this field, but we could decide that we only want to update the field On Add for the first time. We may want to only update the fields, not add the fields. And we may want to add updates only if it's empty. So I don't think, too obvious business cases here, that's something that could come in handy at some point. What could be really handy would be to add some transformations, so Truncate would help me. For instance, I have this 200-character text field into Marketo that should go to a 50-character text field into the CRM. I could truncate the value from Marketo to 50 characters to match the length of the field into the CRM. I could round numeric values to upper or lower, to nearest, up to, down to. We can truncate to a number of characters. We can format the phones with different formats. We can say this field, the URL, we want to map to have the URL with the exact outcome. Case would be, for instance, I want all my company names to be uppercase. That's something we could apply here. Replace, we could find this character, this string of characters, and replace it with this another string. And Date would be to transform the dates, the date format. So, very useful. And we could also here have some transformations, so define values, translate so we can have translation tables defined. We'll see that later. We could use Lookup, that's very useful. For instance, you push opportunities from your CRM to Marketo in the opportunity table of Marketo. Those opportunities, we have a certain ID, and Marketo manages those IDs and those IDs will not be pushed to CRM. And when the next flow comes in, which is the OpportunityContactRole, you need those opportunities ID to create records on the OpportunityContactRole. So in the OpportunityContactRole flow, we can give, we can say: please take this opportunity name, look at this name into the opportunity table you just have filled out and give me the ID back so that I can write down the record into the OpportunityContactRole. It may look complex, but all those of you who have worked with foreign keys into tables and the nightmare it is to correctly fill up the foreign keys will understand what I say. We have other operations here. I will not go through everything because we have plenty of choice, it would be too long. What's next is to see the translation table. So, for instance, if we have those countries into the CRM data stored as numeric values, we could store a translation table here and apply this translation table to the country fields, for instance, one way or the other. And that will revert the country either to the name of the country or the numeric value of the country. That's great. And we can have as many translation tables as we want. Manage here would be to fine-tune and to test the flows. How would we do that? First, for instance, on this flow, we would put a filter so that only some records with some IDs would be pushed from Marketo to the Zoho contacts. And we then could move those records from Marketo to Zoho and see if it works. Here I don't have any data, but I would see here the success and the errors. So this is where we would fine-tune the flows because, for instance, we would discover that: oh, this field is numeric, and on the other system, it's a text field. So that would not match. We would have to change that or to do a transformation. Or this field is to be compared to this other one or… I don't know, we have plenty of errors at first, and this is where we will fine-tune and see very explicit, very user-friendly error messages that would help us to reduce the number of errors. Once all the flows have been tested, we can schedule all the flows. Here we would create the schedule of all the flows, the order, how often would the flows, the integration run, whom we should alert if anything is not correctly moving one way or the other so that we could have alerts based on the errors. I really like the fact that this is straightforward, it's very easy to understand. Again, it's designed to even help the marketing operation to manage their own integration. Once the flows are in place, the marketing operation could have the control of the mapping because it's drag and drop, it's very easy to do. And you know, when the marketing operation creates new fields into Marketo, obviously it has to be created into the CRM, but then they don't want to wait three months for that. So I think it's a good idea to give them some flexibility into this integration. I'm sure you're interested in how much Vertify costs. So it's either a monthly or annual fee, depending on the volume of the database. It starts up to 100K contacts. That would be $13K annual. And you would have 20 hours of implementation included and one integration. That's how you could start. Merlin Leonard is a Vertify partner for France and Europe, so don't hesitate. If you have any questions, I would be happy to do a custom demo for you. Don't also hesitate to contact Vertify. I am sure they will be very happy to discuss all those plans and to customise them for you. That's the end of this Marketo Office Hour. I hope that helps give you some insights into this wonderful solution that could help you create an integration in a matter of days and give you some control of your integration. Bye.