1 of 1 people found this helpful
Hi Alexis Devonish,
This is correct. The Marketo fields do not change at all. Just the sf.com field that this MKTO field is mapped to will change.
Btw - independent of these changes, the original/inferred fields are system managed fields in MKTO and are not available in forms as the system populates these values vs the person filling out the form. That said, the over all point holds. You don't need to make any changes in MKTO where these fields are used (filters, triggers, tokens, column layouts on lead grids, any API's accessing the MKTO records etc).
Creating those new custom fields and mapping them is no problem. However,
- 1. should I do it based on the scheduling (we’re group C – Sep1)? What happens if I do it before?
- 2. Since we’ll create the new custom fields, what to do with the old ones? They have the same field name, so this can be confusing.
- 3. To be 100% I get this correctly – after I create the new custom fields – I can uninstall the MLM package? If so, will this solve the issue of the question #2?
- 4. What will happen if I will rename the API name of the original fields? Meaning, instead of “mkto2__Acquisition_Program__c” to “mkto71_Acquisition_Program_Id__c” assuming I will not uninstall the MLM package.
- 5. All of those fields are in the Lead object only, right?
Good questions. I'll go through each in turn, but I wanted to start by saying that it will be important to stick to the deployment schedule.
1. The release schedule has been created with the size of the lead databases of our customer base in mind. It's been split alphabetically by Account String into different numbers of customers and the determining factor for how the splits were made was total database size. For example, Group 2 is only the three letters A, B and C while Group 3 has the nine letters of D through L. However, based on the lead database sizes of the customers within those groups, Group 2 and Group 3 have approximately the same number of leads in them. The schedule has been divided this way to avoid causing traffic jams in data flowing back and forth with SFDC.
Marketo continuously makes significant strides forward in our software offerings as well our hardware serving that software, such as with Project Orion that was detailed in this year's Summit. Check out the webinar located here for a description of Orion (starts at 28min in). Even with the best software and hardware out there, data can only be pushed through an API call so fast. (Whether you use a garden hose or a fire hose, it still takes time to empty a whole water tower.) The servers have set lines of communication with SFDC and all of the customers share those lines. We've created new pipelines to be devoted just to the backfill process so that it doesn't compete with the regular SFDC sync cycle, and if everyone sticks to the schedule, we know those communication lines will keep up with the traffic. But if customers don't stick to the schedule, it throws it off. (What happens if someone parks a second water tower next to yours and asks to share your one fire hose?) That's why we ask everyone to stick to the schedule. We know this schedule may not work for everyone, so you're welcome Contact Marketo Support to request a schedule change. We'll be happy to accommodate as best we can.
2. The old fields being replaced can be deleted by uninstalling the MLM package. The details of cleaning up SFDC can be found here and here are SFDC's instructions for Uninstalling a Package. One thing to note is that if you have any reports or workflows in SFDC that reference these fields, SFDC won't let you uninstall it until those dependencies have been removed. Once data stops flowing to the old fields, they'll be obsolete, so there's no real need to keep them.
3. The old fields and the MLM package can be removed as soon as the the fields have been created. Just be sure to update your workflows and SFDC reports if you have any to connect to the new fields like noted above. All of the details can be found in our Changes to Marketo Salesforce Sync – Under The Hood documentation.
4. The fields do need to be recreated as new fields. The configuration change will shut off communication to the existing fields and new fields must be created in SFDC to replace them. Changing field names on the existing fields won't work unfortunately. You can find the info on keeping field data in SFDC in the documentation for Adding Marketo Fields to Salesforce here.
5. The fields currently exist in SFDC on the Lead and Contact objects already, and it's strongly recommended that you recreate them on both the Lead and Contact objects. It isn't required. You can do it on just the Lead object, but as it says in our FAQ doc, it's best to create them on both the Lead and Contact as well.
I hope this helps! Let me know if you have any other questions.
Once we re-create the 16 fields do we need to refresh the schema?
Hi Kassandra ,
That's a really good question. The answer is no - no need to refresh the schema at all. Part of the configuration change from the Marketo side was to create an "event listener" that monitors the sync cycle for the recreated fields. So, when you recreate the new fields, on the very next sync cycle, the sync picks up the fact that the new fields have been created and automatically maps them to the correct corresponding Marketo fields. This in turn kicks off the backfill process, but once the fields have been created, the rest from there is automatic.
Wanted to check the response to a previous question above.
What happens if we create the new fields before our backfill window starts? Will these show up in Marketo as separate, new fields?
1 of 1 people found this helpful
If you start before your window, it will work too and we will start backfilling immediately. No new fields will be created in MKTO. We batched folks up to manage the overall load. However, we are mostly seeing requests to push out the date vs pull it in.
So if you want to do it earlier, its fine. If possible, could you let support know?
1 of 1 people found this helpful
Thanks for confirming what will occur. I was actually planning on just transitioning the Lead Score field at this time and all of the other fields later. But given how you are handling the transition (and the impact in SFDC), I am just going to hold off and do all together in our transition window. (That is if I got to the SFDC team that is creating the field in time.)
Appreciate your response,
I take it I need to uninstall the App first before creating the new salesforce fields as they need to have exactly the same API names and this would cause a duplicate error if I tried to create them whilst they still exist?
UPDATED: Editing my reply here - I had a copy/paste mistake in the table. Please be sure to check the doc for exact details: Adding Marketo Fields to Salesforce
Hi Nick ,
Actually you'll want to create the new fields first. The new fields will have specific API names to use and the details can be found in the doc here: Adding Marketo Fields to Salesforce
The API names do need to be precise, so please check the doc for the specifics.
The version number won't change from what it currently shows. It isn't automatically upgrading the MSI package, it's patching the dependency for the existing installation to remove the dependency on the MLM package. So if you manually upgrade the MSI package, you'll get an entirely new version number, but the patch that went out doesn't actually upgrade the package, it just corrects that back end dependency, so the version is actually the same.
I think it may have added a ".1" at the end of the version number, but I'm not positive on that point. Arjun Nair should know more about that particular detail.
So if I understand everything correctly, I need to:
- Create the 16 new fields
- Install MSI
- Uninstall MLM
Will the new MSI package write to these new fields I just created for the future? So any reports I have pointing to those old fields can be updated to these new ones?
Is the MSI package capable of doing the backfilling or should I let the new fields sit with the old MLM package until its all synced up?
Just out of curiosity, if I were to download and do a clean install of MSI on a new server, what field would it sync Lead Score to? (I mean isn't the new package going to create a custom field for that value anyway? If the fields are different, how will my MSI know to write to mkto71_Lead_Score and not whatever field may be created by MSI during the install?)
It would be nice if we could have a clear way to know in SFDC whether the MSI package has been patched or not. And on a compliance / It procedure stand point, it would also be preferable