Knowledgebase

Issue Description How to use a script token to calculate and populate the number of years since a given date Issue Resolution This can be achieved by using a velocity (email script) token: #set( $defaultTimeZone = $date.getTimeZone().getTimeZone("America/New_York") )  #set( $defaultLocale = $date.getLocale() )  #set( $calNow = $date.getCalendar() )  #set( $ret = $calNow.setTimeZone($defaultTimeZone) )  #set( $calConst = $field.in($calNow) )  #set( $ISO8601 = "yyyy-MM-dd'T'HH:mm:ss" )  #set( $ISO8601DateOnly = "yyyy-MM-dd" )  #set( $calJoinDate = $convert.toCalendar(  $convert.parseDate(      $lead.JoinDate,       $ISO8601DateOnly,       $defaultLocale,       $defaultTimeZone     )  ) )  #set( $differenceInYears = $date.difference($calJoinDate,$calNow ).getYears() )  #set( $friendlyLabel = $display.plural($convert.toInteger($differenceInYears),"year") )  You joined us ${differenceInYears} ${friendlyLabel} ago!  Where $lead.JoinDate is the joining date. More at blog.teknkl.com/velocity-days-and-weeks/

Issue Description You receive an error in ToutApp - "IMAP access is disabled for your domain. Please contact your domain administrator for questions about this feature. (Failure)" Issue Resolution This due to an invalid Gmail connection For this error message to be resolved, we recommend looping in with your Gmail Administrator regarding the IMAP access of your domain and whether or not it can be enabled. See the link below for additional reference on this for your Gmail Administrator: support.google.com/a/answer/105694?hl=en

Issue Description How to delete email from ToutApp Live Feed   Issue Resolution The way to stop the tracking is to archive the email.  All you need to do is find the email, click the arrow next to Email, and click "Archive". This will stop the tracking and it won't show up in the live feed.   )   Who This Solution Applies To ToutApp customers Is this article helpful ? YesNo

Issue Description Getting error "Salesforce 551 unauthorized bounce" in ToutApp   Issue Resolution - Head on over to your Salesforce instance and login.  - Once you're logged in, head over to "Setup" > "Email" > "My Email to Salesforce"      - In the "My Email to Salesforce" page, head over to the "My Acceptable Email Addresses" section and ensure the all the addresses you use are listed in here:     - Just below "My Acceptable Email Addresses" you can set your email logging settings to how you would like them to enter your SFDC.    - Save your settings.           Who This Solution Applies To ToutApp customers Is this article helpful ? YesNo

Issue Description How to disable Niko from ToutApp extension Issue Resolution To remove Niko, simply click on the blue Tout envelope at the top right of your browser, then manually uncheck the box next to "Show Niko as I browse the web". Refresh the page, and Niko should disappear. Who This Solution Applies To ToutApp users with Niko

Issue Description Email Insights does not display any data or metrics for specific program when the emails in the program are operational.   Issue Resolution Operational emails are hidden by default, so no data or metrics will be shown in Email Insights unless 'Operational Emails' are included   "Does Email Insights support Operational emails? Yes. By default, Operational emails are hidden from view and querying. However, you may change this setting under the Personal Settings panel." docs.marketo.com/display/public/DOCS/Email+Insights+FAQ   Who This Solution Applies To Customers using Email Insights Is this article helpful ? YesNo

Issue Description Customers based in our Sydney datacenter experienced a service issue which caused an intermittent disruption in email sends beginning 10:30 AM AEST local time on November 12, 2018. This issue was resolved at 1:00 pm AEST and all emails are now sending normally. No customers outside of the Sydney datacenter were impacted. During the impacted time frame, some email sends were lost and will not be delivered. The issue occurred intermittently during the affected time, so some emails were sent successfully, while others were not. This documentation provides details on how to identify the impacted lead records. Identifying Affected Leads Symptoms All lead records that were sent emails during the impacted time will show an "Email Sent" activity (as per normal behavior) Leads that were not impacted and successfully had emails sent will show the corresponding "Email Delivered" or "Email Bounced" activities (as per normal behavior) However, the impacted leads that emails did not send to will NOT have any "Email Delivered" or "Email Bounced" activity. They will show the "Email Sent" activity, but there will not be any corresponding activity to indicate what the result was - Delivered or Bounced. The emails that failed to send will not be retried. Leads impacted by this service issue will not receive the email unless customers choose to re-send it through another Campaign or Email Program send. Using Smart Lists to Identify Leads To identify affected leads create the following Smart List: Filter logic: ALL filters Flow Step #1: Was Sent Email Email is any Date of Activity is ‘2018-11-12’ Flow Step #2: Not Was Delivered Email Email is any Date of Activity is ‘2018-11-12’ Flow Step #3: Not Email Bounced Email is any Date of Activity is ‘2018-11-12’ Flow Step #4: Not Email Bounced Soft Email is any Date of Activity is ‘2018-11-12’ Once complete, your Smart List will look like this: The lead records returned by this Smart List will be the impacted records that did not have emails sent during the affected time frame. *NOTE: In a limited number of circumstances, there is a possibility that a very small number of leads did not have the "Email Sent" activity logged. This will be an uncommon occurrence, if it happens at all. Who This Solution Applies To Customers in the Sydney Datacenter. No customers whose Marketo instances are located in other datacenters are impacted in any way. Where to get additional help If you would like any additional help please contact Marketo Support.

