I am lucky enough to work for a company that surrounds me with incredibly talented people. And in the short time I’ve been here, I have already learned so much from my teammate Jamie Carey. Jamie has inspired me to begin a new series: Interview with the Marketo Admin. I want to know what goes on in the Marketo world, and how it affects my Salesforce world, and vice versa, and… you get the idea. Like Interview with the Vampire… but a little less dangerous.

Our first collaborative blog post is on the subject of field considerations. As Salesforce admins, one of the first things we learn is how to create custom fields. But with integrated marketing apps, there are many facets of field creation that we never even think about – so here is some of the wisdom that Jamie has passed on to me, to share with the rest of the AwesomeAdmin community!

Field creation / visibility – a.k.a. Don’t clutter Marketo!

JC: Every field created in Salesforce on the Lead, Contact, or Account objects will be created in Marketo if it is visible to the Marketo sync user. You can control the number of fields in Marketo via permissions for that user. There are also fields in Salesforce – listed here – that will map to Marketo by default, so keep those in mind.

CK: What about other objects? Do they get copied in Marketo if the Marketo sync user can see them?

JC: Marketo defaults to Accounts and Leads (Salesforce Leads and Contacts are all called “Leads” in Marketo). You can sync other objects to Marketo, but just for the purpose of utilizing them in Smart Lists – Marketo will not copy them as records (like it does with Accounts and Leads).

CK: What happens with field visibility when you sync Marketo with Salesforce for the first time?

JC: During the initial setup, you create a Marketo sync user. It’s a good idea to create a completely separate profile in order to give the sync user access to only the fields that you want them to “see” on Leads, Contacts, and Accounts. If the sync user can’t see the field, it will not become a field in Marketo.

My takeaway: Be mindful of the clutter you are creating in Marketo! Whenever you create a new field on the Lead, Contact, or Account object, hide it from the profile for your sync user unless it is a field that you are sure Marketing will want to use. You can always provide visibility later – but you can’t take it away once it is given.

Read vs. Edit Access for Marketo sync:

JC: You may have certain fields that should only be edited within Salesforce, but that you want visible in Marketo – so make sure to evaluate which fields you want Marketo to write to versus read-only.

CK: What happens to the data if a field to which Marketo has read-only access is on a web form, and a lead fills out the form with different data?

JC: Salesforce always wins. Marketo will still sync, but the values in Marketo will be overwritten by the Salesforce values on any field that Marketo cannot edit. In addition – by default, Marketo will never write to an Account field if there’s already a value in it (the logic being, you would not want a person who fills out a form to be able to change account-level information). However, you can ask Marketo Support to change this for you if you have a business use case for it.

My takeaway: Be very intentional when allowing Marketo to write field values. Think about every potential scenario when determining read only vs. read/write access to fields.

Field API Names:

JC: Marketo refers to SFDC fields by their API names, not their labels. If you change the API name in Salesforce, Marketo will create another field with the new API name, and start storing the data there.

CK: What happens to the old field, with the original API name?

JC: It stays there, and it still contains the data that was in the field up until the point that the API name was changed.

CK: Can’t you just delete it?

JC: Marketo does not allow deletion of fields like Salesforce does. You can put in a request to have them merge the duplicate fields, but it’s a bit of a process.

My takeaway: Just because you can change a field’s API name doesn’t mean you should. You will not see an error message upon trying to change an API name unless that field is referenced in Apex code. But it can affect your integrated apps – in this instance, by creating more clutter. With other integrations, it can completely break the sync on the field. Once a field has been created, it’s a good idea to leave its API name alone.

Invisible reference fields:

JC: Fields can exist in Marketo that do not exist in Salesforce, and still be used to update Salesforce records.

CK: How does that work?

JC: Through a flow step called “change data value” in which you can reference a Marketo field (not in Salesforce) and use that field’s data to populate another field (that is in Salesforce) with a token.

My takeaway: If you are thinking about creating a Lead field in Salesforce that would only exist for the purpose of populating another field, this is a good alternative. It works like a reference in Process Builder – the field could just exist on a web form and in Marketo, and its values can be used to update your Salesforce records!

A couple of other things I learned about Marketo fields from my interview with Jamie:

• Marketo does not have field history tracking – so make sure that you are tracking your most important fields on your Salesforce objects and in Chatter feed tracking, because you will not be able to jump into Marketo and view field history.
• Although you can sync formula fields from Salesforce to Marketo, they will not be updated in Marketo unless the record has been edited – because the Marketo sync is looking for the “Last Modified” update.

These are just a few of the field considerations that really stood out to me – additional documentation can be found here.

Not a Marketo customer? I’m not going to say something silly like “all marketing automation tools are the same” – but these are great considerations for anything that syncs with your fields in Salesforce.