I want to know, do we have any option to know about the lists which a lead/contact is part of. How can I find in one go a lead is part of how many lists.
Thanks in advance.
You can think of list membership as primarily a property of the list, not a property of the lead.
Obviously the two are closely linked, but Marketo doesn't automatically maintain a flat field -- a "reverse lookup", if you will -- with all the lead's lists (I assume you mean Static Lists here).
You can maintain such a list via a webhook: use a Textarea field that'll hold a semicolon-delimited value, trigger the 'hook on Added to List and Removed from List, pass the current value in the payload, get back the added/pruned value.
But it's not built-in. Think hard about whether you really need this functionality before going down that road. What are you using it for? Is there another way to go about it? (Not to say such a field is not useful, as we've found the need to roll it out a few times.)
(Also, tags on the Community are set using the corresponding input box, not hashtags.)
Thanks Sanford for looking into my query.
Yes, indeed we would love to have an option to check the list details of a lead/contact. This can give us a quick visibility to know which all list the lead is tagged to. We can add or remove quickly these leads to any list.
"Love to have" isn't quite the use case I was looking for , but I provided more information about the webhook approach on this older thread: https://nation.marketo.com/message/182101-re-rest-api-is-it-possible-to-get-the-lists-associated-wit...
Would be great if we get this functionality, I am aware that some of the marketing automation tool has this function. Thanks for you time Sanford.
Well, Marketo's feature set isn't so driven by how one might use the UI for ad hoc work, but by true marketing automation needs.
The emphasis on MA means you shouldn't be in a situation where you need to see every single list across your instance, regardless of its relevance to the current task.
Again though, I have indeed been in situations where maintaining an allCurrentLists type field is justified. With the API, fetching list-first is clearly inefficient. The field is also useful in Velocity.