SOLVED

Multiple Product Interests

Go to solution
Robb_Barrett
Marketo Employee

Multiple Product Interests

Hi, I have a thread here (Self Referencing Webhook Timeout ) here I was looking for help on a solution but I'm not sure it's going to work, so I'm going to dial this back to the beginning.

I have to find a solution to store multiple product interests for a large number of products and feed that info between Marketo and Salesforce. It is too many products to create checkboxes for everything - it wouldn't be scalable nor would it store all of the information I really want to store, but as secondary and tertiary product detail levels.  Custom Objects seem to be the way to go and, for the life of me, I can' figure out why Marketo makes them so difficult to work with - only making them accessible via API which makes it quite difficult to self-update as I can with the Lead record.

Does someone have a valid example in production of multiple product interests?

Robb Barrett
1 ACCEPTED SOLUTION

Accepted Solutions
Grégoire_Miche2
Level 10

Re: Multiple Product Interests

Hi Robb,

You should know not to post questions to the Champions group if you want to get an answer

I would surely go to the static lists. Static lists are usually overlooked and I tend to more an more prefer them to adding a field for boolean info, as long as you do not need to add them to a form

-Greg

View solution in original post

3 REPLIES 3
Robb_Barrett
Marketo Employee

Re: Multiple Product Interests

Let me further refine the need.  Because we have numerous different products in which a person could have an interest, we want to create an easy way to segment in Marketo and update SFDC back and forth. There are a couple of different ways I can see this happening:

1. Create a new field for every product interest. This is the least desireable as it bloats the database. Easy to use and implement, however it will also be unwieldly in SFDC to have hundreds of checkboxes.

2. Use Custom Objects. This is the most logical, however Custom Objects are extremely difficult to use as there is no good way to update them from a form fill without making a call to an external API which can handle the necessary data movements.

3. Use static lists. This also seems like it could be an easy solution. It's easy to add and remove a person from a static list and then use a workflow to transform that into a string that can be passed back and forth to SFDC.

So, am I correct in that Static Lists are going to be the way to go, or is there another option I'm not thinking about?

Robb Barrett
Grégoire_Miche2
Level 10

Re: Multiple Product Interests

Hi Robb,

You should know not to post questions to the Champions group if you want to get an answer

I would surely go to the static lists. Static lists are usually overlooked and I tend to more an more prefer them to adding a field for boolean info, as long as you do not need to add them to a form

-Greg

Anonymous
Not applicable

Re: Multiple Product Interests

Hi Rob,

One other option is to use a delimited string value in a text field.

Based on the products owned, the string value can be 'product A | product C | Product D' or similar.

You can create product specific smart lists based on this field 'contains' criteria.

Static lists are good too. You will use smart campaigns to set these when product interest changes. In case of delimited string, you will have to use javascript code on landing page (or webhook to do the same..)

How are you thinking to transform static list membership in to a string to pass to SFDC?

Rajesh