Summary A service issue has been identified that can potentially cause duplicate leads to be generated in Marketo for customers using Microsoft Dynamics (MSD) CRM. This issue only applies to customers using MSD 2016, and only when upgrading to MSD version 9. Who is Impacted All customers using the native CRM Sync between Marketo and MSD 2016  Already Impacted: Customers using MSD  2016 Version 9 with Marketo Lead Management (MLM) solution version 4.0.0.23 or lower Potentially Impacted: Customers using MSD 2016 version 8 or lower who plan to upgrade to version 9 The issue of duplicate leads being created occurs when the MSD instance is upgraded to version 9 All customers who have already upgraded to MSD v9 are already impacted If you have MSD but have not yet upgraded to v9, you are not yet impacted, but could be by upgrading to MSD v9 Who is Not Impacted Customers using MSD On Premises CRM instances Customers using Dynamics 2011, Dynamics 2013, or Dynamics 2015 Customers with Salesforce CRM When the Service Issue Occurs Qualifying a Lead to a Contact in MSD may not be reflected properly in your Marketo subscription. Expected Behavior: The existing Lead record in Marketo is converted to a Contact record (i.e. the Microsoft Type for the person record should change from Lead to Contact). The existing record in Marketo remains synced to this record in MSD Current Behavior: A new Contact record is created in Marketo to sync with the Contact record in MSD. The existing Lead record in Marketo becomes orphaned (no longer synced with any record in MSD). Additionally, the orphaned Lead record in Marketo contains the activity history while the new Contact record in Marketo contains the contact information Resolution There are two parts to the solution, depending on whether you have already upgraded your MSD 2016 instance to version 9. If you have not yet upgraded your MSD 2016  instance to v9, you will only need the first step. If v9 has already been installed, you will need to perform both. Part One - Install the latest Marketo Lead Management solution A new version of the Marketo Lead Management solution has been released for Dynamics 2016 that prevents duplicate records from being created when upgrading to MSD 2016  v9. This solution must be installed before upgrading to MSD 2016 v9. Installation Process      1. Within your Marketo subscription, you will need to download the latest version of the Marketo Lead Management solution.  Documentation on how to download the Marketo Lead Management solution for MSD can be found here:  Download the Marketo Lead Management Solution Documentation on how to upgrade the Marketo Lead Management solution for MSD can be found here: Upgrade the Marketo Solution for Microsoft Dynamics NOTE: Microsoft Dynamics has 4 product versions that Marketo supports; Dynamics 2011, Dynamics 2013, Dynamics 2015 and Dynamics 2016. The only product version this applies to is Dynamics 2016. No other product versions are impacted in any way. 2. Install the new Marketo Lead Management solution in your MSD 2016 instance as a normal update. Be sure to install the new solution on top of your existing solution in Microsoft Dynamics as a normal update.  Part Two – Correcting Duplicate Records in Marketo This step only applies to customers who have already upgraded to MSD 2016  v9 prior to the new Marketo Lead Management solution being released. This part applies to customers who have had duplicate records created in Marketo. In order to eliminate the duplicate records that were created in error, we must first identify those records. The next step is to merge the two duplicates together. In this scenario, due to both records being synced to MSD, it is a little complicated. Build a Smart List to Identify Duplicates Use the following filters to identify the impacted records: Duplicate Fields > Email Address Microsoft is Deleted > True Microsoft Type > Lead When finished, your Smart List will look like this: This Smart List will identify the duplicate records created by this service issue. When this issue occurs, both of the duplicate records are synced to MSD. It is not possible to merge two records if they are both synced to MSD. However, Marketo Support is able to disconnect the sync of one record on the back end and perform the merge of the two records. Submit a Case with Marketo Support Merging these duplicate records is only possible when done by Marketo’s Engineering team. Contact Marketo Support to open a Support case. Be sure to include all related details, including the link to your Smart List. Marketo Support will evaluate the duplicates and escalate the ticket to our Engineering team. The Engineering team will perform the merge for the records.

Issue Description You have created a Smart List with a filter for a date type field and you are using the constraints either “before” or “on or before” a particular date. However, records with empty value on those field get qualified. Issue Resolution When you create a Smart List using a date field filter (e.g., Date of Birth, SFDC Created Date) and use the “before” or “on or before” constraints, the Smart List will also include people who have no value in said date field. This is an expected behavior as  by default Null value is treated as a timestamp with a default value (e.g Jan 1 1900). This is similar to a token having default value and this is also mentioned as a caution within our knowledge base document over here. The work around is to use an addition filter or to make sure that the date value is populated for all the records. You can learn the importance of date stamping in this Champion blog post.

Overview GoToWebinar is changing their authentication protocol used for API access. Their legacy protocol, OAuth v1.0, will no longer be used after January 31, 2019, and all services accessing GoToWebinar (Marketo) will be required to use the new authentication protocol, OAuth v2.0. Marketo has already updated our system to utilize the new OAuth v2.0 authentication protocol for new login authentication. All newly initiated service authentications between Marketo and GoToWebinar will use OAuth v2.0. However, all existing GoToWebinar services currently logged in and in use now must be reauthenticated manually. All customers who use GoToWebinar must reauthenticate each of the logins for these services in your Marketo instance by navigating to Admin > LaunchPoint. Any API calls still using OAuth v1.0 after January 31 will fail. This will result in statuses not being shared between Marketo and GoToWebinar and will prevent users from syncing Event programs with a GoToWebinar event. FAQ Why is this change happening? GoToWebinar is strengthening their security protocols for API login access to their services. This requires using an upgraded version of the login protocols, known as OAuth v2.0. Is this a Marketo change or a GoToWebinar change? This change is being implemented by GoToWebinar to strengthen their security protocols. Marketo has upgraded our system to allow a seamless transition, but the protocol change is being made by GoToWebinar. When does this take effect? The new protocol version OAuth v2.0 is active and in place now. GoToWebinar has placed an announcement on their status page stating that the deprecation of the legacy OAuth v1.0 is scheduled for January 31, 2019. All connections between Marketo and GoToWebinar that are still using the legacy OAuth v1.0 protocol will be refused by GoToWebinar after that date. This includes new access requests as well as those currently active and in use. What do I need to do? Reauthenticate your GoToWebinar services with a fresh login from within your Marketo instance before January 31, 2019. Why do I have to do it myself? Marketo has made the changes necessary to utilize OAuth v2.0 for new authentication logins being made moving forward. However, all logins already in use were initiated on the older protocol, OAuth v1.0. Marketo doesn’t know your personal login credentials, so you need to do the reauthentication directly. Is there a different procedure for how to enter the credentials inside the Marketo UI? No. The update Marketo made was on the back end, so there is nothing different to how you enter the info. The UI is the exact same as it was. What happens if I don’t reauthenticate the login before January 31, 2019? All connections between Marketo and your GoToWebinar services will be refused by GoToWebinar on their end. If I miss the deadline and the connection is shut off, how will I know? You’ll find error messages in your Marketo instance where the services are used. See the section below for “Symptoms of a disconnected service” to know what to look for. If I miss the deadline and the connection is shut off, how do I get it working again? Reauthenticate your login credentials in Admin > LaunchPoint. See the “Customer Action Needed” section below for step by step directions. Customer Action Needed All customers who use GoToWebinar must reauthenticate the login credentials for each user. This must be done before January 31, 2019 to avoid experiencing disruption of your services. 1. Navigate to Admin 2. Click LaunchPoint to open the list of Installed Services 3. Click and open the GoToWebinar service to edit it 4. Click the Log into GoToWebinar button. 5. In the GoToWebinar Sign In pop-up window, enter your GoToWebinar email and password and click Sign In. 6. After the window closes, click Save DONE! By reauthenticating the login, you’ve ensured that the service is using the new OAuth v2.0 protocols. Symptoms of Disconnected Service Here is a list of what to expect if the integration with GoToWebinar is disconnected due to the deprecation of OAuth v1.0 on January 31, 2019. 1. The service listing in Admin > LaunchPoint will have a status of Failed along with a few details. A. Reauthenticating your login credentials will resolve these errors. 2. Event programs that have not yet synced with GoToWebinar will be unable to sync and will return errors. A. Reauthenticating your login credentials will resolve these errors. B. For reference, here is the documentation on how to sync an Event Program to GoToWebinar. 3. Existing programs which were synced with GoToWebinar prior to the deprecation will show no difference. However, if anyone is added to the program with a ‘Registered’ status, Marketo will attempt to push this record to GoToWebinar and will fail due to the deprecation of the OAuth v1.0 protocol. This will give the record a status of ‘Registration Error’. If this occurs, this data is not lost. A. Reauthenticate the GoToWebinar service B. Manually refresh the webinar attendance. Navigate to the Event Actions menu of your Event Program and select Refresh from Webinar Provider 4. Records that were already registered with GoToWebinar before the service stopped will still be able to receive the correct {{member.webinar url}} token. That data for the token will already be in Marketo, so reminder emails will still have the right links to the actual webinar even if the service was stopped after they were registered. The attendee report won’t be able to come down from GoToWebinar with the connection cut off, but at least your leads will still have the link to get to the webinar. 5. If the service is no longer active and an existing webinar completes, normally this would record attendance information and sync this back to Marketo and change the status of program members. However, if the service is inactive, this will fail silently, and no status change will occur. Manually refreshing from webinar provider will also silently fail if done while the service is still inactive. The notification will show that there are no updates. A. Reauthenticate the GoToWebinar service B. Manually refresh the webinar attendance. Navigate to the Event Actions menu of your Event Program and select Refresh from Webinar Provider C. Now that the credentials were reauthenticated and the service is back online, the manual refresh will work properly. How to Get Additional Help Feel free to ask questions in the comments section of this documentation. Our Support team will be monitoring the comments to help answer your questions. You can also Contact Marketo Support at any time.

