Which custom object type should I use?

[Kim_Gandy1]

I'm working to import individual's product purchases.

Custom object: Purchase

Fields: Product, price, date purchased

Would this be a one-to-many or many-to-many custom object? Also, what field would be the link?

[SanfordWhiteman · Accepted solution]

Strive to avoid many-to-many (2nd-level) custom objects because they are not available from Velocity.

Unless you have a need to separately maintain Product metadata (characteristics other than purchase price, which is more a property of the purchase than of the product) then just use a 1st-level Purchase CO.

[Kim_Gandy1]

To clarify, when you say "1st-level" you mean one-to-many, correct? Thanks Sanford Whiteman​!

[SanfordWhiteman]

Yes.

[Kim_Gandy1]

Hi Sanford Whiteman​,

When importing custom object data via list, can you clarify what the Marketo Guid is and when to use it as dedupe mode? My CO import file only has product, price and date purchased. How do I need to include email address so the data is associated with a person record? Would email be the dedupe mode?

[Anonymous]

Hi Kim,

You need to link you COs to your leads, so just add "Email address" as a field, and build is as such:

Data Type: link

Link Object: Person

Link Field: Email Address

And select it as Dedupe, along with your Product ID and purchase date I would recommend.

You will need to add the email address in your import file, I hope you have that piece of information!

I would recommend waiting for Sanford's reply though, he's much more knowledgeable in this field!

[Kim_Gandy1]

Haha, I do have email addresses luckily. Just didn't know where they fit into the equation. Thanks Thomas Merlin​!

[SanfordWhiteman]

can you clarify what the Marketo Guid is and when to use it as dedupe mode?

The Marketo GUID is a guaranteed-unique identifier assigned to every custom object record.  Hence it's a foolproof way to ensure you are targeting the right record for an update. On the flipside, that means you have to store the GUID values upon original insertion, or else you won't be aware of them when you need to update.

For example, if your CO records are generated by another system (as most are), when you do an insert you also sync back the GUIDs to the other system. That way a later update to an individual CO will always be correct, since even if every single other field on the record is duplicated, the GUI can't be.