Knowledgebase

  Syntax Recommendations Common Look Up mechanisms Common Modifiers Too Many Mechanisms Character String Too Long Null Records in the SPF Record Repetitive Records in the SPF Record - Void Lookups Validation Tools Syntax Recommendations Common Look Up mechanisms a: mx: include: ip4: ip6: exists: ptr: all Common Modifiers redirect= exp=   An A Record must ALWAYS contain IP address (map host to IP) CNAME (Alias) must contain hostnames. No IPs here NS an MX records must contain host names. No IPs allowed. MX records (for mail servers)  should contain hostnames NOT IPs. Too Many Mechanisms Section 10.1, "Processing Limits" of the SPF RFC 4408 specifies the following in regards to DNS lookups: SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier.  If this number is exceeded during a check, a PermError MUST be returned.  The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do count against this limit.  The "all", "ip4", and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit. The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated. This limit is in place to prevent SPF lookups from being a useful avenue for Denial of Service attacks. Using an example SPF record as an example to illustrate, this record was breaking with 12 look-ups: example.com text = "v=spf1 include:_spf-a.example.com include:_spf-b.example.com include:_spf-c.example.com include:_spf-ssg-a.example.com include:spf-a.anotherexample.com ip4:131.107.115.215 ip4:131.107.115.214 ip4:205.248.106.64 ip4:205.248.106.30 ip4:205.248.106.32 ~all" [ 5 mechanisms] _spf-a.example.com  text = "v=spf1 ip4:216.99.5.67 ip4:216.99.5.68 ip4:202.177.148.100 ip4:203.122.32.250 ip4:202.177.148.110 ip4:213.199.128.139 ip4:213.199.128.145 ip4:207.46.50.72 ip4:207.46.50.82 a:mh.example.m0.net ~all"  [ +1 = 6 mechanisms] mh.example.m0.net a = 209.11.164.116 _spf-b.example.com text = "v=spf1 include:spf.messaging.example.com ip4:207.46.22.35 ip4:207.46.22.98 ip4:207.46.22.101 ip4:131.107.1.27 ip4:131.107.1.17 ip4:131.107.65.22 ip4:131.107.65.131 ip4:131.107.1.101 ip4:131.107.1.102 ip4:217.77.141.52 ip4:217.77.141.59 ~all" [+1 = 7 mechanisms] spf.messaging.example.com text = "v=spf1 include:spfa.anotherexample.com include:spfb.anotherexaple.com include:spfc.anotherexample.com -all"  [+3 = 10 mechanisms] spfa.anotherexample.com  text = "v=spf1 ip4:157.55.116.128/26 ip4:157.55.133.0/24 ip4:157.55.158.0/23 ip4:157.55.234.0/24 ip4:157.56.112.0/24 ip4:157.56.116.0/25 ip4:157.56.120.0/25 ip4:207.46.100.0/24 ip4:207.46.108.0/25 ip4:207.46.163.0/24 ip4:134.170.140.0/24 ip4:157.56.110.0/23 -all" [+0 = 10 mechanisms] spfb.anotherexample.com  text = "v=spf1 ip4:207.46.51.64/26 ip4:213.199.154.0/24 ip4:213.199.180.128/26 ip4:216.32.180.0/23 ip4:64.4.22.64/26 ip4:65.55.83.128/27 ip4:65.55.169.0/24 ip4:65.55.88.0/24 ip4:94.245.120.64/26 ip4:131.107.0.0/16 ip4:157.56.73.0/24 ip4:134.170.132.0/24 -all" [+0 = 10 mechanisms] spfc.anotherexample.com  text = "v=spf1 ip4:207.46.101.128/26 ip6:2a01:111:f400:7c00::/54 ip6:2a01:111:f400:fc00::/54 ip4:157.56.87.192/26 ip4:157.55.40.32/27 ip4:157.56.123.0/27 ip4:157.56.91.0/27 ip4:157.55.206.0/24 ip4:157.55.207.0/24 ip4:157.56.206.0/23 ip4:157.56.208.0/22 -all" [ +0 = 10 mechanisms] _spf-c.example.com  text = "v=spf1 ip4:203.32.4.25 ip4:213.199.138.181 ip4:213.199.138.191 ip4:207.46.52.71 ip4:207.46.52.79 ip4:131.107.1.18 ip4:131.107.1.19 ip4:131.107.1.20 ip4:131.107.1.48 ip4:131.107.1.56 ip4:86.61.88.25 ip4:131.107.1.44 ip4:131.107.1.37 ~all" [+0 = 10 mechanisms] _spf-ssg-a.example.com  text = "v=spf1 include:_spf-ssg-b.example.com include:_spf-ssg-c.example.com ~all"  [+2 = 12 mechanisms] _spf-ssg-b.example.com  text = "v=spf1 ip4:207.68.169.173/30 ip4:207.68.176.1/26 ip4:207.46.132.129/27 ip4:207.68.176.97/27 ip4:65.55.238.129/26 ip4:207.46.222.193/26 ip4:207.46.116.135/29 ip4:65.55.178.129/27 ip4:213.199.161.129/27 ip4:65.55.33.70/28 ~all"  [+0 = 12 mechanisms] _spf-ssg-c.example.com text = "v=spf1 ip4:65.54.121.123/29 ip4:65.55.81.53/28 ip4:65.55.234.192/26 ip4:207.46.200.0/27 ip4:65.55.52.224/27 ip4:94.245.112.10/31 ip4:94.245.112.0/27 ip4:111.221.26.0/27 ip4:207.46.50.221/26 ip4:207.46.50.224 ~all" [+0 = 12 mechanisms] spf-a.secondexample.com  text = "v=spf1 ip4:157.55.0.192/26 ip4:157.55.1.128/26 ip4:157.55.2.0/25 ip4:65.54.190.0/24 ip4:65.54.51.64/26 ip4:65.54.61.64/26 ip4:65.55.111.0/24 ip4:65.55.116.0/25 ip4:65.55.34.0/24 ip4:65.55.90.0/24 ip4:65.54.241.0/24 ip4:207.46.117.0/24 ~all" [+0 = 12 mechanisms] Character String Too Long 255 character limitation in a single string kb.isc.org/article/AA-00356/0/Can-I-have-a-TXT-or-SPF-record-longer-than-255-characters.html string-functions.com/length.aspx You may have more than 255 characters of data in a TXT or SPF record, but not more than 255 characters in a single string. If you attempt to create an SPF or TXT record with a long string (>255 characters) in it, BIND will give an error (e.g. "invalid rdata format: ran out of space".)  Strings in SPF and TXT records should be no longer than 255 characters.  However to get around this limitation, per RFC 4408 a TXT or SPF record is allowed to contain multiple strings, which should be concatenated together by the reading application.  In the case of use for SPF (using either TXT or SPF RRs) the strings are concatenated together without spaces as described below.  Reassembly by other applications of multiple strings stored in TXT records might work differently. 3.1.3. Multiple Strings in a Single DNS record As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS record (either TXT or SPF RR types) can be composed of more than one string. If a published record contains multiple strings, then the record MUST be treated as if those strings are concatenated together without adding spaces. For example: IN TXT "v=spf1 .... first" "second string..." MUST be treated as equivalent to IN TXT "v=spf1 .... firstsecond string..." SPF or TXT records containing multiple strings are useful in constructing records that would exceed the 255-byte maximum length of a string within a single TXT or SPF RR record. EXAMPLE text = "v=spf1 ip4:199.15.212.0/22 ip4:72.3.185.0/24 ip4:72.32.154.0/24 ip4:72.32.217.0/24 ip4:72.32.243.0/24 ip4:94.236.119.0/26  ip4:37.188.97.188/32 ip4:185.28.196.0/22 ~all“ text = "v=spf1 ip4:199.15.212.0/22“ " ip4:72.3.185.0/24 ip4:72.32.154.0/24 ip4:72.32.217.0/24" " ip4:72.32.243.0/24 ip4:94.236.119.0/26" " ip4:37.188.97.188/32 ip4:185.28.196.0/22 ~all" Null Records in the SPF Record A record that is NULL or that does not exist will break an SPF record.  Syntax within the record is very important, if there are extra spaces between mechanisms it will count as NULL. EXAMPLE text = "v=spf1 ip4:199.15.212.0/22“ <- accurate text = "v=spf1 ip4: 199.15.212.0/22“ <- NULL (NOTE the space between IP4: and the IP) Repetitive Records in the SPF Record - Void Lookups If there are too many repetitive mechanisms in the SPF record, including records that cascade (for example when using "include:") the record will break. There is a MAX of 2 void look ups in an SPF record.  More than that and the record will break.  This prevents SPF records from being used in Denial of Service style attacks. Validation Tools SPF checker, syntax validator and SPF tester http://www.kitterman.com/spf/validate.html SPF checker http://vamsoft.com/support/tools/spf-policy-tester SPF validator http://vamsoft.com/support/tools/spf-syntax-validator CIDR Calculator http://www.subnet-calculator.com/cidr.php Nslookup network-tools.com/nslook/ SPF creation wizard microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ Common SPF errors openspf.org/FAQ/Common_mistakes SPF syntax definitions openspf.org/SPF_Record_Syntax