It's one of the most common calls we get in Support - "This lead should have qualified for this campaign, but it didn't. Why?"  Here's how we go about answering this question, and you can do it too.   Did the lead actually qualify? Sometimes the leads do qualify for the campaign but don't go through the flow.  One quick way to check this is to look at the campaign membership.  If the lead qualified, it will become a member of the Smart Campaign, even if it doesn't go through the flow. Has the lead gone through the flow before?  We can check this in the campaign results. If it has, we need to see if the campaign allows the leads to go through the flow more than once. If the campaign is set up to allow leads to run through the flow multiple times, then we need to proceed with troubleshooting. But if it is not, we have our answer - the lead didn't go through the campaign because it had done so previously and couldn't go through again.   Did the trigger have constraints? If it didn't, we move along, but if it did, we need to check and see if the lead met the requirements of the constraints at the time the lead hit the trigger. This is very important.  If, for instance, there was a constraint that required a value in a field, and that field was not populated before the trigger went off, then the lead wouldn't qualify.  The timestamps in the activity log for the trigger activity and the value change might be the same, but if the value change for the field happened even a fraction of a second after the trigger event, it's still too late. The lead will not qualify.  Looking at the lead now, it looks like it qualifies, but at the moment the campaign was triggered, the lead had different information, so check to see when the required values were written to the lead.   Did the Smart List have filters in addition to the trigger? Just like the constraints, we need to confirm the lead satisfied the filter requirements before the trigger fired.  This can get complicated if one of your filter requirements is "Member of Smart List" because you are going to have to go into the referenced Smart List and confirm the lead met all those requirements, and if that Smart List also contains a "Member of Smart List" filter, then will have to check that one as well and, well, you will see why we in Support recommend against nesting Smart Lists.   Has the campaign been changed since the lead hit the trigger? We tend to assume that the campaign we are looking at today is the same as it was when the lead hit the trigger, but this is often not the case.  Check through the Audit Trail to see if there have been any changes.  Maybe a constraint was added, removed, or changed.  Maybe the filter logic was changed from AND to OR.  Maybe it used to only let leads go through the flow once.  If the campaign was changed, you will need to go through the troubleshooting steps above all over again, checking against what the campaign used to have, rather than what it has now.  If you have nested Smart Lists, it may be that the campaign didn't change at all, but a filter criteria in a the secondary Smart List did.  This is another reason why nested Smart Lists should be avoided if possible.   If you go through these steps and still can't figure it out, open a case in Support and include the results of the troubleshooting above so we can look into it further.

