Skip navigation
All Places > Champion Program > Blog > Authors Grégoire Michel

Champion Program

12 Posts authored by: Grégoire Michel

Many of us have been fighting with the lack of handlers that would enable to easily style forms. Combining multiple ideas, I propose you here a framework that will enable to add specific classes to form columns and form rows dynamically, using some JS that you can add once to your LP templates or in the embedded forms.

 

The idea is to leverage the fact that you can add a class to a field label and have the javascript replicate that class to any element in the DOM hierarchy of the label.

 

First, this how you can add some classes to field labels:

1-Access the form in edit mode and select a field (e.g. First name). Click the label advanced editor icon:

2-In the editor, open to the HTML mode:

3-And in the HTML, change the simple text into some HTML with a class:

 

You can use any class you want, provided that the JS knows how to identify it.

 

Second, use the following JS to duplicate the label classes to the rows and columns (I borrowed a couple of lines to Sanford Whiteman other solution to this problem, so thx for this ):

 

 

<script>

    MktoForms2.whenRendered(function (form) {

      var ANCESTORS_STOR = '.mktoFormRow, .mktoFormCol',

          _forEach = Array.prototype.forEach;

 

 

      function addcustomclasses(formEl) {

            _forEach.call(formEl.querySelectorAll(ANCESTORS_STOR), function(ancestor) {

                    _forEach.call(ancestor.querySelectorAll('.mfc-twelve-twelve'), function(input) {

                    ancestor.classList.add('mfc-twelve-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-eleven-twelve'), function(input) {

                    ancestor.classList.add('mfc-eleven-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-ten-twelve'), function(input) {

                    ancestor.classList.add('mfc-ten-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-nine-twelve'), function(input) {

                    ancestor.classList.add('mfc-nine-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-eight-twelve'), function(input) {

                    ancestor.classList.add('mfc-eight-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-seven-twelve'), function(input) {

                    ancestor.classList.add('mfc-seven-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-six-twelve'), function(input) {

                    ancestor.classList.add('mfc-six-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-five-twelve'), function(input) {

                    ancestor.classList.add('mfc-five-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-four-twelve'), function(input) {

                    ancestor.classList.add('mfc-four-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-three-twelve'), function(input) {

                    ancestor.classList.add('mfc-three-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-two-twelve'), function(input) {

                    ancestor.classList.add('mfc-two-twelve');

                    });

                    _forEach.call(ancestor.querySelectorAll('.mfc-one-twelve'), function(input) {

                    ancestor.classList.add('mfc-one-twelve');

                    });

            });

        }

 

        var formEl = form.getFormElem()[0];

        addcustomclasses(formEl);

    });

</script>

I am quite sure that the JS code can be streamlined and enhanced, for instance to handle any class starting with "mfc-" instead of a fixed list of classes, but I would leave it to someone better at JS than I am . Another enhancement would be to also recopy the class from the label to the input zone. (Sanford Whiteman, I know you turn this very basic code into gold)

 

 

Finally, you will need to add these classes to you CSS. you can use combined classes to manage specifically rows and columns.

 

For instance, I have prepared a CSS that uses the following set of classes to manage the columns width and responsive behavior on a multi-column form:

 

<style>

.mktoForm .mktoFormCol.mfc-twelve-twelve {

    width: 100%;

}

.mktoForm .mktoFormCol.mfc-eleven-twelve {

    width: 91.66%;

}

.mktoForm .mktoFormCol.mfc-ten-twelve {

    width: 83.33%;

}

.mktoForm .mktoFormCol.mfc-nine-twelve {

    width: 75%;

}

.mktoForm .mktoFormCol.mfc-eight-twelve {

    width: 66.66%;

}

.mktoForm .mktoFormCol.mfc-seven-twelve {

    width: 58.33%;

}

.mktoForm .mktoFormCol.mfc-six-twelve {

    width: 50%;

}

.mktoForm .mktoFormCol.mfc-five-twelve {

    width: 41.66%;

}

.mktoForm .mktoFormCol.mfc-four-twelve {

    width: 33.33%;

}

.mktoForm .mktoFormCol.mfc-three-twelve {

    width: 25%;

}

.mktoForm .mktoFormCol.mfc-two-twelve {

    width: 16%;

}

.mktoForm .mktoFormCol.mfc-one-twelve {

    width: 8.33%;

}

 

@media only screen and (max-width: 480px) {

    .mktoForm .mktoFormCol.mfc-twelve-twelve,

    .mktoForm .mktoFormCol.mfc-eleven-twelve,

    .mktoForm .mktoFormCol.mfc-ten-twelve,

    .mktoForm .mktoFormCol.mfc-nine-twelve,

    .mktoForm .mktoFormCol.mfc-eight-twelve,

    .mktoForm .mktoFormCol.mfc-seven-twelve,

    .mktoForm .mktoFormCol.mfc-six-twelve,

    .mktoForm .mktoFormCol.mfc-five-twelve,

    .mktoForm .mktoFormCol.mfc-four-twelve,

    .mktoForm .mktoFormCol.mfc-three-twelve,

    .mktoForm .mktoFormCol.mfc-two-twelve,

    .mktoForm .mktoFormCol.mfc-one-twelve, {

        width: 100%;

    }

}

</style>

The real advantage of this method is that you can design in advance a series of classes and document them so that your users are fully free to use them as they want in their forms.

 

-Greg

I often get the question about why one should not import persons in programs (using the "import members" button in the member tab:

There are at least 3 reasons for this:

  1. Because you want to be able identify without any doubt which persons where created on lmport and which were merged with existing persons.
  2. Because you want to be able to control program membership and acquisition information
  3. Because you want to control order of operations in an SFDC environment

 

Let's explain in details:

 

1-Being able to identify which persons were created

There are many way to identify persons that were created from an import, but most of them can give inacurate results because they are based on information that can be tempered with. Acquisition programs, source, and any other field based identification can be tempered with with simple flow steps, errors in Marketo from the user, or changes in the CRM.

 

You can protect your database against certain changes (for instance blocking updates on fields), but you also have another issue to deal with: the source or acquisition program will be the same whether a person has been imported in the program or if the person filled out a form (see Being able to prevent new persons to be added to a program on form fillout) In this case, a filter on "acquisition program" will give wrong results.

 

And yet, in some case, you need to accurately identify the persons that were really created on import, in oder to be able to delete them (and only these ones) later on or in order to run specific campaign (such as add the to an engagement program).

 

The static list here is very helpful since the "person is created" filter and associated trigger provide a very useful "List name" constraint:

Using that constraint, you can select precisely the persons that were added to your database through the list import.

 

2-Controlling program membership and person acquisition information

Importing a person in a program makes it a member of of the program and automatically sets the acquisition program and date if the lead is created upon import. But sometimes, you need control these information. For instance, you may want to run an email on the imported database and consider a member or even an new name only the valid emails or the persons who click it.

 

Unlike what is written is some places, importing in a static list within a program does NOT make the imported persons a member, nor a new name of the program. You will have to run flow steps to make it happen, which means you will be able to control precisely the conditions for this to happen.

 

3-Controlling order of operations

This really matters if your program is synchronized with a SFDC campaign. In any other situations, this point will not be valid. And this is a consequence of previous point, but I though it was worth a separate chapter.

 

When you import a person in a program, that person is immediately added to the program as a member, and if the program is sync'ed with an SFDC campaign, the person is also immediately pushed to SFDC, denying all your data management and person lifecycle management campaign to run. This results in mis-assignment, wrong alerts, etc... some workarounds exist but still*, but this is not a welcome behavior.

 

If you use a list to import the data, then you can use a "was added to list" filter or "added to list" trigger to process things exactly in the order you want and finally add the person to the program in the correct member status, and also set the acquisition program (I tend more and more to privilege filters and batchs for long lists, that I run after the import is complete: no need to add another trigger to the active list, since this trigger will only fire once).

 

4-Conclusion: to reduce user confusion, use only one method, the safest one.

I observe, across all the projects to which I have been participating, that teaching users multiple import techniques is more confusing than anything. On the long term, they tend to forget about the pros and cons of each methods and fall back on using only one.

 

 

For these 3 reasons, I strongly recommend that you get used to have an "Import list" and the associated smart lists:

  • Was created on import
  • Was merged on import:

 

-Greg

 

 

 

* Add a "Sync is authorized" field in SFDC that has to be true in order a person to be inserted from Marketo (using an SFDC validation rule to control this), but sometimes

As this is a recurrent request in this community, here are the various ways of setting up the unsubscribe links in Marketo, and when one should use them.

 

 

0-Summary

The following table summarizes the possible approaches, when to use them and what chapter you should read:

IfRecommended implementation steps
You want a quick and minimal version that works well and guarantees compliance
  1. Customize the default code (See 2)
  2. Customize the default page (See 3)
You want to properly brand your unsubscribe landing page, and continue using Marketo default or system token
  1. Create a new Unsubscribe page with your own template. Place it preferably in a marketing activities program together with it's follow-up page and any smart campaign you may need
  2. Redirect the /UnsubscribePage.html URL to your page (See 4)
  3. If you plan to use it, customize the default code (See 2)
You need various unsubscribe pages for different audiences (segments, language, ...)
  1. Create your various unsubscribe pages. Place them preferably in marketing activities programs together with their follow-up pages and any additional smart campaigns you may need
  2. Add a snippet element in a dedicated module at the bottom of your email templates (or a text element if you are still using email 1.0)
  3. Deactivate the default link (6)
  4. Create unsubscribe snippets using the customized URL (See 5 ). You can even make these snippets dynamic if the various Unsub LP's are linked to segments.

 

There are 3 ways to get the unsub link added to an email:

  1. just ignore the problem. When you send an email, Marketo will detect that no unsubscribe link is included and will automatically add it's default one, that is defined in the admin -> email section and which code is:
    • <p><font face="Verdana" size="1">This email was sent to {{lead.Email Address}}. If you no longer wish to receive these emails you may <a href="%mkt_opt_out_prefix%UnsubscribePage.html?mkt_unsubscribe=1&mkt_tok=##MKT_TOK##">unsubscribe</a> at any time. </font></p>

  2. add the {{system.unsubscribeLink}} to your emails as the href in an <a> tag. This can be done in the template (even hard coded there) or left to the user. That will be enough and Marketo will automatically understand that it should replace the token with the proper link and that it should not add the default unsubscribe link. So <a href="{{system.unsubscribeLink}}">my unsub link</a> will become <a href="http://mktolpsubdomain.company.com/UnsubscribePage.html?mkt_unsubscribe=1&mkt_tok=##MKT_TOK##">my unsub link</a> at runtime.
  3. Add a link towards any LP in Marketo, with "?mkt_unsubscribe=1&mkt_tok=##MKT_TOK##" at the end of the href. This will be enough for Marketo to know not to add the default link to the email.

 

2-Customize the Marketo default code

The default admin-> email code can be customized by anyone who knows some rudiments of HTML. Text, fonts, colors, layout, etc.. can be changed. Just always make sure you do not remove the "?mkt_unsubscribe=1" from the link href.

Typically:

 

<table align="center" width="600">
     <tr>
          <td style="font-family: helvetica; font-size:10px; color:#555;">
               This email was sent to {{lead.Email Address}}. In order to stop receiving our spammy emails <a href="
http://mktolpsubdomain.company.com/myniceunsubpage.html?mkt_unsubscribe=1&mkt_tok=##MKT_TOK##" class="mktNoTrack" target="_blank">click here.</a>
          </td>
     </tr>
</table>

will work perfectly well.

 

Please note that, in order to prevent Marketo to track the click on the link, you will have to add class="mktNoTrack" to the <a> tag.

 

3-Customize the Marketo Default page

By default, all Marketo instances come up with an unsubscribe page that use the ugly akward Standard free form template:

This page will be located in the design studio, and it's name will be localized in the language in which you instance was initially created.

The most obvious and simplest move is to customize this page and make it a little more looking like a page from your company

You can also move this page in a program in the marketing activities. As long as it's URL keeps being UnsubscribePage.html (see below) it will continue to work.

 

Now, maybe you would like to use another template for your landing page. Or maybe you want to replace this unsubscribe page with a thoroughly designed subscription center. But you want to keep the usability for your Marketo users, so you would like to keep the {{system.unsubscribeLink}} token or the Marketo Default driving the visitors to your nicer LP.

For this, you need to know that, whatever the config of your instance, the {{system.unsubscribeLink}} token always direct to /UnsubscribePage.html. So you will just need to have this URL reassigned to your new and nice unsubscribe page. This is again quite easy using Marketo URL tools. Once your new unsubscribe page is ready and tested:

  1. Go to your old unbsubscribe page. In Marketo UI, click the Landing Page actions -> URL Tools -> Edit URL settings:
  2. In the dialog box, change the URL to anything (I personally simply add "old" to the end of it.

    Tip: What is important here is to throw away to previous URL so that the URL becomes available
  3. Then go to your new unsubscribe page and do exactly the same thing, granting this new page the UnsubscribePage.html URL

 

To run this process, wait until a moment when no email has been sent in the past hours, since you will have no unsub page available between steps 2 and 3.

 

5-Use a different URL for the unsubscribe page

May be you want to use a different URL for this page, or even have various URLs for various contexts. In fact, nothing mandates you to always use the {{system.unsubscribeLink}} or the /UnsubscribePage.html URL. Any Marketo LP URL will do the job here, as long as it is appended with the "?mkt_unsubscribe=1" to indicate to Marketo that this is an unsubscribe link. You should also add the &mkt_tok=##MKT_TOK## to make the click on the link carry the token value and enable cookie value reconciliation. Please also note that, in order to prevent Marketo to track the click on the link, you will have to add class="mktNoTrack" to the <a> tag.

 

The following is a perfect unsubscribe link in an email template:

 

<tr><td>This email was sent to {{lead.Email Address}}. In order to stop receiving our spammy emails <a href="http://mktolpsubdomain.company.com/myniceunsubpage.html?mkt_unsubscribe=1&mkt_tok=##MKT_TOK##" class="mktNoTrack" target="_blank">click here.</a></td><tr>

 

As you can see, it takes no token and not event the /UnsubscribePage.html URL.

This method will be necessary in a multi language / international roll out: you will need to have multiple, different Unsubscribe pages for each language and the Marketo default or {{system.unsubscribeLink}} token can only link to one of them.

 

Also please note that the unsub code can be added to snippets, which in turn can be added to the emails for maximum flexibility.

 

If you are sure that your email templates always include the necessary links and you want to avoid Marketo adding it's own link just replace the default unsubscribe links with HTML comments in admin->email

 

Hope this helps,

 

-Greg

In my previous posts on the "sync with Marketo" "Sync with Marketo" mysteries part 1 and "Sync with Marketo" mysteries part 2, I pointed out the fact it's impossible to know through filtering that a record has stopped sync'ing, except through visiting lead activity logs one by one.

 

The typical use case is:

A sales person learns a contact has left the company. the salesperson flags the contact as Inactive in SFDC. A workflow automatically unflag the "sync with Marketo" field, the sync immediately stops, meaning that Marketo does not event know the contact is in fact inactive.

 

In fact, I recently and inadvertently discovered an interesting behavior of the Connector which drives to the possibility to know...

 

It is based on the fact that SFDC formula fields cannot be updated by Marketo, but always sync from SFDC to Marketo even if the sync raises an error. The only case in which they do not sync from SFDC to Marketo is when the sync is stopped.

 

Create a formula field in lead and contact objects. Call it "Sync test" or anything else. Put any formula in it. If you want to make it a useful info, copy the SFDC record id into it, you may need it one day (I'll right another post on this).

 

When you want to test the sync on a record, Create the following smart campaign:

 

Smart List

  • Trigger: campaign is requested
  • Filter: SFDC Type [Person] IS NOT EMPTY (no need to do this on a record that has ever sync'ed)
  • + any other filter you see fit

 

Flow:

  1. Change data value, attribute is "sync test", new value is NULL
  2. Sync lead to SFDC (assign to whatever you want)

 

Qualification rule:

  • Always run through the flow

 

Run the smart campaign on the leads you want to test.

 

When the campaign is over, if the sync is stopped, the "Sync Test" field will still be empty. If the sync is not stopped, the "Sync Test" field will be filled again with the formula value EVEN if the sync did not occur (for instance because of sync error, due to validation rules in SFDC).

 

The interesting thing is this is that the blocked sync records in Marketo can therefore be queried with the "Sync Test IS EMPTY" filter, for instance to delete them from Marketo.

 

 

-Greg

This post is the second one of a 3 parts series, stating with this one: Testing the email editor 2.0: Great features, a few glitches and the strong need for a v2.1, which dear reader, you should read first in order to understand the reasons of this migration path.

 

You should also read this Email editor 2.0 is leaving room for a v2.1 in order to get a grasp on the remaining limits of the products and avoid to look features that are not there yet.

 

From all the testings in the post above, we have designed a migration path that we will apply to our customers in order to make sure that everything runs smoothly and no key content get lost.

 

Table of content

 

0-Define your strategy

The very first thing you need to do is to define your strategy. You current templates will have to be divided in 2 categories:

  1. CAT1 will be candidate for an upgrade. For these, you should undertake the series of tests described in the rest of this post. If you have any email that may have to be edited in the future, then you should assign its template to CAT1.
  2. CAT2 templates are not candidate for an upgrade. This can be because their are obsolete on a graphical standpoint, or because the first tests below makes it obvious that they will break and you consider fixing them is not worth the effort. For the CAT2 templates, the best is to remove or approve any template draft and email draft and archive the templates. Then make it explicit to the users that they should:
    1. No longer try to use these templates and use some CAT1 or some brand new v2 templates instead.
    2. No longer try to edit the emails based on these templates as these have not been tested on v2 and there is a risk of content loss.

 

At the end of the upgrade process, you will end up with 3 types of templates:

  1. Non upgraded templates. They should all be archived.
  2. Upgraded templates. These will work as they used to be in v1, with the same level on functionality, based on mktEditable elements. We recommend that you do not try to introduce v2 Variables or new element types on them, as it would cause compatibility issues on you existing emails
  3. New templates. These can be created either from clones of the v1 templates, from Marketo starter templates or from any other sources. They will potentially benefit from all the new features, including the modules.

 

1-Before you activate the v2: Test and prepare

Before you activate the new editor, we strongly advise that you take these preliminary steps:

  1. Delete unused tests and development trials
  2. Get rid of all remaining templates drafts and email drafts. Approve them or discard them, but let none of them in your design studio nor in your marketing activities. These draft will collide with the upgrade and you will have to delete them anyway.
  3. Archive the CAT2 templates and alert the users on not using them any longer.
  4. Rename all your existing CAT1 templates, adding a v1 to their names, to be able to distinguish them easily when you start creating new ones or upgrading templates
  5. Important: Review the CAT1 templates for the following undetected mistakes and fix these mistakes (and approve the template draft and the related emails drafts that are automatically created when you repparoved the template):
    • Any unclosed HTML tag
    • Any missing ID in a mktEditable element
    • Any duplicate ID
    • Any nested mktEditable elements
    • Any line breaks inside html tags
  6. Once you have corrected these templates, review all the emails that were based on these templates. Especially if you had some nested mktEditable, the corrected email might look weird. Edit the emails, check them, correct if necessary and approve them (leave no draft behind)
  7. Make a copy of the code of all the CAT1 templates that you have checked/corrected above in a backup storage (a text editor file on your computer will be perfect)
  8. If you have the courage and the time, rename all your emails you plan to upgrade, adding a v1-t1 (meaning email in v1, template in v1) to the name. The naming convention will evolve to v2-t1 when you will edit and approve the emails in editor v2 without an upgrade to the template and the to v2-t2 (or simply v2) when both the template and the email are upgraded.
  9. Important: clone the CAT1 templates, name the clones "[mytemplate]-upgtest" and approve them. Then create v1 emails from these upgrade tests templates, name them "[my email]-v1-upgtest" edit the content and add real content to these emails (in other words, replace the template default/dummy content with yours), then approve them. There will serve as a preliminary test just after the activation and before upgrading all the production templates.

 

2-Tests to be done just after the activation

Just after the activation of the feature, and before you authorize anyone to start using the editor, you should run this series of sanity checks:

  1. Clone your v1 templates, edit the new clones and approve them. These clones will be v2 (name them accordingly, it impossible to distinguish them in the email or template list without a proper naming convention Have the editor version to appear in the email list). This will act as a test and will also create the same template as the source v1, yet in v2. Then create test emails from this new v2 templates and test everything is alright. Send drafts, create a dummy email program targeting yourself. In case you encounter an error at this stage, better disable the v2, return to the v1 editor and fix your v1 templates or ask support to help you find out why these templates would not upgrade. You may also find that some of your templates have too many bugs to be worth the work and reclassify them to CAT1 (and archive them). Make sure all your templates are clean and "upgradable" before going further and start upgrading production emails.
  2. Upgrade the "upgtest" templates you have create before activating the v2 editor (edit them as a draft, and approve them). Go to the v1-upgtest emails. They should have a v2 draft attached. Edit these drafts and check that all the content is there. Check also that all the editable zones ARE editable. Approve these drafts, send samples. At this point, you have proven that your v1 templates do upgrade well and that the upgrade of the related emails went also well. If your email content is not there, signal it to support and revert to v1. If the content is there but the mktEditable zones are not editable, use the workaround in 1-3 in this previous post and signal it to support.
  3. If everything went well so far, then you can safely consider upgrade the production templates and the attached emails in v2, but remember that you are not technically obliged to do so. This would be done editing and approving these production templates. This will create in return a v2 draft on all emails created from the template you have upgraded, which you should edit and review before approving them. In case anything wrong is detected here, deleted these drafts and call support in.

 

At this point, you are done with the upgrade and you can benefit from the new UI.

 

In large orgs, you may want to deactivate the starter template library, in order to avoid your users starting to create emails that are far from your corporate guidelines.

 

3-Quick wins to look for after the upgrade

Your upgrade went well, here are some quick wins should you look for in order to get rapidly some more value from the editor, through new or cloned templates. We recommend that you do not try to introduce v2 features in upgraded templates that have production emails attached to them and rather create new ones.

  1. Edit your CLONED v2 templates again (do not do this on upgraded ones if there are some prod emails on them) and replace the zones supposed to contain images with new mktoImg elements. Also, replace the zones supposed to contain snippets with mktoSnippet elements. This is a simple way to make your user's life much easier. Be aware though that if you used to use tokens to indicate which image should be displayed, you should not perform this change (see Email editor 2.0 is leaving room for a v2.1 for the improvements that would be needed).
  2. Also in the v2 templates, replace your text CTA's with variables. Do the same with all 1-line formatted items such as titles (mind the text version, though). Again, a limitations here: variables and modules do not go long well, so if you plan to make your template modular, do not do this change.
  3. Approve these new v2 templates and test them extensively, again (send sample and smart campaign).
  4. If you are happy with the result, you can put them to use by your users, archive the old v1 ones and let your user know they should now use the v2

 

4-Longer term gains

On the longer term, invest in the new possibilities offered by the new features

  1. Set Background images with the image variables (we still have to check this works even in a <--!if mso context)
  2. Use the new variables to completely reshape the functional behavior of the templates
  3. Start leveraging the new module capability to create flexible templates that your users will love. It will enable you to reduce the total number of templates you need in your instance. (Attention to the variables in modules, variables are global to the whole template and will therefore have 1 value for the whole email)
  4. Use the brand new Video component

 

Continue the reading here: Email editor 2.0 is leaving room for a v2.1

 

-Greg

This post is the last one of a 3 parts series, starting with this one: Testing the email editor 2.0: Great features, a few glitches and the strong need for a v2.1 and this one: Upgrading to the new email editor 2.0: a recommended migration path

 

From the tests we have ran, we found out that some of the features where not complete and that some of the key use cases would not be possible yet. This part details the features that still need to be completed or that are yet missing and points to the various ideas to be voted for.

 

Again, the new editor is a huge progress compared to the previous one. The level of flexibility it now provides makes it an excellent tool that combine user effectiveness, adaptation to business needs and high level of compliance to technical standards.

Nevertheless, from our tests and the doc, we have detected a few additional features that would be welcome and the lack of which limits the usage of the new features. These missing capabilities establish, in our opinion, the basis for a v2.1 that will hopefully come soon after and make the product really complete.

 

Table of content

 

The strong misses (must have)

This first set of ideas are still limiting the usage or mitigating the user experience

  1. Enable the Search (Ctrl-F) function on the code. See Enable Search (Crtl-F) in the Email 2.0 code editor
  2. Text version of the email do not support variables, this reduces the possibility to use a variable as a container for text parts of the emails, such as a title. See Email editor 2.0: variables in the text version
  3. Content that belongs to template and not to editable zones only render in the HTML version. And yet, it might be necessary in the text version as well. See Text version of email templates
  4. The new module feature seems very promising, although we have not been able to test it because of a strange limitation: it can be implemented only on a limited set of HTML tags and not on <div>. Our templates use divs as this is the only way to have them support all email clients on all versions of android. Email Templates 2.0: enable containers and modules on <div> tags, not only on table elements
  5. Manipulating images has made very significant progress. But using them together with tokens is still quite difficult. In fact it means that it is still impossible for the moment to set/change the images in an email with tokens only, without editing it. What a waste of time and a contradiction with the principle of tokens! See:
  6. It is impossible to make variables segmentable for dynamic content. In other words, if you use a variable to create a CTA, this CTA will have to be the same for all segments.  Guided LP and email 2.0 templates: make variables segmentable for dynamic content
  7. As detailed above, it's easy to replace CTA with 2 variables and make it unerring, but it will not be compatible with the module features. Text CTAs would be preferable. See Text CTA Elements for email and LP templates.
  8. The fact that variables have only 1 global value makes them very limited when combined with clonable modules, as it drives 2 modules to have the same CTA value, the same background image, etc... We really need to have variables to be able to get 1 different value for each module. See Email editor 2.0: module level values for Variables
  9. It is not possible in the 2.0 to have more than one container in a template. Therefore, it is not possible to control in which area of the email which module will go. SeeEditor 2.0: Have more than one mktoContainer per email template
  10. Controlling the number of modules that can be inserted in a template would be interesting to control that the modular approach does not turn into a total fantasy. See Controlling the number of modules in a container.
  11. In order to make sure that users comply to the corporate guidelines, we could also need to be able to restrict access to some of the functionalities of the Rich text editor toolbar: Restrict access to the Rich Text toolbar (Thx Alan Brown )
  12. Restrict the List variables values to the list values. See Email 2.0: List variables should only accept list values
  13. The need for some more advanced support of VML in order to be able to create templates that perform as well on Outlook as on any other client. See Email editor 2.0: Enable branded link for vml buttons
  14. Making a whole module dynamic in order to provide much more flexibility and reduce the risk for errors. Email editor 2.0: Make whole modules dynamic content

 

The features that would be welcome (should have)

This series of ideas would enable to push the usability and functional level a step further

  1. Enable the text editor to wrap text instead of horizontal scrolling. See New email editor 2.0: wrap template code
  2. Adding a token to a variable is still not convenient, as in LP's: you need to know the token syntax or copy and paste it from another part of Marketo Token picklists for Guided LP or email 2.0 template string variables
  3. It is too easy to add an image which dimensions are not compliant with the way your responsive template is set up, which would cause some issues on some platform. You can force the image dimensions with some new attributes, but it is not a recommended way if you want it to adapt to really all email clients and devices Editor 2.0: Set Min and max dimensions for image elements and variables in Guided LP / email templates
  4. Editing the email code is not a right that should be given to anyone. SeeEmail "Edit Code" (a.k.a "Replace HTML") permission
  5. Variables should display in the order set by the designer, as this order is usually more functionally logical. Guided Landing Page or email 2.0 variables should display in the order set by designer
  6. Finding out which email is upgraded and which is not requires to browse each of them one by one. Not convenient. See Have the editor version to appear in the email list
  7. Activating the starter templates is currently an ON/OFF setting in the admin. So either every one can access it or no one. It would be much better to make it more granular through a permission role: Editor 2.0: access to the Starter Templates to be controlled through a role permission
  8. When setting a variable in a template, if this variable is a number or a string, the user may leave it empty, which would break some of the behaviors in the template. See Required attribute for guided page variables
  9. A series of needs posted elsewhere by Courtney Grimes :
    • Would it be possible to offer overriding image thumbs for modules? If not, can we please get modules thumbs to render better? I use a lot of webfonts with fallbacks for emails and it seems Marketo likes to fall back...on sans-serif. Which I know is going to freak a lot of people out.
    • When dropping a module into an email, can the drop hover box scale to fit the bounds of mktoContainer's width? I can see this becoming confusing quickly.
    • For the "mobile" preview, would it be possible to allow for custom width scaling? While I realize 360px is the most common mobile width, it'd be nice to do quick checks without having to run to another email platform.
  10. The support for Wistia in the mktoVideo elements. See Email video element wisita support (Thx Matt Tunney)
  11. Better manager of the pre-header, especially in context where we need to make it dynamic. See Email editor 2.0: enable dynamic content in the preheader  and Email 2.0: enable to disable the preheader feature and the possibility to use tokens in the preheader. See Email editor 2.0: support tokens in the preheader
  12. The possibility to crop / resize images on the fly from the editor: email 2.0: Crop/resize images on the fly
  13. The risk induced by some variable default behavior: Email editor 2.0: have MktoBoolean accept an empty "true" value instead of for setting it to "true"
  14. The possibility to specify where an image should be stored when loading it from the computer. See Email editor 2.0: when uploading an image from the computer, enable to choose the design studio folder in which the image will be stored
  15. When creating a template from a template, have the possibility to lock down variables so that future users of the new template cannot change them. Email editor 2.0 Save as template: possibility to lock down variable values
  16. The possibility to generate HTML5 videos that would be played in clients that support it:Email 2.0: play html5 videos on email clients that support it.
  17. Make the module management in the editor much faster. See Email Editor 2.0: Make module management much faster with a dedicated wizard
  18. And also:

 

 

-Greg

Hi all,

 

I and our team have had the opportunity to test the email editor for real for a coupLe of weeks now. Here is our non comprehensive (We obviously have not tested it completely, there are too many features!) feedback. Yet, in order to run this test, we tested about 80 different templates, including all the new templates provided by Marketo in the Starter kit and 150 emails. By far not enough to be sure we covered all the cases, but an interesting sample, though.

 

This post has 3 chapters:

  • This post details the test we have been running and the findings, including the issues we have encountered and how they were solved it ends with an evaluation of whether or not one should ugrade
  • Upgrading to the new email editor 2.0: a recommended migration path describes a migration path that will ensure that you do not end up with unexpected issues or emails that you could no longer edit
  • Email editor 2.0 is leaving room for a v2.1 details the features that still need to be completed or that are yet missing and points to the various ideas to be voted for.

 

Table of content

 

1-Tests and discovery

  1. Activating it is easy. Really. Nothing happens excepted that you have now a way to select your templates in the template chooser that is way more convenient and user friendly than what was possible before. Also, the complete library is now coming with it, but the admin can have it deactivated so that users do not start to wield too much of their creativity at the expense of the corporate branding guidelines
  2. Rolling back to v1: We also have tested disabling the new editor after a while. It worked fine. The major impacts are:
    • All v2 templates that we had created (or upgraded from v1) in between could no longer be selected for email creation, which seems normal.
    • The v2 Templates could no longer be edited neither, which seems also logical.
    • All emails that had been upgraded to v2 or created in v2 becomes impossible to edit, which also make sense.
  3. Opening v1 emails in the v2 editor without upgrading the template: Once the new editor is enabled, it remains possible to create or edit a draft on a v1 email event if it's templates has not been upgraded to v2. All the email drafts you create will be flagged as v2, even if the template is still v1 (a little weird). If you approve these drafts, the email is upgraded to v2 and the v1 is lost forever. This might have an impact if you want to preserve the capability to revert to v1 (see point 2 above).
    So, at least at the beginning and until you are fully comfortable, we strongly recommend that you clone them first. Once you are fully comfortable that all your v2 templates are fully operational, you will be able to edit the v1s.
    This is on this topic that we encountered the most significant issues in the whole test:
    1. The mktEditable editable sections could not be edited any longer. PM provided us with a workaround which is quite simple: click the "Edit Code", look for a mktEditable section and add a letter or a space, then save it. Finally, on the June 18th, the issue was fixed and all templates that we upgraded since then have not replicated the issue.
    2. The content had disappeared in most if not all mktEditable zones. Again, this was fixed on June 18th.
  4. Draft emails (never approved) or email drafts (edited after approval) created prior to the upgrade: We had a couple of v1 emails that had never been approved (and therefore never used). We tried to edit them after enabling the editor, and received a system error. But the workaround is simple here: just clone that email, and the clone will be the same email, upgraded in v2.
    We also had some v1 drafts pending. Once the upgrade was done, it became impossible to open/edit them again until we had upgraded their template and removed the v1 email drafts.
  5. Simple upgrade of templates: we have upgraded quite a few templates, just to make them appear in v2, but changing nothing in them. This is a key point as it we would expect this to be the first step after upgrading the editor. The findings here are mixed. We discovered that the previous version of the editor would let errors undetected and that these errors would become breakers with the new version, causing system error messages when someone tries to upgrade the templates with these errors. Amongst the things you need to cleanse thoroughly before upgrading are:
    1. Missing ID in mktEditable elements. These would throw a system error when trying to edit the email in the new editor. You could still edit the template in v2, though,  but then you are stuck with the email not opening. On June 18th, a fix has been provided: during the template upgrade, Marketo will insert IDs like "mkto_autogen_id_0" everywhere they are missing.
    2. Nested mktEditable elements. If v1, only the child mktEditable would really be editable. Then, on upgrade, trying to open the email or the template would throw a system error when trying to edit the email in the new editor. A fix has been provided so that nested mktEditable zones will no longer prevent the upgrade. But that fix is about separating the 2 mktEditable zones, one below the other, which impact is that it destructures the email. So you should  run a thorough review of your templates before upgrading to avoid this issue whatsoever.
    3. Here as well, we encountered the issue of lost content and uneditable mktEditable elements as in point 3 above, but this has been fixed and on june 18th, this very troublesome point was no longer replicable.
    4. The last issue that we encountered is that if an email would use images from another Marketo instance, these images would display on v1 and would not on v2 in the editor (They would show normally in V1 and v2 in our receiving mailbox). This is due to some network configuration and is apparently restricted to our pod (app-e.marketo.com), but be aware.
  6. Once done, most templates were working well for email creation and as if nothing had been changed. Unfortunately, not all template upgrade went that well. One of the template we upgraded drove all the 40 emails based on this template to be impossible to edit. We had that issue on a template with a quite large number of attached emails. The issue has since been fixed and this is now back to normal, all the depending email being editable now.
  7. After a while, we noticed one strange thing: the basic template from the Marketo library had been replaced by one of or own test templates.
  8. Once a template is upgraded, in v2, all emails using this template get a new v2 draft, as expected from the doc. Here also, we experienced the same 2 significant issue as in point 3 above, which have been fixed with the same consequences
  9. We have also started to modify the templates in order to take advantage of the new element types and of the variables. These provide really a huge value, although we have not tested all the possibility brought by these new features, and we are yet to discover all the possibilities offered now. First findings are:
    1. The capability to create image elements instead of rich text ones when you need an image. This feature enables the designer to control completely the layout of the image and reduce significantly the risk of errors linked to replacing an image in a rich text zone, formatting it, etc... Similarly, email variables also bring in a lot of additional security and ease fo use to the user BUT it is impossible to use these image variables or elements in conjunction with tokens (meaning using a token to set the URL of the image). The result of this is that, if you use these new elements, you can forget about fully tokenizing the email. In our opinion, this is an important limitation. The whole way images are supported really has to be improved with these ideas: Email editor 2.0: possibility to use a token in an image variable, Email editor 2.0: using a token for the image elements, Store images/files in program or create a File/Image program token type.
    2. The possibility to create video elements is completely new in emails and is really cool. Works simply and efficiently. Again it would benefit to be compatible with tokens, similarly to image elements.
    3. We also tested the new variables, that work quite the same as they do in the guided landing page templates. Replacing editable text CTA with 2 variables (one for the text, one for the URL) completely reduces the risk of inline CSS errors for instance. The droplist variables are also really cool to better control what users would be allowed to do. But some strong limitations remains with the use of variables:
    4. We also detected one bug related to the new functionalities: the mktoAddByDefault="false" in the module elements does not work The flag has no effect and worse, it prevents the child elements in the module to be edited by the user. PM knows about it and the bug is being fixed, but in the meantime, one should just not use the attribute. All in all, this is really not a reason for not upgrading.
  10. We discovered then that the editor would not allow to search the template code using the CTRL-F, so we had to use another, third party, HTML editor. This feedback has been provided to PM and is being considered as a future improvement (see Enable Search (Crtl-F) in the Email 2.0 code editor), although this is IMHO really not a reason for not upgrading.
  11. We have started to play with the new module system. IMHO, the Module functionality is probably where the strongest difference and value increase is made compared the v1. Modules are sections of your emails. They will contain elements. Modules can be added to the email, move, deleted, cloned, making your email template much more flexible and versatile, in other terms... ...modular . The only, yet significant, constraint is that your templates will have to be significantly reworked to benefit from this feature. This is also true if your templates have been provided by template generators from the Launchpoint. Also, depending on the technology one is using to structure the template blocks, it might not be easy/feasible: lmodules can only be made of <table> or <tr>, and the module container will have to be <table>, <tbody>, <thead>, <tfoot> or <td>. Unfortunately, <div> are excluded . PM is working on it to see if it would be possible to add support for <div> in the future (Email Templates 2.0: enable containers and modules on <div> tags, not only on table elements ), but in between, we are investigating on our side the possibility to add <tr> or <tbody> elements in the templates.
  12. Finally, and this is key, we also have tested the templates shipped trough the new starter kit. They are great and very versatile, although the responsive behavior is not always perfect. Tests @June 18th:

 

2-Should you activate the new editor?

  • This is a legitimate question since the change is significant. Furthermore, here and there, some warnings were raised on the importance of the change and the attached risks.
  • The mere fact that activating the feature and touching nothing else enables to benefit from the new template chooser, the new email editor and the new email previewer, each of them being easier to use and providing a more complete feature set, make it worth the upgrade. And this is true whether you are using home grown templates, templates derived from the good old templates.marketo.com or templates created with a Template generation tool from the launchpoint. Ask your template vendors for more details.
  • Furthermore, the conclusion of our tests is that working on v2 emails created from v2 templates (created in v2 or upgraded from v1) works fine. As stated earlier, once upgraded to v2, old v1 templates continue to work in order to create new emails and, since the mktEditable classes continue to work as previously, you could even continue to develop templates without changing your development technique. This means you can benefit from new features such as the new template selector with a very low investment.
  • And of course, if you are ready to invest into the adaptation of your templates in order to benefit from the new features, then this new editor brings a lot of value. Safeharbor: Just be cautious yet and clone before editing, since we CAN guarantee that we have NOT tested all the new functionalities
  • But, as described above, upgrading production v1 templates (editing them and approving them in v2) and consequently upgrading v1 emails attached to these templates has been causing loss of content and editable zone problems in the upgraded emails. It all has been resolved now, but I would still encourage you to be cautious and use the migration protocol described here to make sure you will not hit the same problems.
  • Therefore, if you decide to activate v2, it would be preferable that you to adopt a policy by which you will not try to upgrade to exiting templates, but create new, V2 ones and retire the v1. Doing this, your v1 emails will continue to be sent normally after you have activated the new editor.
  • If separating V2 templates from v1 is not possible, or if you want to go one step further, and you absolutely have to upgrade your production v1 templates, we recommend that you run a few checks before upgrading (see Upgrading to the new email editor 2.0: a recommended migration path), correct the glitches if necessary and be ready to step back on this or wait until the bugs are fixed.
  • Finally, our tests also shown that the new editor could be further enhanced. We have listed some areas for progress here: Email editor 2.0 is leaving room for a v2.1

 

We will continue testing in the next few days, and keep you posted of findings. Pls do not hesitate to share yours as soon as you are ready to test.

 

This is to be continued here:

Email editor 2.0 is leaving room for a v2.1

Upgrading to the new email editor 2.0: a recommended migration path

 

-Greg

As a regular contributor to the community, here are some advice I would give to beginners who want to maximize the chances to get some help from the community:

 

1-Choose the right place to post

Post your products questions to the place where you have the greatest chance to get a quick answer. This is set at the bottom of the discussion entry screen:

  1. "Products" is the best place for anything related to the use of the products (MLM, RTP, ...). Most of the time, this is THE place to start. Most of the community members start to look there when they have some time to answer questions. Furthermore, questions and discussions in this place resurface each time someone comments them, making them more visible
  2. "Community help and feedback" is the best place for anything related to how this community works
  3. "Champions: the Marketo elite" is not that a good pick, unlike what one would think: only a small subset of the users are monitoring this place. the questions there do not show on the pending question lists and you are quite less likely to get a quick answer. My experience is that questions posted there receive far less answers.
    [EDIT]: based on Liz' comment below, "Champions: The Marketo Elite is for people to find out more information about the Champion program." And if you did post it to the wrong place, you can ask Elizabeth Oseguera or Scott Wilder to have it relocated.

 

2-Choose the right type of post

The choice of the type of post will impact the quality of the answers you will get as well as the timeliness of these answers:

  1. Questions: In order to post a question, you have to create a "Discussion" (weird, isn't it? ).  "Discussions" are for any questions and information and by default, a "Discussion" will in fact be a "Question". As a contributor, like all other community contributors, I know that questions are from people who need real help, most of the time quickly. Start there, unless you really know your post belongs to somewhere else.
  2. Discussions: You can also transform a question in a simple information to the community, un-clicking the "Question" checkbox. This will make your post a simple information for the community. Always very appreciated from everyone . But then, do not necessarily expect an answer, you are more likely to get "thank you's" here.
  3. Ideas: Create and Idea only if you are sure it is a missing feature. If you are not sure, start with a question. If you are pointing out a missing feature, the community will often answer something such as "That a nice idea, post it, we will vote". Do not post questions here, it will not help you as you should not expect a "how to" answer. On the other hand, accept that idea relevance can be discussed by other community members. And always search before posting ideas. Idea duplication is very frequent and it dilutes votes, which makes them less likely to attract PM attention.

 

3-Focus on question length and clarity

The way you will right your question will condition whether or not you will get an answer:

  1. Ask only 1 question per post: the longer and the more complex a question seems at first glance, and the less likely it is to get an answer quickly. Really! We (other community members) browse questions and if we get only 5 minutes ahead of us, we will focus on short and clearly expressed questions that we can answer in this short amount of time. Also, on this side, avoid asking a question as a answer to your or someone else's question if it is not directly related to the primary question. Doing this, you are again limiting your capacity to get a quick and rich answer, as most people will not see your question.
  2. Do not ask a new question in the answer thread of another post. This most of the time will be ignored by contributors because it has no visibility at all (only people who have already contributed to the thread will see it).
  3. Add screenshots and code samples. Do not hesitate to add some screen copies of the smart lists, flows, scheduling tab, admin sections you need help on (anonymize them if needed). If you need some help on an HTML template, post the code. Same for API usage.
  4. Do not ask the same question in multiple posts. It will scatter the answers at best, having various contributors answering multiple times on distinct aspects of the question in different places. At the end of the day, you will spend more time reconciling the answers and these answers will be of a lower quality because the contributors will not have the whole picture. It will also give people who answer the impression they become crazy, wondering whether they have dreamt answering it or not . If you have entered the question twice inadvertently (it happens) delete one of them rapidly.
  5. Use ideas as clues for something missing:  If you have the feeling something is not working as you would expect it from the product, search the "ideas" section. Very often someone has had the same need and entered an idea, indicating the need for an improvement. It will tell you that you are right. And then vote and look at the discussion in the idea if any workaround has been posted by a contributor.

 

4-Reward answers and responders

  1. Rewards the answers. Community members spend graciously some time trying to help and appreciate to be recognized for this. And believe me they also have a job aside from this. So, do not take it for granted, hit the "helpful" and "like" buttons as often as you want, and do it even if you did not write the question in the first place.
  2. Mark them as answered when you are done. This is done clicking the "correct answer" button on one of the answers and give the signal to other community members that you are OK and that they should concentrate on other pending questions. Also remember this is a way to reward the person who helped you, so hit wisely and do not reward yourself
  3. Vote for ideas when you find them relevant. It is not a waste of time, even if the number of open ideas is much larger than the number of done ones

 

-Greg

This post it to elaborate some strategies to handle the "sync with Marketo", based on the findings we had on how this field really work ("Sync with Marketo" mysteries part 1)

 

If you want to prevent some leads to be sync'ed to Marketo from the early beginning

Just set the "Sync with Marketo" to False in SFDC before enabling the sync. In the initial sync process, stop at the field mapping step, ask Support to enable the filter and, when it's done, complete the sync.

 

If you want to progressively expand the set of contacts and leads to be sync'ed

This may be needed for a progressive roll out in large orgs.

Start with disabling ("Sync with Marketo" = False) for everything in SFDC and progressively set the "Sync with Marketo" field to True for the BU's or geographies you want to activate.

 

If you want to deactivate the sync on some existing and already sync'ed leads / contacts before deleting them in Marketo

From our findings, the first way you should consider to set this up is to stop the sync FROM Marketo. Unchecking the "sync with Marketo" will propagate to SFDC at next sync, and from there, the sync will stop. So the smart campaign to set up to do this is:

  • Trigger: whatever event that should cause to stop syncing
  • Flow :
    • Change data value. Attribute = "Sync with Marketo", New value=False
    • Sync to SFDC
    • Delete lead

The "sync with SFDC" flow step is not mandatory, you may just rely on the automatic sync to happen. Still, having this step in the flow enables to make sure that the sync has occurred before deleting the lead. If you do not use a "Sync to SFDC" step, insert a "wait 1 hour" instead.

 

If for various reasons, you do not want to use Marketo to stop the sync but you want to do it in SFDC, then use a time based workflow so that the "sync" field is not unchecked immediately. This will leave time for the other value changes to be propagated to Marketo, where you will be able to use these value changes to ultimately delete the lead, after another wait of 2 hours.

TimeSalesforceMarketo
T0Lead/contact values are edited and trigger a Time based workflow for 1 hour
T0+5mnOn sync, the values are also changed in Marketo to reflect the changes from SFDC. Trigger a smart campaign to delete the lead, but start by waiting 2 hours
T0+1hEnd of the TBW. The "sync to Marketo" field is set to False
T0+1h 5mnThe sync stopsThe sync stops.
T0+2h 5mnEnd of the wait, the lead is deleted

 

 

If you want to reactivate the sync on leads/contacts that have stopped to sync

You do not have a choice here: the only place you can do this is in SFDC, even if you have not deleted it yet from Marketo.

 

-Greg

One common question is : how do I restrain some records from flowing from SFDC to Marketo when that cannot be handled with simple Salesforce sharing rules. For instance, making sure that inactive contacts or even contacts without emails do not pack into the Marketo DB and count against the licence. The answer is often to add a "Sync with Marketo" field and use it to filter out some records.

 

But the devil is in the details, so we ran a comprehensive test on how the "Sync with Marketo" really works and came back with a few interesting findings.

 

Finding #1: the only value of the field that matters is the one from SFDC.

I had read it already from Support, but, as St Thomas, we did some testing to verify it: if the field have a value on SFDC and another one in Marketo, on a same lead / contact, the value that determines whether or not the sync will happen is the one from SFDC. So if the field is set to "True" in SFDC, it will sync, otherwise it will not, whatever the value of the field in Marketo. No escape.

 

Finding #2: The sync stops immediately when the "sync with Marketo" is set to False in SFDC.

When the sync is disabled, it stops immediately. Really. There is not such thing as a "last sync". This means that the last "transaction" in SFDC is completely ignored from Marketo,with all the value changes in this transaction. Even the "Sync with Marketo = False" info will not visible to Marketo.

 

Example: Imagine that you have an SFDC workflow that disables the sync when the contact is set to "inactive". The workflow will fire IN THE SAME TRANSACTION as the "inactive contact" setting. Then the sync will be imediately disabled, thus preventing the next sync to happen. This means that Marketo will never know that the contact is not "Inactive" (or whatever field value change you may have done editing the contact). If you had expected to use this information in Marketo, for instance to remove the lead from the Marketo DB, you will not be able to . In another post, we will detail a workaround on how to handle that, but it will take some advanced SFDC skills.

 

Finding #3: you can cut sync from Marketo but you can only enable it from SFDC

This is a consequence from the previous findings and from the way the sync works.

 

Starting from a sync'ed lead or contact, if you uncheck the "Sync with Marketo" field in Marketo, you will be in a temporary situation where the field is still "true" in SFDC and the sync continues to work (See Finding #1). On next sync, which will work, the "False" value will be pushed to SFDC, and from there, the sync will be immediately disabled. So, you can easily disable the sync from Marketo.

 

But you cannot re-enable it from Marketo since, as the sync is now disabled, any change in Marketo will no longer be pushed to SFDC (See Finding #1). In SFDC, the field will remain to "False", unless you edit and change it there. And as stated in Finding #1, the only value that matters is the one from SFDC.

 

Consequence: if you need to reestablish a sync, it can only be done in SFDC.

 

Similarly, if you are creating new leads from Marketo, you should rather make sure they will be marked as "sync'ed" on creation in SFDC.

 

Finding #4: once the sync is disabled, the account info continues to sync

That one was not anticipated, although, after a second thought, since the account is a separate object in Marketo and SFDC, it makes sense. Let's say you have a contact and an account in SFDC that sync with Marketo. Then you deactivate the sync on the contact. The sync will stop for the contact. But not for the account. So if after this, you change some account values in SFDC, they will be visible on the lead in SFDC, even on the one that does not sync. It is a little surprising to see the industry or the billing address changing on a Marketo lead that is not supposed to sync...

 

The good news is that it is possible to also ask for accounts to have a sync filter.

 

Finding #5: if you stop a sync and reactivate it later, it will resync the right lead / contact

This is another apparently obvious one, but worth saying: if you unsync a lead contact, then change your mind before it has been deleted from Marketo, no problem, just reactivate the sync FROM SFDC, and it will automatically resync all field changes that have occurred in between.

 

-Greg

One common question is how can we add a list of emails to the durable unsubscribed list, coming for instance from other systems, without increasing the size of the Marketo database. This is a key requirement as soon as you use other systems than Marketo to send emails and want to keep complying with legal requirements.

 

This getting even more complex if one has to manage the fact that some of these leads already exist in the Marketo database and should be kept there, together with their historical information.

 

The idea is to create a simple program that will handle this efficiently and automatically. Here are the components of the program :

  1. Let start with the "DurableUnsubscribed Import" list : This is where the durable unsubscribed will be imported. Once the process is finished as we will see, the list will be empty.
  2. The "Durable Unsubscribed Deletion List" will contain all the leads that are unsubscribed but should not be kept in the database. In other words, they were added to Marketo when you imported leads to the Durable Unsubscribe Import list. It's filters are set as is :
    • Please note the usage of the "lead was created" filter with a "List Name" constraint : it enables you to detect specifically the leads that were added only to be added to the DUL.
    • We combine this with a "member of list" filter that also checks during the process that the lead is still a member of the import list. As the lead deletion will occur after 2 hours, it enables you to change your mind and remove a lead from the list.
  3. The smart campaign that does the job is a triggered one
    • It will fire when the lead is added to the list
    • As it is not allowed to change the "unsubscribe" field through an import, we need to handle it in the smart campaign flow :

      Then we wait 2 hours to leave Marketo ample time to log the un-subscription (We can even leave it 1 day, but do not make it too short). After this delay, we check the lead is still there, waiting for deletion and has been created during the import. For this, we check the lead still belong the the "Durable Unsubscribed Deletion List" smart list and, if so, we delete it.Finally, if the lead has not been deleted (meaning it was there already and is supposed to have some history in the database), we remove it from the Import List

 

Alternatively, we can set the smart campaign as a batch and run it manually after completing an import in the Import List. In this case, we would replace the trigger with the  following filter :

 

This process will also work if you use the import list API calls and import them to the "Durable Unsubscribe Import" List :

 

Do not hesitate to provide feedback and alternatives, I'll incorporate them.

 

-Greg

One of the recurrent question we face from Marketo users is "Why is there such a difference between the number of leads in my target and the number of emails actually sent". This can be explained my multiple, non exclusive factors that all can be identified and measured.

 

Some bad guys were part of your target:

You have not excluded a whole series of leads from your campaign: the blacklisted, the empty emails, the invalid emails (previous hard bounces), the unsubscribed and the not-so-ugly marketing suspended ones. If you have not done so yet, create a smart list in you lead database, name it "Global Exclusion List" and add all these filters to it, with a "ANY" (OR) rule logic:

Then create another smart list in the program that hosts you email campaign with the 2 following filters:

  • "Member of smart campaign" IS [The smart campaign that was supposed to send the email] (could be replaced by a member of program if it's an email program)
  • "Member of smart list" IS "Global Exclusion List"

That smart list will give you the list of leads that were excluded by Marketo from the email cast.

 

And BTW, since you now own the "Global Exclusion List", make it mandatory to all users to always add a "member of smart list" IS NOT "Global Exclusion List" to all your campaigns.

 

Some of your leads were hit by the communication limit:

This is the reason that users who started to use Marketo recently tend to forget the most easily. Remember, some limits are set to prevent you from overloading your prospects mail boxes, and apparently rightfully And guess what, Marketo does enforce these rules! As there is no filter that can give you the list of emails (Vote here: "Not email was sent" error constraints or filters & triggers); detecting them is a little tricky. You will have to go the smart campaign that was supposed to send the email and the click on the "Results" tab. Finally, at the bottom, enter "communication limit" in the search box:

The list of leads that were impacted will show up, and the count will be visible at the bottom-right corner of the screen. Remember here that communication limits are evaluated per day (based on the calendar day in the subscription time zone. (midnight-midnight)) and per rolling period of 7 days. You can override these communication limits in a smart campaign, but use this with extreme care and monitor closely your unsubscribe rates when you do so (on all emails sent within the same period of time).

 

Some of the leads were in fact duplicates

Marketo takes care of you: as sending the same email twice to someone is not really a commonly accepted best practice, if Marketo detects 2 or more duplicates in your smart campaign target, it will automatically remove the superfluous ones from the email cast. These are quite easy to list. Create a smart list with the following filters:

And remember that Marketo did not remove all the leads in this list: it sent email to one lead for each set of duplicates in the campaign and skipped the others.

The hard point about duplicates is that you cannot exclude them from your campaign preventively: if you add a "Duplicate field is Email address" filter, it will exclude all of them, not just the redundant ones.

 

 

Of course, all this would be made easier if it was possible to filters leads for which an email was targeted but not sent: "Not email was sent" error constraints or filters & triggers

 

-Greg