Issue Issue Description When syncing records between Marketo and Dynamics, an error is received of "Marketo is unable to update the following records in Microsoft Dynamics" due to "A record was not created or updated because a duplicate of the current record already exists".   Solution Issue Resolution The reason for that error is due to custom de-duplication rules set up in Dynamics, specifically when Marketo inserts a lead record or updates lead and contact records. There are a couple ways this issue can be addressed: 1) Your team can review the custom de-dupe rules in Dynamics and open them up so Marketo can insert/update records. We recommend this step first! 2) There is a Support tool that will allow suppression of the de-duplication rules set up in Dynamics for the sync user. With this tool, the sync user will be able to insert leads for the first time or updating a lead or contact. This process isn't typically recommended as a first step because it can lead to duplicate records being created, but if you'd like the suppression enabled, please reach out to Marketo support with the details of your request. Who This Solution Applies To Dynamics Users

Issue Below are the fields in SFDC that are required by Marketo to sync an object.  Fields in () are fields additional fields that are required if you also have Sales Insight configured. Also specified are the fields that can be updated by Marketo.  The rest of the listed fields only need to be "Read-only" for the purposes of the sync. If any of these fields are not visible to the Marketo Sync user, you will see sync failures indicating that a required field is missing.  To fix this, have your SFDC admin update the permissions level for the field(s) for the sync user's profile.   Solution Lead Fields: IsConverted, ConvertedDate, ConvertedAccountId, ConvertedContactId, ConvertedOpportunityId, status, OwnerId, IsDeleted, MasterRecordId, Id, SystemModstamp, CreatedDate, Name, Email, (Company, Owner.Name) Can be updated from Marketo: status, Name (via first/middle/last name), Email.    Contact Fields: AccountId, OwnerId, IsDeleted, MasterRecordId, Id, SystemModstamp, CreatedDate, Name, Email, (Owner.Name, Account.Name) Can be updated from Marketo: Name (via first/middle/last name), Email   Account Fields: OwnerId, IsDeleted, MasterRecordId, Id, SystemModstamp, CreatedDate, ParentId, Name Sync is one-way only by default so Marketo doesn't make changes to your account records. If two-way sync is turned on (e.g. for Person Accounts), Marketo can update Name.   User Fields: AccountId, CreatedDate, Email, Id, ManagerId, SystemModstamp, UserType Sync is one-way only by default so Marketo doesn't make changes to your user records.   Opportunity Fields: Id, IsDeleted, SystemModstamp, AccountId, CampaignId, CreatedDate, IsClosed, IsDeleted, IsPrivate, IsWon, Name, OwnerId, Probability, StageName, SystemModstamp, (LastModifiedDate) Sync is one-way only by default so Marketo doesn't make changes to your opportunities.   Opportunity Contact Role Fields: ContactId, CreatedDate, Id, IsDeleted, IsPrimary, OpportunityId, SystemModstamp Sync is one-way only by default so Marketo doesn't make changes to the contact roles for your opportunities.   Campaign Fields: Id, IsDeleted, SystemModstamp, CampaignMemberRecordTypeId, CreatedDate, IsActive, IsDeleted, Name, OwnerId, ParentId, Status, Type Sync is one-way only by default so Marketo doesn't make changes to your SFDC campaigns.   Campaign Member CampaignId, ContactId, CreatedDate, Id, IsDeleted, LeadId, Status, SystemModstamp Can be updated from Marketo: Status   Campaign Member Status Fields: CampaignId, CreatedDate, Id, IsDefault, IsDeleted, SystemModstamp   Tasks Fields: Status, SystemModstamp, IsDeleted, CreatedDate, WhoId, OwnerId, WhatId, AccountId, IsClosed, IsArchived, IsReminderSet, RecurrenceActivityId, IsRecurrence, Id, SystemModstamp, Subject   Event Fields: CreatedDate, Id, IsDeleted, OwnerId, Subject, SystemModstamp, WhoId     Who This Solution Applies To All instances with a native SFDC integration.

  What is the Email API? What is the Email API used for? What is Email 2.0? Does the Email API Work on Email 2.0 Assets? Will the Email API Break when Enabling Email Experience 2.0? How Are 1.0 Assets Upgraded to 2.0 Assets? What to Do When an Email Was Accidentally Converted to Email 2.0 format?     What is the Email API? API stands for Application Programming Interface and the Email API allows an automated process to create and edit emails in Marketo. There are also other API calls that involve emails, such as Approve Snippet (assuming the Snippet is used in an Email) and Clone Program (assuming the Program contains Emails). There are also API calls to create and update Email Templates. Essentially, the API can do many things that you can also do through the Marketo user interface, but then in an automated fashion.     What is the Email API used for? There are many scenarios: an external system could create Emails in Marketo using data that lives outside of Marketo. A translation service provider could clone a master Email, translate it to many languages, then save them back into Marketo as localized Emails. A reporting system could extract Emails from Marketo to use in reports that are generated outside of Marketo. An external system could Clone a Program that contains Emails, then populate the Program Tokens and schedule the Email to be sent out at a specific time. There could be an external email template creation system that creates new Email templates in Marketo through the API.     What is Email 2.0? “Email Experience 2.0” is the new Marketo product feature with the enhanced email editor, documented here: docs.marketo.com/display/public/DOCS/Email+Editor+v2.0+Overview. It can be switched on in Admin > Email > Edit Email Editor Settings. All Emails and Email Templates also have a version number, either 1.0 (the old version) or 2.0 (the new version). If we refer to “Email 2.0 asset” we mean an email or email template in the new upgraded 2.0 format.     Does the Email API Work on Email 2.0 Assets? Yes.     Will the Email API Break when Enabling Email Experience 2.0? No. Enabling Email 2.0 will not automatically upgrade Emails or Email Templates to the new 2.0 format. The Email API can still create new Emails and Email Templates in the 1.0 format.  However – after enabling Email 2.0 – any Email or Email Template that is created or edited and approved through the Marketo User Interface will automatically be upgraded to the 2.0 format.     How Are 1.0 Assets Upgraded to 2.0 Assets? If you edit an “Approved" or “Approved with Draft” 1.0 Email with Email 2.0 enabled, the draft is converted to the 2.0 format. You can still discard the draft to go back to the approved 1.0 format. Once you approve the email and it becomes 2.0, the Email cannot be converted back to 1.0. If you edit a “Draft” 1.0 Email (never been approved), this will automatically be converted to 2.0 with no option to revert back to the 1.0 format. The same applies to Email Templates.     What to Do When an Email Was Accidentally Converted to Email 2.0 format? If an Email or Email Template was accidentally converted to the 2.0 format, you’d have to copy the asset contents to a text editor, disable Email 2.0, then create a new 1.0 asset using the content that you copied.