概要 弊社サンノゼデータセンターの一部のお客様環境におきまして、日本時間の2018年9月12日(水)よりメール送信が遅延または中断されるサービス障害が発生いたしました。 サンノゼデータセンター以外のお客様環境には影響はありません。 この障害は既に解消されており、現在ではメール送信は正常に機能しております このメール送信遅延障害からの復旧作業中に送信されたメールの一部が消失し、配信されませんでした。この文書はサンノゼデータセンターのお客様にこの障害によって影響のあったキャンペーンを特定する方法を詳細にご案内するためのものです。 お客様には多大なるご迷惑をおかけいたしましたことを深くお詫び申し上げます。私共は今回の障害が非常に重大な問題であると認識し、影響のあったキャンペーンの特定を支援させていただくと共に今後同様の問題の発生がないよう回避策を講じる所存です。 影響 このメール送信遅延障害の復旧作業の間にメール送信処理中に使用されるアクティブメッセージキューサービス (AMQ: Active Message Queue) の再初期化を行いました。このAMQのリスタート時にキューで待機していたメールが消失しました: トリガーキャンペーンによって送信され、AMQで待機していたメールは処理されないまま、消失しました。 リスタート時もしくはその直前にバッチキャンペーンによって送信されたメールはリードのアクティビティとして「メールの送信」は記録されますが、「配信済みメール」が記録されない場合があります。現象は以下の2つのパターンとなります: 一部のバッチキャンペーンはすべての対象リードのメールが送信済みとなりますが、配信済みが0となります。この場合、メールは一切配信されません。 それ以外のバッチキャンペーンではメールは送信済みで、かつ配信済みとなっているものとそうでない(配信済みが記録されない)ものが混在している状態となります。このように少しでも配信済みが記録されている場合はそのキャンペーンのメールはすべて正常に配信されています。 障害発生日時 メール送信の遅延が日本時間の2018年9月12日(水)の早朝(深夜帯)から発生し始めました。 AMQの再初期化によってメールが消失し、配信されなかった時間帯は以下の通りです: 2018年9月12日(水) 4:30AM - 5:00AM JST 2018年9月13日(木) 1:15AM - 1:50 AM JST 問題は2018年9月13日(木) 2:30AM JST 頃に解消しました。 影響のあったキャンペーンの特定方法 スマートリスト スマートリストを使用して、メールが消失したかどうかを確認する方法が2種類あります。一つはトリガーキャンペーンを、もう一つはバッチキャンペーンを特定します。 トリガーキャンペーンを特定 AMQが再初期化された際にトリガーキャンペーンによって送信され、AMQで待機していたメールは処理されないまま、消失しました。 以下のスマートリストはトリガーキャンペーンによって送信されたけれども、配信されずに消失したメールの対象リードのリストを返します。 スマートリストフィルタールール論理式:  全フィルターを使用 フィルター #1: スマートキャンペーンのメンバー リード: [指定のリストに存在する]  "<トリガーキャンペーン名>" フィルター #2: メールを送信済み メール: [指定の値と等しい] "<トリガーキャンペーンのメール名>" アクティビティ日: [指定の値と等しい]  2018/09/12 フィルター #3: メール未配信 メール: [指定の値と等しい] "<トリガーキャンペーンのメール名>" アクティビティ日: [指定の値と等しい]  2018/09/12 フィルター #4: ソフトバウンスメールではない メール: [指定の値と等しい] "<トリガーキャンペーンのメール名>" アクティビティ日: [指定の値と等しい]  2018/09/12 フィルター #5: バウンスメールではない メール: [指定の値と等しい] "<トリガーキャンペーンのメール名>" アクティビティ日: [指定の値と等しい]  2018/09/12 完成しますと、以下のようなスマートリストとなります (英語版UI) :    バッチキャンペーンを特定 AMQのリスタート時もしくはその直前にバッチキャンペーンによって送信されたメールはリードのアクティビティとして「メールの送信」は記録されますが、「配信済みメール」は記録されない場合があります。現象は以下の2つのパターンとなります: 一部のバッチキャンペーンはすべての対象リードのメールが送信済みとなりますが、配信済みが0となります。この場合、メールは一切配信されません。 それ以外のバッチキャンペーンではメールは送信済みで、かつ配信済みとなっているものとそうでない(配信済みが記録されない)ものが混在している状態となります。このように少しでも配信済みが記録されている場合はそのキャンペーンのメールはすべて正常に配信されています。 以下のスマートリストにて特定のバッチキャンペーンに対して本障害の影響があったかどうかを確認できます: スマートリストフィルタールール論理式: 詳細フィルターを使用 [1 and 2 and (3 or 4 or 5)] フィルター #1: スマートキャンペーンのメンバー リード: [指定のリストに存在する]  "<バッチキャンペーン名>" フィルター #2: メールを送信済み メール: [指定の値と等しい] "<バッチキャンペーンのメール名>" アクティビティ日: [指定の値と等しい]  2018/09/12 フィルター #3: メール配信済み メール: [指定の値と等しい] "<バッチキャンペーンのメール名>" アクティビティ日: [指定の値と等しい]  2018/09/12 フィルター #4: ソフトバウンスメール メール: [指定の値と等しい] "<トリガーキャンペーンのメール名>" アクティビティ日: [指定の値と等しい]  2018/09/12 フィルター #5: バウンスメール メール: [指定の値と等しい] "<トリガーキャンペーンのメール名>" アクティビティ日: [指定の値と等しい]  2018/09/12 完成しますと、以下のようなスマートリストとなります (英語版UI) : キャンペーンのメール送信結果の確認 スマートキャンペーンのサマリーページにそのキャンペーンによって送付されたメールの結果が確認できる「メール」タブがあります。 影響のあったキャンペーンを特定するには、障害が発生した日付で配信済み、ハード・ソフトバウンスが0、送信済みと保留中の数が等しいかどうかをご確認ください。以下は一例です: もし、すべての送信メールが保留中の状態である場合、本障害に当たっていると判断できます。現時点でもこの状態の場合はこれらの保留中のメールが配信されることはありません。 メールの効果レポート メールの効果レポートで送信したメールにどのような効果があったか確認できます。キャンペーンに影響があったかどうかを確認するには特定の日付、特定のメールのメールの効果レポートをご確認ください。スマートキャンペーンサマリーのメールタブの時と同様に、障害が発生した日付で送信済みと保留中のメールの数が同じ場合、本障害に当たっていると判断できます。 支援が必要な場合 もしこの障害の影響があったかどうかを確認するために弊社からの更なる支援が必要な場合はMarketoカスタマサポートsupport.marketo.com までご連絡ください。 

