Limitations and Considerations re: Custom Object Data

[Angus_McCann1]

My company has multiple different Brands (A, B, C) with different platforms (1,2,3, etc.)

In our Marketo instance, we use Custom Objects to store information, like profile info, from other systems. Each profile gets its own object. So if I have a profile on Brand A, platform 1 and 2, Brand B platform 3, and Brand C platform 4, I’ll have 4 custom objects on my contact record.

We keep all this information stored inside a Master Data Record outside Marketo, and each time we add a new platform, a new “row” gets added for each platform and a whole new mapping needs to be created.

However, our data team suggested that we create an agnostic “Profile Data” object, where the brand and platforms are fields. This way, each time we add a new platform to the Master Data Record, they will just be pushed into our Marketo Instance without having to do extra mapping, scope work with development, etc.

My concerns are this: we have plenty of fields that overlap platforms – first name, last name, email, etc – but we also have plenty that are unique to that individual platform:

• Is there a limit to the number of fields we can put into a Custom Object?
• Does it become too un-wieldy on the system to have too many fields in a Custom Object?
• What does this mean for the number of API calls?
• What about velocity scripting? We are currently starting to lean more heavily on velocity to pull information from objects to populate into emails, does this make it a never-ending cascade of conditional logic that will break the script?

[SanfordWhiteman · Accepted solution]

Is there a limit to the number of fields we can put into a Custom Object?

---

Yes, 40 fields in most instances. (Some people pay for more, but that isn't always offered.)

Does it become too un-wieldy on the system to have too many fields in a Custom Object?

Not within the standard limit, I wouldn't worry about that. And it's about whether the model fits your business (see below).

What does this mean for the number of API calls?

---

In theory you could be using fewer API calls if you had one generic object, since you only have to update a single object (same endpoint). However, not knowing your API usage pattern now, can't know if that matters.

What about velocity scripting? We are currently starting to lean more heavily on velocity to pull information from objects to populate into emails, does this make it a never-ending cascade of conditional logic that will break the script?

---

You don't need to have more than one condition if there's one field that dictates the "sub-type" of the object. 

The underlying question, and you are right to wonder about it, is Are you dumbing down your business model too much by using one object?  This isn't really something we can know from the outside. IMO if your back end database, and your company's object-oriented code, treats the brands as specific objects types/classes/tables, then you should honor that decision and continue it in Marketo. 

[Angus_McCann1]

So my only follow-up is more than I'm looking for feedback from people who have tried this and said "We hated this because..." although I realize this might not be the most common use-case for people and we might have to do trial by fire.

Thanks, Sanford!