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:
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.