Summary Customers based in our San Jose datacenter experienced a service issue causing an interruption in email sends beginning on Tuesday, September 11, 2018. No customers outside of the San Jose datacenter were impacted. This issue has been mitigated and emails are now sending properly. During the impacted timeframe, some email sends were lost and will not be delivered. This documentation is for customers based in the San Jose datacenter and provides details on how to identify the impacted campaigns. We sincerely apologize for this issue and are committed to helping our customers identify impacted campaigns and ensuring proper safeguards are put in place. Impact During the recovery process, we reinitialized the Active Message Queue (AMQ), which is used to process emails during the sending process. The restarts of the AMQ had the following impact: Emails sent by Trigger campaigns during this timeframe (and those waiting in queue beforehand) could not be processed and were lost. Emails that were sent by Batch campaigns during this time or just prior may show that they were sent, but do not show a delivered activity. There are two ways that these could appear: Some Batch campaigns will show every email as sent, but zero delivered. If there are zero emails showing delivered, these Batch campaigns will not send those emails. Other Batch campaigns will show a mix of some emails sent but not delivered and some that show they were successfully delivered. If there are any deliveries showing in the campaign, the rest of the emails sent should send normally. Timeframe The email sending delays began on the morning (PDT) of Tuesday, September 11, 2018. The AMQ reinitialization caused emails to not be sent during the following timeframes: September 11, 2018, 12:30 PM PDT – 1:00 PM PDT September 12, 2018, 9:15 AM PDT – 9:50 AM PDT The problem was mitigated at approximately 10:30 AM PDT on Wednesday, September 12, 2018. Identifying Impacted Campaigns Smart Lists There are two methods to identify which campaigns had lost emails by using Smart Lists; one for Trigger campaigns, and the other for Batch campaigns. Identifying Trigger Campaigns Emails that were sent by Trigger campaigns while the AMQ was being reinitialized and all emails sent by Trigger campaigns that were waiting in queue to be processed by the AMQ when it was reinitialized were lost. The Smart List below will give you a list of affected leads that had an email sent by a Trigger campaign, but the email was lost before sending. Smart List Filter Rules:   ALL filters Filter #1: Member of Smart Campaign Campaign is "<YOUR_TRIGGERED_CAMPAIGN_NAME>" Filter #2: Was Sent Email Email is "<YOUR_TRIGGERED_CAMPAIGN_EMAIL_NAME>" Date of Activity is 09/12/2018 Filter #3: Not Was Delivered Email Email is "<YOUR_TRIGGERED_CAMPAIGN_EMAIL_NAME>" Date of Activity is 09/12/2018 Filter #4: Not Email Bounced Soft Email is "<YOUR_TRIGGERED_CAMPAIGN_EMAIL_NAME>" Date of Activity is 09/12/2018 Filter #5: Not Email Bounced Email is "<YOUR_TRIGGERED_CAMPAIGN_EMAIL_NAME>" Date of Activity is 09/12/2018 Once complete, your Smart List will look like this: Identifying Batch Campaigns Emails that were sent by Batch campaigns while the AMQ was being reinitialized, or just prior, may show that they were sent, but do not show a delivered activity. There are two ways that these could appear: Some Batch campaigns will show a mix of some emails sent but not delivered, and then some that show they were successfully delivered. If there are any deliveries showing in the campaign, the rest of the emails sent should send as normal and these campaigns were not impacted. Other Batch campaigns will show every email as sent, but zero delivered. If there are zero emails showing delivered, these Batch campaigns will not send those emails. These are the Batch campaigns that were impacted. The Smart List below will show you how to identify whether a specific Batch campaign was impacted. Advanced Smart List Filter Rules: 1 and 2 and (3 or 4 or 5) Filter #1: Member of Smart Campaign Campaign is "<YOUR_BATCH_CAMPAIGN_NAME>" Filter #2: Was Sent Email Email is "<YOUR_BATCH_CAMPAIGN_EMAIL>" Date of Activity is 09/12/2018 Filter #3: Was Delivered Email Email is "<YOUR_BATCH_CAMPAIGN_EMAIL>" Date of Activity is 09/12/2018 Filter #4: Email Bounced Soft Email is "<YOUR_BATCH_CAMPAIGN_EMAIL>" Date of Activity is 09/12/2018 Filter #5: Email Bounced Email is "<YOUR_BATCH_CAMPAIGN_EMAIL>" Date of Activity is 09/12/2018 Once complete, your Smart List will look like this: Campaign Email Results The Summary page in Smart Campaigns has a tab called Email that shows the results of any email sent by that campaign. When trying to identify campaigns that were impacted, you will be looking for campaigns that had emails sent but had zero emails delivered or bounced. All emails will be in Pending. Here’s an example of what to look for: If you see email results showing that all emails that were sent are in pending, this is a Batch campaign that was impacted. No emails from this campaign will be sent. Email Performance Report The Email Performance Report will show you the stats for how your emails have performed. When trying to identify impacted campaigns, check an Email Performance Report for emails on the specific date you need. If you see the same behavior of a large volume of emails sent but all of them in Pending, you’ll be able to track which email sends were impacted. Additional Help If you would like any additional help identifying impacted campaigns, please Contact Marketo Support

Issue Description Consider a scenario where you wanted to setup a campaign flow in such a way that their program status needs to be changed as “Influenced” if they are currently not a member of that program and the default choice is “do nothing” as seen in the below screenshot. However, you will be able to see that for records who isn’t member of program is getting assigned with default choice and not with the choice 1. Issue Resolution The flow step will change the program status to influenced only if they are member of program and have the status anything apart from "No show", if not default choice will be selected. The flow-step will not add the lead to the program and then change the program status when "Add choice" is used in the "Change program status" flow step. If there inst a choice added as shown in the below image, then the person will also be made a member of the program if they weren't already. Who This Solution Applies To

Issue Description You tried to send a test email through Tout but it is saying that you need to set up an SMTP server.  The email identity set-up has the Tout servers enabled in my account. Issue Resolution We no longer offer ToutApp Default delivery channel. Customers can either use office365, gmail, or a custom delivery channel. The easiest way is to connect to their gmail account and use gmail as the delivery channel. Here are some docs that will help with set up as well as basic information around smtp servers & delivery channels: docs.marketo.com/display/DOCS/Setting+up+Your+Delivery+Channel docs.marketo.com/display/DOCS/Verify+Your+Email docs.marketo.com/display/DOCS/Setting+up+an+SMTP+Server Who This Solution Applies To ToutApp Customers

