I recently received a request from a customer who was trying to update a person's email address via the API. He was trying to use the Create and Update Lead API, and because the lead had a new email address, he was getting a duplicate person record created with the new email address. What he wanted was to update the existing Person record with the new email address instead. Since I have had this question a few times, I thought it would be helpful to write a blog post about it. The steps to follow are below, but...spoiler alert....the answer is to use the Sync Leads Using Post endpoint instead. In order to update the right Person record, I'll need the Marketo Person ID for that person. I can get that using the Get Leads By Filter Type endpoint like this: Once I have the id of the Person record, I can call the Sync Leads Using Post endpoint to update that record. As you can see from the screenshot below, I’m passing in an action of “updateOnly” and “id” for the “lookupField” value. Then I can pass the information in the “input” that I want to be updated; namely email in this case. To verify that the email address was changed, I can make the Get Leads By Filter Type call again and pass the new email address. Finally, t here are several ways to get the person id that you’ll need to do this with. You can either do a Bulk Lead Export if there are a lot of them or you can call Get Leads by Filter Type if it's a one-off, and you need to look it up by email address.
... View more
Many of our customers have complex business requirements that require more than what the baseline Marketo data model can support. That's why we have Custom Objects in Marketo. Custom Objects allow the customer to support more advanced data models in Marketo, but there are some best practices to follow when using them.
Measure Twice. Cut Once
When you first design your Custom Object, we advise to take your time and get all of the fields correctly defined before you approve the object. The reason for this is data contiguity. When you approve the custom object, Marketo creates a table in the database for that object definition.
If, at a later time, you decide that you need another one or more columns, and you simply add them and approve the object again, the additional columns will not be stored in the same table as was created in the original object definition. Going forward, you'll have data in two different tables for that object, which will require Marketo to use a join whenever it access that object. This can have an adverse effect on the speed of data retrieval from Marketo instance, impacting script execution, data access via the API, and even the user experience in the Marketo web UI.
As an alternative, you could always delete and recreate the Custom Object with the correct columns, but then you would have to migrate the data from the old Custom Object to the new one which adds a level of complexity that most of our customers don't want to get into. The best option is to get it right the first time; like woodworkers say: "Measure twice. Cut Once."
Recreating a Custom Object
Just in case you find yourself in a position to need to rebuild your Custom Object, here are the steps you'll need to follow to do it correctly:
Stop any third-party integrations that are using the Custom Object via the API.
This will prevent any third-party systems from trying to access the Custom Object via its API while you're rebuilding the object.
Remove all references to that object in filters, flow steps, smart lists etc.
This will prevent any trigger campaigns from executing based on your work.
Write down the exact spelling of the Custom Object.
So you can recreate it later
Delete the Custom Object
Depending on how many rows of data are in the Custom Object , you may have to ask support to do this.
Wait for about 15-30 minutes to allow Marketo to confirm that the Custom Object is fully deleted
This ensures you can recreate the object with the same API name.
If you just delete and recreate the object with the same API name, the recreate can fail.
Don't Use Custom Objects as a Data Land Fill
Many of our customers consider using Marketo for storage. It's better to use a data warehouse or some other third-party system.
To avoid allowing your Marketo instance to fill up over time with useless data, it's best to make sure to use your Custom Objects to store only data that is useful now, or in the future. Things you should not store in a Custom Object include:
Any data that will not be used for marketing activities
Transient information - Activity data should be stored in a Custom Activity instead
Order history - Consider purging old data from time to time
Deletion of Custom Object Data
If, after following the steps above, you still need to purge data from your Custom Objects you can do this through the API. Use the Delete Custom Objects endpoint, and remember to batch your calls in order to do up to 300 rows at a time. This will save you from using up your API rate limit. It's unfortunately not possible to mass delete all records via the API today.
... View more