Issue: Tickets Owner and associated Conversation Assignee are not linked.
Use Case: Our support team rotates who is on call. Whoever is on call during a specified period of time will answer incoming client issues for that period. To facilitate this, we have the Conversations Inbox set to unassigned for new incoming messages. We also have it set to automatically create new tickets, which also have the ticket owner as unassigned. If a support rep claims a Ticket they set themselves as the owner, BUT the associated Conversation is still shown as unassigned.
As a result it diminishes our team's ability to work out of both the Ticket and Conversation areas concurrently, as ownership of something in one area is not reflected in the other. This reduces the usefulness of the Conversations Inbox.
Solution: When an unowned Ticket (automatically created from a new Conversation) has it's owner set, also assign the associated Conversation to the same user.
One way our team has worked around this is to assign the conversation in the inbox first. The ticket will then assume the same owner as the conversation.
Hubspot,
On occassion, a ticket needs to be handed off to another department, requiring it to have a new ticket owner - which we have been able to easilly reassign through a workflow, but ALSO needs the conversation owner to reflect the new ticket owner, along with being moved to the new department's inbox. When we manually move a conversation to a new inbox, it automatically unassigns the conversation and I would like to have the option to keep the assigned owner.
Since 2 of our departments use the same pipeline and frequently hand off tickets between each other, the teams have access to each other's inbox and we have been able to manually assign the conversation to match the ticket, but then it all goes kerplunk when we move the conversation.
My business would also love this feature! We're never in a situation where the ticket assignee and the conversation assignee would be a different person. We use mainly tickets over the conversations, and remembering to change both is proving very difficult.
Our reps are having to manually assign the conversations to themselves when the ticket is automatically done. I am trying to convince leadership to upgrade to enterprise and to roll this out company-wide and this small issue negatively weighs on the decision. Hoping it happens soon!
No reason for the conversation and associated ticket to have a different owner as well. Would be very usefull to be able to assign the ticket owner to the conversation.
Disappointed no solution exists for this yet. We've recently migrated to the Service Hub and this add unncessary complexity/uncertainty for our support team
We've got a similar use-case. A workflow that updates the Ticket Owner whenever the associated Conversation Owner is changed - but we can't do the reverse, to update the Conversation Owner to match that of the Ticket via Workflow.
Hi @callie - thanks for that. I don't see that in out portal. I just did some more testing and the Ticket Owner still isn't updating.
Perhaps this only happens when in Inbox settings "Automatically assign conversations" is set to on (we don't use this, as we use a Workflow to triage based on a few key data points and define the owner); and then the subsequent Inbox setting below this "Treat incoming conversations as support tickets", where you can tell HubSpot to "Inherit Conversation Owner", which we have turned on, but as I said it seems not to work, presumably because either (a) we have the former setting turned off? or perhaps (b) because some of our users are not Service Pro and therefore HUbSpot doesn't rotate to the next owner (though we are able to do this in a workflow). Unless I'm missing something else?
Hi @callie - OK further to my last message (humble face) it seems Conversations does do what you said - except not for the very first assign Owner action in Conversations.
What I mean is, per the settings I previously outlined, we don't assign an Owner to any Conversation, hence no Owner is updated on the Ticket (except if we have a Workflow turned on). Then if we add a Conversation Owner for the first time, it doesn't update the Ticket - again, this applied to scenarios where there has never been a Ticket Owner and where there is one already assigned.
However all subsequent changes to the Conversation Owner then update the Ticket owner too.
So I guess our Workflow that updates the Ticket Owner based on the Conversation Owner change is still needed, though only for that first change.