Issue Description Duplicate records were sent an email from an Email Program. Issue Resolution While Marketo prevents sending emails to duplicate records (i.e. same email address) via the same smart campaign, it is possible to send an email to duplicate record when there is A/B test configured for the email program. Specifically, one record can be sent an email from the test sample size while the duplicate record can be sent the email from the winner sample size [see For example, if there are two records for "mary@mail.com" in the audience, Mary can be sent two emails as follows: One record can be sent the email by qualifying for receiving the test from the sample size of the A/B test The other record can be sent the email by qualifying for receiving the winner from the sample size of the A/B test Note: sending the test and sending the winner utilizes individual campaigns which is why the systematic deduplication of emails within a smart campaign does not take effect for this scenario. To prevent this from occurring, exclude the duplicate records from the smart list of the email program.

Marketo will be performing mandatory maintenance in our London data center from Saturday, April 13, 2019, at 8:00 PM GMT to Sunday, April 14, 2019, at 2:00 AM GMT. Only Marketo instances in the London data center will be affected, and no Marketo instances in any other data center will be impacted.The maintenance is expected to take as little as two hours to complete, however, customers should plan for service disruptions for the entire maintenance window to account for unforeseen complications. Service will be restored as quickly as possible. All Marketo services for customers in the London data center will be disrupted during the maintenance window. To help you plan for the service disruption, we have gathered and answered some frequently asked questions. Why is the maintenance needed? As network traffic increases, we must also scale our infrastructure to prevent unplanned service disruptions. We are replacing our network’s firewall and load balancer devices, which will improve security, add capacity, and increase availability for all customers. The current network devices are processing more traffic than they are designed to handle, so immediate action is required. Upgrading our network infrastructure re-establishes stability to our services, providing better service for all customers Why is the maintenance scheduled on April 13 th ? We never want to interrupt service. However, if we have to, the goal is to minimize impact as much as possible. As a global operation, it’s difficult to find a time that has the lowest traffic in all geographic regions. The maintenance was scheduled for a Saturday because, as a weekend, it doesn’t fall on a workday in any country. We’ve scheduled additional coverage from our Network, Engineering, and Support teams and will be actively monitoring progress throughout the maintenance period. If the maintenance is only expected to take two hours, why is it scheduled for six hours? In previous maintenance replacements of the same devices, we were able to complete the process within the same amount of time. Therefore, we are expecting that it should only take two hours. However, there is always the possibility of unforeseen circumstances that could extend the recovery time. The additional time is to account for this possibility and all customers should plan for service to be disrupted for the entire six-hour timeframe. Timeline: April 13, 8:00 PM GMT - 8:30 PM GMT Status page maintenance notice updated to "In Progress" All Marketo back-end services stopped in the London data center Firewall and load balancer upgrades and maintenance initiated April 13, 8:30 PM GMT - 10:00 PM GMT Firewall and load balancer maintenance completed Begin system recovery process Systems restored, and network system monitoring begins Status page maintenance notice updated April 13, 10:00 PM GMT - April 14, 2:00 AM GMT Ongoing system monitoring and analysis of any abnormalities Where can I get updates during the maintenance process? Marketo's Status page, status.marketo.com will be updated with the progress of the maintenance process in real time. Please see the notice "Scheduled Maintenance in London data center, April 13," and subscribe to updates to have the most current information sent directly to you in real time. What services will be affected? During the maintenance process, all Marketo services housed in the London data center will be disrupted. This will include interactive logins, email, landing pages, forms, and all other services that require access to the instance, such as API and LaunchPoint services. Many back-end services will be stopped, therefore campaigns and programs scheduled to run or in progress during this time will be delayed. Will images display in emails? If the images are hosted in your Marketo instance, and your instance is in the London data center, those image files will not be accessible, therefore they will not display during the maintenance downtime. Images hosted externally will display as normal. Will hyperlinks in emails connect to the page they should go to? This depends on whether the link is being tracked or not. If the link is a tracked link, it will not connect to the destination URL. If the link is not being tracked, it will connect as expected. Email links are tracked by default, but that tracking can be disabled. Tracked links operate by first going through a Marketo server to identify which person clicked which link. The page then navigates to the corresponding destination page as expected. While the maintenance is in process, that Marketo server will not be reachable. Therefore, tracked links will not be able to navigate to the destination page. Links that are not tracked do not go through a Marketo server and will not be affected. Will our unsubscribe page be accessible? While the maintenance is in process, the London data center will be offline, therefore unsubscribe pages hosted in London Marketo instances cannot be reached. Any person who navigates to one of these unsubscribe pages will receive an error message. The error message will state that there was a technical issue preventing the unsubscribe request and they will need to re-attempt to unsubscribe later. What happens if a person clicks the unsubscribe link that Marketo adds to email footers? This depends on whether the unsubscribe link is being tracked or not. If the link is a tracked link, it will not connect to the destination URL. If the link is not being tracked, it will connect as expected. The default behavior for unsubscribe links in the email footer is to be tracked. This tracking can be removed by customizing the HTML of the footer as detailed here. However, if the tracking is still in place, the link clicks will result in errors. This will be true for custom unsubscribe pages hosted outside of Marketo as well as those within Marketo. If we use a non-Marketo unsubscribe page and the link is not tracked, will it connect? Yes. However, you should watch for a secondary issue. In most use cases, customers will use the Marketo API to send that unsubscribe data back into Marketo to update the corresponding record as unsubscribed. If that API call is made during the maintenance downtime, the API call will fail and the unsubscribe request will not be logged. Customers should retry these calls after the maintenance window. Will the unsubscribe link added by email providers function during the maintenance? Most email providers will add an unsubscribe link to the top of email messages. When clicking on this link, this unsubscribe request goes through the email provider and doesn’t navigate to your unsubscribe page. The email provider then forwards that unsubscribe request (and any others received for the same email sender) to the email sender in a list. This is known as a list-unsubscribe. If the email provider sends this list-unsubscribe request to Marketo during the maintenance downtime, it will not be able to connect and the unsubscribe request will not be recorded in your instance. Marketo has performed extensive research and testing on this functionality to identify ways to mitigate this risk. List-unsubscribe retries: Most email providers will retry a list-unsubscribe request if the first attempt fails. This helps ensure that, even if the list-unsubscribe is unsuccessful during the maintenance window, it will be retried later. Removal of list-unsubscribe feature: While the list-unsubscribe functionality is added by the email provider, Marketo can control whether or not that functionality is applied. By changing a back-end configuration, Marketo can prevent email providers from supplying their unsubscribe link. By removing this option, it forces people to use the unsubscribe link provided in the email footer. Since the unsubscribe link will take the person to an error page, they will know that there was a technical issue preventing a successful unsubscribe request and will know that they will need to re-attempt to unsubscribe later. This should prevent a situation where a person thinks they have unsubscribed but have not been recorded as so. The list-unsubscribe feature was removed on April 2, 2019. This will remove the list-unsubscribe functionality from all emails sent after the configuration change is made. However, it is not possible to remove the feature from emails sent prior to the configuration change on April 2, 2019. Through extensive testing and trend analysis, we have found that the likelihood of a person using the list-unsubscribe feature two or more weeks after the email is sent is extremely low (between 1.64% and 1.87%). What this means is that the chances of a person using this feature to unsubscribe but not actually being unsubscribed is very low. When combined with the fact that all major email providers retry list-unsubscribes if not successful on the first attempt, the risk of an unsubscribe request not processing successfully is very small. The list-unsubscribe feature will be re-enabled after the maintenance has been completed. If you have any questions, please contact Marketo Customer Support https://support.marketo.com.

Summary We have identified an issue that occurred during a recent update released on October 26, 2018. This update inadvertently created a condition where landing pages might lose page elements after being re-approved. Free-form landing pages that contain dynamic content may also have missing elements. Frequently Asked Questions Who is affected? This update affected a subset of landing pages across multiple customers that developed their landing pages with the Free-Form Landing Page editor. Landing pages that have been developed using the Guided Landing Page editor are not affected. How does this affect me? Customers need to ensure their live landing pages are not missing any content. This issue is most likely to affect free-form landing pages with dynamic content, and landing pages that have been re-approved since October 26, 2018. However, please keep in mind that it is possible this issue affected other landing pages as well. Which landing pages should I focus on? First, you will want to focus on your landing pages with dynamic content. Landing pages with dynamic content can be reviewed using the Preview Page functionality as shown in the documentation here. Review by each Segment to ensure all content is present in each version of the page. If you notice missing content on the live version of the landing page with dynamic content, you will need to re-add that content to the page in the Landing Page Editor and re-approve the landing page. Second, you will want to look at commonly used and high value landing pages. Open these in Marketo’s editor to check if content is missing and re-add it if necessary. What content is missing? This issue only affects Rich Text Elements. Landing pages have multiple different types of elements (forms, images, snippets, etc.). The only type of landing page element that are impacted Rich Text Elements. Here’s what to look for: Landing Page Elements Impacted – Rich Text Elements Landing Page Elements Not Impacted – All Other Element Types What if I am unsure that any content is missing? Unfortunately, there aren’t many ways to see exactly what content is missing from affected pages. You should be able to see the correct version of landing pages without dynamic content by visiting the live version. If you cannot reach the live version of the landing page, you can try using The Way Back Machine at http://web.archive.org to see older cached versions of the page. While this is a third-party resource not operated by Marketo, it may be helpful in identifying what content was previously on the landing page. Are all my landing pages affected? It is highly unlikely that every landing page is impacted. However, every free-form landing page has the possibility to be impacted. It is recommended to check your active landing pages as well as the pages that have dynamic content to ensure they display as intended. You can utilize a Landing Page Performance Report to see which Landing Pages are active and which ones have the highest traffic so that you can prioritize those first. Free-form landing pages are the only ones affected by this issue. Guided landing pages are not affected at all. Will cloned landing pages be affected? Landing pages that are cloned from an affected landing page after October 26th could also be impacted. You should validate these cloned pages as well. Why doesn’t Marketo rollback the update that caused this issue? We first learned about this issue after other changes occurred to the code base. Unfortunately, we are unable to selectively roll back updates due to unforeseen changes that may occur. Additionally, many customers have made additional changes since this first occurred and there’s no way to identify which version should be restored. Can Marketo Support fix the issue? Marketo Support is not able to determine what content might be missing. Ultimately, you will need to determine if any elements are missing from your landing pages. Landing Page Verification Utility Overview Marketo recognizes that correction of this issue will take investigation. To help you identify pages that could have been impacted, we have built a new Landing Page Verification utility as a resource for you. The Landing Page Verification utility is a new back end utility that was developed specifically for this purpose. Since it is a back-end utility, it is not polished the way that products are inside the Marketo UI. However, it will identify all landing pages in your Marketo instance that could have been impacted by this service issue. Using the Landing Page Verification Utility This resource will allow you to generate a list of potentially affected landing pages, which will then need to be checked. Please note that landing pages not on this list may also be affected. Navigating to the Utility Since this utility is not built into the Marketo UI, access to it is different than accessing any other feature within Marketo. To access the Landing Page Verification utility, you must manually change the URL from within your Marketo instance. Here are the steps for navigating to it: 1. Navigate to your My Marketo page and take note of the URL in the address bar. In the example here, the URL is https://app-xxxx.marketo.com/#MM0A1 NOTE: In your own instance, the “xxxx” will be replaced by a different 4 digits such as ab07 or sj19 as examples. 2. Change the last section of the URL from #MM0A1 to supportTools/landingPageVerification and hit enter. The URL will change From: https://app-xxxx.marketo.com/#MM0A1 To: https://app-xxx.marketo.com/supportTools/landingPageVerification Reading the Results The first screen that the Landing Page Verification utility opens shows you whether you have pages impacted, and if so, how many. Zero Results Returned If the Landing Page Verification utility is unable to find any pages that are likely to be affected, you will see the page below indicating that no pages were impacted. Pages Impacted If the Landing Page Verification utility identifies pages that have been impacted, it will show how many pages there were. To view the full list of landing pages, check the box and click the Submit button. You’ll see a page like the one below that lists all pages that may be affected. Prioritizing Landing Pages While it’s best to assume that all landing pages in the list need to be checked, it’s possible that some were not affected. If there are many pages listed, it will be helpful to know which ones to prioritize to be checked first. Some landing pages are more likely to have been affected. Here are some things to consider when evaluating which pages should be checked first. Landing pages that have dynamic content are the most likely to be impacted and should be checked first Landing pages that have been edited after October 26, 2018 are likely to be impacted Landing Pages that are archived are not visible to your customers and probably don’t need to be checked Checking Your Pages The pages displayed in the Landing Page Verification utility are hyperlinked so that you can click through to those landing pages directly. When you get to the landing page in Marketo, you’ll need to check the live page to see if there are elements missing. The URL for the live page will be found at the bottom, along with a button to navigate directly to the approved page. Due to the nature of the issue, you may find some landing pages where the Landing Page Editor is missing some elements that still appear in the live page. This sometimes occurs when the live pages are cached versions of the landing page. By comparing these to the versions in the Landing Page Editor, you can use these cached versions to help identify which elements of the page need to be recreated. Recreating Landing Page Elements All missing landing page elements must be recreated. Once recreated, approve your landing page and verify that the live landing page has the correct elements in it. Where to Get Help Marketo’s Customer Support is ready to assist. Please contact us at https://support.marketo.com or through any of the methods listed here.

This document provides an overview of the recent service issue that impacted customers in our Ashburn data center on June 4, 2019. If you are unsure if your instance was impacted, please Contact Marketo Support at support.marketo.com. When: June 4, 2019 Impact to interactive logins: 12:33 PM PDT - 2:30 PM PDT Impact to remaining services listed below: 12:33 PM PDT - 5:45 PM PDT Duration: 5 hours, 12 minutes Service affected: Interactive logins may have been intermittently disrupted between 12:33 PM PDT and 2:30 PM PDT. The services listed below may have been intermittently, or completely impacted for the duration of the issue, 12:33 PM PDT - 5:45 PM PDT. The Marketo Sky user interface inaccessible REST API may have returned error messages of 611. A full list of REST API error messages can be found here. For a subset of customers, activities that occurred during the impacted timeframe may not have been fully indexed. This could cause smart lists to show inaccurate data, which may cause campaigns to qualify, or not qualify, records inaccurately. Some triggers were not evaluated even if a lead qualified for a trigger campaign. Batch and trigger campaigns could have failed. Any campaign failures should be visible in your instance's notifications center. Documentation on how to find these notifications can be found here. List imports were put in queue for a small subset of customers. These queued up list imports had to be canceled and will need to be re-imported. To identify lists that failed to import, right-click on the list from the navigation tree and select "Show Import Status". This will bring up the import status dialog box. Bulk exports (leads and activities) were put in queue due to this incident. Our team resolved this on June 5, 2019, allowing most exports to complete at that time. There is a possibility that the export failed for some customers. In this case, exports would have to be re-attempted. Intermittent bandaid errors may have appeared in the Marketo user interface. Email tracking links may not have been able to be resolved. This would have resulted in: Landing pages being inaccessible when clicking a tracked link. "Click link in email" activities not persisting. Account Based Marketing (ABM) may have returned stale data. Real-Time Personalization (RTP) and Search Engine Optimization (SEO) tiles in the Marketo user interface may have been inaccessible. Facebook and LinkedIn LeadGen may have been inaccessible. Some web / Munchkin activities may not have been recorded. While these services were impacted, the serving of forms and landing pages and SOAP API continued to function as normal. What happened: The source of the disruption has been identified as an IP address conflict issue. On June 4, 2019, a new network hardware device was initialized that inaccurately acquired an IP address that was already in use by the load balancer, another network hardware device. This network address conflict caused the load balancer to be intermittently unavailable, stopping network traffic. This could have caused network requests for internal services such as Locator Service, Metadata Service, and Activity Service to time out, resulting in the affected Marketo services to be intermittently or completely impacted. Due to the complex nature of the issue, it took longer than normal to identify the source of the problem. While we were able to identify the network address generating errors, each time the new device was reinitialized, the errors would appear and disappear, causing the intermittent symptoms. Remediation: Once the issue was identified, our team took immediate action to resolve the issue. To restore interactive logins, our team implemented a workaround to bypass the impacted load balancer device. Additionally, we began to migrate the remaining impacted services to an alternative load balancer. During this secondary process, we discovered the IP address conflict issue. Once we identified the definitive root cause, we disabled the network devices and full service was immediately restored. To correct the activity data that was not fully indexed during the impacted timeframe, our team has developed and begun the process to correct the data. Please note that activities that occurred outside of the impacted timeframe were not affected. Due to the large volume of activities, we expect this process to take up to 30 days to complete, with an anticipated end date of July 8, 2019. Facebook and LinkedIn LeadGen data may not have been recorded in Marketo during the impacted timeframe. To correct this, our team completed a data fix process on June 12, 2019, to replay these requests and ensure no data was lost. There is a chance that a small number of Munchkin activities that were affected during the impacted timeframe did not get recorded. Our team cannot reprocess these activities as this would cause duplicate events for other activities that did get recorded. We will continue to update this article including data fix timelines and processes as soon as such information is available. Please check this article frequently for updates. For additional questions, please Contact Marketo Support 

This document provides an overview of the recent lead Change Score issue that impacted a subset of customers across our data centers beginning on June 11, 2019. All customers that were impacted were emailed details of the incident on June 20, 2019. If you are unsure if your instance was impacted, please reach out to Marketo support at support.marketo.com.   Impacted Timeframe by Data Center: London data center, June 11, 2019, 4:00 PM PDT - 5:00 PM PDT Sydney data center, June 14, 2019, 3:30 PM PDT - 4:00 PM PDT San Jose & Ashburn data centers, June 14, 2019, 6:30 PM PDT - 7:00 PM PDT   How to identify what data center your instance is located in: You can deduce the server locations by looking at the URL of your instance. The CNAME=the pod or server your instance is on. The example above indicates that this instance is in our Ashburn data center.   The abbreviations for all our data centers are as follows. lon = London sn = Sydney sj = San Jose ab = Ashburn   Service affected: A subset of Marketo customers may have experienced lead score changes that were not being updated. Impacted customers would have received campaign failure notifications in their Marketo subscription. Change Score flow steps that were set to update lead scores would not have been triggered during the impacted time-frame, however, no other flow steps were affected and the remainder of the campaign would have executed as expected.   What happened: This issue originated from an internal logic error during a recent release. This error caused a delay between the database schema update and the code release, resulting in lead score change triggers to be missed.   Remediation: Once the cause was identified, our team immediately began to identify the root cause and potential fixes. Our team created this documentation to educate customers on how to replay the impacted flow steps to update the lead score as needed.    Campaigns that were not triggered during the impacted timeframe will not be automatically replayed. However, customers can create their own smart campaign to update the lead scores as shown below.   Replay Impacted Smart Campaign: 1. Navigate to the Notification center in your instance. 2. Once in the Notification center, look for any campaign failures during the timeframe that the data center your instance is in was impacted as listed above. 3. If the failed campaign contains score changes, then only the Change Score flow steps failed. Every other flow step in that campaign would have worked correctly. You will need to re-run the Change Score flow steps for the leads listed in the campaign failure notification. If you experience any issues with replaying the impacted smart campaigns, please contact Marketo support at support.marketo.com, or through any of the methods listed here.