Issue There are two filters available (Acquisition Program and Acquisition Program Name), but only Acquisition Program Name appears in the lead record and is available as a column in the lead views.  What is the difference between these? Solution Acquisition Program is a system-managed field. It isn't available in many picklists, nor in certain filters. Acquisition Program Name is a field that allows you to use this data more freely as it is not locked by the system. Acquisition Program = Master naming for programs Acquisition Program Name = Friendly usable name    

Included in this article Overview The configuration changes between Marketo and Salesforce will stop the sync to the 16 affected fields. If you recreate those fields in SFDC, the backfill process will update those newly created fields with the current values housed in Marketo. With these existing values being backfilled into the newly recreated fields, Salesforce will see it as a regular data value change, which can cause other actions to occur from things like Apex Triggers, Workflows and 3 rd Party Apps from the AppExchange. While the backfill process is still running, you could also see inaccurate data in SFDC reports. This doc will show you what to look for and how to prevent issues they could cause. Effects Inside of Salesforce Marketo is entering the existing field values into the newly recreated fields inside of SFDC. While Marketo views this as just “catching up” the values between Marketo and SFDC, Salesforce will view it differently. As soon as the new fields are recreated in SFDC, the Marketo fields are remapped to those new fields. The backfill process begins and the sync is cut off to the older existing fields, so they immediately stop updating. This results in two important things to be aware of: Everything in SFDC referencing the older original fields will be referencing old data that is no longer updating. The backfilled values entered into the newly recreated fields will be seen by SFDC as brand new values, not the existing values that they are in Marketo. Visibility Rules SFDC has the ability to restrict access to Leads and Contacts for specific users and roles. Some customers will use this ability to restrict the Marketo Sync User from being able to access certain groups of Leads and Contacts in order to keep them from being able to sync to Marketo. Restricting visibility to Leads and Contacts prevents the backfill The backfill process uses the Marketo sync user ID to connect with SFDC. If the SFDC sync user has no visibility to a group of Leads and Contacts, there is no way for the backfill process to update those leads. Resolution Evaluate your business need first. If you need to keep these Leads and Contacts from syncing with Marketo even when considering this configuration change, don't open up the visibility to them for the sync user. Neither the backfill process or normal sync cycle will see them and no data will be synced with those leads. If you want all fields to be updated for these Leads and Contacts, allow the sync user visibility to access them before creating the new fields and starting the backfill process. That will allow the backfill to run and push the Marketo field values into the newly recreated fields in SFDC. You can still remove visibility to the Leads and Contacts later if you want. If you have already recreated the new fields in SFDC and initiated the backfill process without allowing visibility to the Leads and Contacts for the sync user, the data is not lost. If you decide to allow the sync user access to the Leads and Contacts later on, then any resync of the record will also update these affected fields. Areas Affected Anything in your SFDC instance that references these fields will be affected. For most customers, this won’t be anything to worry about, but for some, it can be a much bigger issue where actions are performed when they shouldn’t be. There are some key places where you will notice the trouble if it does happen. Workflows Salesforce Workflows allow you automate actions within SFDC and can be set to run based on any number of criteria. If your workflow rules reference the older original fields, when the sync to these fields is stopped, these workflows will be based off of field values that are not updating any more. If your workflow rules have already been updated to be based on the new fields, the data value change to the fields from the backfill process can cause the workflow to react differently than it should. Existing values already accounted for will be seen as new values and could re-trigger your workflow. More information on SFDC Workflows can be found here: Workflow Rules - developer.force.com Apex Triggers Apex Triggers let you take specific actions before or after record changes and can be used to perform a wide variety of tasks the same way that workflows can. If your apex trigger is set to trigger off of value changes in the original fields, since the sync to these fields is stopped, none of these triggers will fire. If your apex trigger is triggering off of the newly recreated fields, the data value change to the fields from the backfill process can cause the apex trigger to fire when it shouldn’t since existing values will appear to be new values. More information on Apex Triggers can be found here: Salesforce Developers - Triggers AppExchange Apps If your AppExchange app references the older original fields, then when the data stops syncing to them, that app will be working off of out of date values. If your AppExchange app references the newly recreated fields, the entry of new values from the backfill process can initiate actions when they aren’t supposed to be performed or had already been performed previously. More information on AppExchange apps can be found here: https://appexchange.salesforce.com/ Reports Salesforce reporting can pull data from multiple locations. If your reports are referencing these affected fields, the reports could show incorrect data. If your reports reference the original fields, then when the sync to those fields is stopped, your reports will no longer display current data. If your reports pull values from the newly recreated fields, there are two variations of what you will see. First, if the backfill process is still going on, not all records will have updated yet, so the reports aren’t yet up to date (but will be soon). Second, if the backfill process has completed, then your field values in these new fields will be up to date and your reports will all be accurate, so there is no longer any issue. When the backfill process has completed, an instance notification will be posted in Marketo to let you know that it has finished. More information on Salesforce reports can be found here: Getting Started with Reports and Dashboards Unit | Salesforce Formula Fields Salesforce formula fields work the same way that Marketo's formula fields do -- they take two (or more) other fields and combine them together to derive a new third value for the formula field's own value. Since the formula field has to reference other different fields, if one of the other fields referenced is one of these affected fields, your resulting formula field value could have incorrect data. If your formula field references the original fields, then when the mapping to those fields is changed, the values your formula field is calculating from will be out of date, resulting in an out of date formula field value as well. If your formula field is referencing the newly recreated fields, then it's possible that they are pulling data from fields that haven't fully been backfilled yet. As with the other places where the fields are in use, as soon as the backfill process is completed, there is no more issue and all data will be up to date. Examples of the Behaviors and Solutions Let’s say you have something in place (a workflow, apex trigger or AppExchange package) that will assign leads to specific sales reps when a lead’s score reaches a threshold of 35. Scenario 1: Not changed yet to reference the newly recreated fields, but backfill process is running. Lead records could reach a lead score of 35 while the backfill is still in process, but since the mapping of the Marketo lead score field has already been switched to the newly recreated field, that data value change activity won’t be recorded against the original existing field. Therefore, your process to assign the lead reaching a score of 35 would not be initiated. Solution: Take note of when you first recreated your fields in SFDC and kicked off the backfill process. Then take note of when the backfill process completes (you’ll get an instance notification in Marketo when it finishes). Set your workflow to compare the values between the old lead score field and the newly recreated lead score field to identify leads whose scores are different between the two fields (so you’ll find the ones who had a score change during the backfill process that wasn’t seen) and also search for leads whose score in the newly created lead score field is over 35. This will identify all leads who had a score change during the backfill process and hit the threshold but weren’t seen. Then have the workflow assign the leads to your sales rep. Scenario 2: After having changed to reference the newly recreated fields. The values being backfilled into the new fields will be seen as new values. So if a lead already has a score of 40 (already met the threshold of 35 sometime in the past), that existing score of 40 will be misinterpreted as a lead reaching the lead score threshold for the first time, resulting in the lead being reassigned in error. Solution: Create a workflow that compares the value in the original lead score field to the value in the newly recreated lead score field. If the scores are equal, then you know the lead had already hit the threshold in the past and this new time was in error, so your workflow can undo the action taken before. If the scores are different and the score in the newly recreated field is over 35, then you know the lead hit the threshold for the first time and was a valid candidate for the change in lead owner. Reporting Changes: The backfill process pushes data at the rate of 10,000 records per hour. Take the number of know leads in your database and divide it by 10,000 to get the approximate number of hours the backfill will take. This is the length of time when your reports could be off. Reporting from the original fields will only have data that is current up to the time when the fields were recreated and the mapping was changed over to those new fields. Reporting from the newly recreated fields won’t give a complete picture until the backfill process is completed. Solution: Run your reports from within Marketo while the backfill process is still running. There will be no discrepancies from any data within Marketo and Marketo is the source for all of this data anyway. Report Subscriptions can be set up to send the info to anyone who needs it. Preventing These Issues There are a couple of ways to approach this. The quickest way to avoid the issue is to not update workflows, apex triggers or AppExchange apps to point to the newly recreated fields until after the backfill process is complete. Also keep in mind that your formula fields could be getting used within these other places as well. This solution may or may not work for your company and your situation. You'll need to take a close look at your processes to see whether this solution works for you. After setting them to reference the newly recreated fields, disable or turn off the workflows, apex triggers and AppExchange apps so they can’t take any action. If you have formula fields using these new fields, you can also evaluate where your formula fields are used to check what needs to be updated or switched off that uses those. Then, when the backfill process is completed, re-enable them to turn them back on again. As with the previous solution, you'll need to take a close look at your processes to see whether this solution works for you. API Access All editions of Salesforce require API access for any integration to work. Professional Edition API calls were previously included as part of the integration while Enterprise and Unlimited editions required API access purchased by the customer from Salesforce. As part of this configuration change, Professional edition customers will now be required to purchase API access from Salesforce in order to continue syncing between Marketo and Salesforce. This includes the newly recreated fields as well as the rest of the integration. Salesforce Professional Edition Salesforce Professional Edition will require API access to be purchased from Salesforce to continue syncing after January 31st. This includes all components of the Marketo > Salesforce sync. MSI utilizes API calls to communicate with Marketo, so even if you are only using MSI, it will still require API access with Salesforce. Salesforce Enterprise & Unlimited Editions Enterprise and Unlimited Editions of Salesforce have already required API access to be purchased. The requirement to get API access will not have any new impact for Enterprise and Unlimited Editions of Salesforce. Where to Go for More Information Recap Summary Now that the changes have been completed, and the deprecation date has passed, this doc will give you the overview of what has happened: Changes to Marketo Salesforce Sync - Recap Summary Frequently Asked Questions Check out our FAQ for the answers to the most commonly asked questions. Changes to Marketo Salesforce Sync – Frequently Asked Questions​ Discussion thread We've created this discussion thread in the community to address any questions you may have. This discussion thread will be monitored by the Marketo team to ensure you get answers to your questions. Changes to Marketo Salesforce Sync – Questions and Discussion Release Schedule The release is being staggered over the course of 6 months. This doc will give you exact details so you can know precisely when your Marketo instance will be updated. Changes to Marketo Salesforce Sync – Release Schedule Under the Hood Documentation This doc will give you all of the nitty gritty details of exactly what is happening. If you're looking for in depth technical details, this is the go-to doc to check out! Changes to Marketo Salesforce Sync – Under The Hood Recreating Affected Fields There are different versions of Salesforce, but don't worry, all of the details on how to recreate the affected fields as well as a video tutorial can all be found in the documentation here: Adding Marketo Fields to Salesforce Contact Marketo Support If you would prefer to talk to someone live, please contact Marketo Support over any of the channel listed here: Contact Marketo Support

