Lead Owner Queue

Lead Owner Queue

I want a brand new field in Marketo named Lead Owner Queue that gives the name of the Lead Queue that owns the Salesforce lead. For Contacts and User owned leads this value would be blank.

Justification: we sync every lead to Salesforce. Most of our leads bubble up through a series of territory and status based Lead Queues. Our generic lead queue is called Marketing. It is very frustrating that I can't do an "If Lead Owner Queue is 'Marketing' Then..." In a lot of cases just doing "If Lead Owner Queue is not empty" would be incredibly useful too.

There is a related idea over here:
http://community.marketo.com/MarketoIdeaDetail?id=08750000000HDlJAAW

I believe my proposal is very focused and acheivable and avoids the contention discussed in the comments of that idea regarding reusing one of the existing lead owner fields for this purpose.
28 Comments
Anonymous
Not applicable
I don't care if Queue is in it's own field or the same one as lead owner. I just need to be able to see it and segment using it, stat!
Anonymous
Not applicable
Two really important things here, though I like the idea:
1) in SFDC, people are used to seeing owner in one place, whether that's a queue or an individual owner. If these are separate fields it will make it a bit non-obvious to the person used to SFDC.
2) there must be an AUTOMATIC (ie: you don't have to build your own marketing activities to make it so) way that if the owner changes from a queue to an owner, then the queue is blanked out and then if it is changed back to a queue, the owner is blanked out. Ex: owned by marketing queue (owned by queue), sent to Sales Rep (owned by lead owner), then is sent back to the marketing queue (owned by queue). Obviously, the lead can't be owned by both and one of these areas needs to be blanked if the ownership is changed back and forth.
Anonymous
Not applicable
Ditto. And owner is an owner - queue or actual SFDC user. The super simple answer for this is for Marketo to actually use the queue name for Lead Owner First/Last Name. That would solve the first problem right away.

With just that bit of info we could set up flows/triggers for if/when leads changed hands.

Solution, I think... SFDC custom field with the value of Lead Owner. SFDC should see this as user or queue and store it as text. Have it updated on create/update and then you'd have that avaiable for use in Marketo.

But in general, that's a long way to go to just know the real owner name - queue or not. And I'd like to see Marketo just use the Queue name as lead owner first/

Anonymous
Not applicable
Hey guys, our current workaround was to create an SFDC field called Owner ID. Then from within Marketo we are able to query for specific queue IDs or simply say "Owner ID begins with 00G". Not at all ideal but it works.
Anonymous
Not applicable
Great idea! This will solve the "lead owner" issue in email siggys.
Anonymous
Not applicable
Sarah B, Kyle B or anyone,

Can you detail how you get the custom SFDC field set up so that it displays Lead Owner/Queue?

Do you use a workflow rule?

Thanks,
Anonymous
Not applicable
Sarah B, Kyle B or anyone,

Can you detail how you get the custom SFDC field set up so that it displays Lead Owner/Queue?

Do you use a workflow rule?

Thanks,
Anonymous
Not applicable
Sarah B, Kyle B or anyone,

Can you detail how you get the custom SFDC field set up so that it displays Lead Owner/Queue?

Do you use a workflow rule?

Thanks,
Anonymous
Not applicable
I think that marketo should  make this a priority and have a step by step on the work-around or better yet just make this a priority and fix the problem.  This is really something that makes me re-think their dedication to product quality improvement verse additional modules to sell.
Anonymous
Not applicable
+1 on this feature request. Marketo should correctly display SFDC owners out of the box, whether the owner happens to be an SFDC user or an SFDC queue. I understand there is a workaround. It seems like bad usability, though, to ask customers to take special steps to get this important functionality working. If you can't fix the underlying issue, at least productize the workaround.