Issue Description A lead fails to sync to Salesforce with the following error: Failed: FIELD_INTEGRITY_EXCEPTION: There's a problem with this country, even though it may appear correct. Please select a country/territory from the list of valid countries. This error may also occur for state as well as country fields. Issue Resolution Country/State pick-list is enabled on your SFDC instance. As a consequence, SFDC will reject any record with country/state value does not belong to the list and therefore, you will have to make sure that countries are set correctly everywhere in Marketo, and especially: in forms in data management campaigns in imports For example, if you try to feed "New York", it will not be accepted. It will only accept "NY". The error messages you're seeing are coming from Salesforce because the State fields have been standardized to only accept certain pick-list values. In order to get these records to sync with Salesforce you'll need to update them to have valid values. Contact your SFDC Admin to get the list of accepted values for that field and update the record in Marketo with the appropriate value that is accepted by SFDC. If you feel like pick list is not necessary on SFDC, you could just disable the state or country pick lists in SFDC by following the below document https://help.salesforce.com/articleView?id=admin_state_country_picklist_enable.htm&type=5 Who This Solution Applies To Customers who use SFDC as their CRM

Issue You see email clicks in a lead's activity history but no corresponding web page visits to the Munchkin-tracked page. The clicks happen immediately upon delivery of the email, or sometimes even before the delivery is logged. Solution Issue Resolution This is usually caused by email security software on the receiving email server. The security software tests the links to make sure they are not malicious and this causes Marketo to log a click activity for the email. Because the security software does not actually open the web page in the browser, there is no web page visit logged.   Your emails are more likely to be link tested if your sender reputation is low. For more information on link testing, see the following documents. Understanding a Spike in Click Activity Cracking the Inbox Code: Barracuda    

When a customer triggers a blacklisting on Marketo's shared IP range that customer is moved to a set of IPs we call the quarantined IP range.  We do this to protect the health of our shared network and ensure the best deliverability possible for all of our customers on that network.   If you have received a Blocklist Notification from Marketo reporting that you have triggered a blocklisting your Marketo account is now in the quarantined IP range.   While you are in the quarantined range it is possible that you may experience a slight decrease in your deliverability rates. The reason for this is that you are now sending from a range made up of senders that have also caused other blocklist issues. All customers have received a notice of the listing and are in the process of repairing their database.   There are two ways to be removed from the quarantined IP range: Follow the steps outlined in our Blocklist Remediation article. Be sure to fill out the form referenced in the email alert to indicate that you have taken steps to mitigate the issue. Demonstrate clean sending behavior for 3 months. We remove senders from the quarantined IP range if they have not triggered any new listings in 3 months.   To ensure your best deliverability rates blocklist issues should be addressed right away to prevent further damage to your sending reputation. Furthermore, if no action is taken to improve list hygiene the issue will likely recur. Marketo's Privacy Team strongly recommend following the Blocklist Remediation steps.   Additional Resources: Blocklist Deep Dive​  

Issue Description You have a record in Marketo that is a Contact in SFDC, and the record fails to sync with the error "INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id." Issue Resolution This error can occur if the Record Type ID field is not updated in Marketo when the SFDC Lead is converted to a Contact.  If the Record Type ID value displayed in Marketo is not valid for Contacts, the sync will fail with the error, "INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id." To resolve this, you can update the Record Type ID in Marketo with the correct value from Salesforce, or you can delete the value from Marketo and allow the sync to write the correct value from Salesforce.

  This is a article attached image Upon signing a contract with Marketo you are provisioned a Marketo instance and a Support Service. There are four different types of Support Services which are available to meet different customer support needs: Online (Legacy) Business or PREMIER SUPPORT BUSINESS (Legacy) Premier or PREMIER SUPPORT ENTERPRISE (Legacy) Elite or PREMIER SUPPORT ELITE Each Support Service has a different Service Level Target (SLT). An SLT is the amount of time Marketo Support targets to make first contact with you after a support case has been submitted. SLTs differ for each Support Service and priority level. Priority levels range from Priority P1 to Priority P4. Here are the SLTs and priority levels for each Support Service:   Priority Online (Legacy) Business PREMIER SUPPORT BUSINESS (Legacy) Premier PREMIER SUPPORT ENTERPRISE (Legacy) Elite PREMIER SUPPORT ELITE P1 1 hour 1 hour 1 hour 30 minutes 30 minutes 30 minutes 15 minutes P2 4 hours 3 hours 2 hours 2 hours 1 hour 2 hours 30 minutes P3 6 hours 5 hours 4 hours 4 hours 2 hours 2 hours 1 hour P4 3 days 1 day 1 day 1 day 1 day 1 day 1 day   Here are the descriptions for each priority level: Priority Description P1 Mission Critical: Core business function down or potential loss of mission critical data P2 Urgent: Major feature or workflow is not functioning. Mission critical workflow and majority of user community is not blocked P3 Important: Normal usability or task completion is impacted but functional, or workaround is available P4 Minor: Minor issue requiring a correction. Normal workflow is not impacted   Find more information About Support here!