Skip to main content
Visit Freshworks.com Visit Freshworks

I understand the purpose and the need for shared ownership but I probably don't understand the working principles.


I have enabled it in my trail, I also defined some groups and custom status fields.


I understand that the correct group is to be set in the property "Assign to (internal)" after setting the custom status. This is what I did.


My first question here is: Why is there a distinct property "Assign to (internal)"? I can also assign the same group to the regular "Assign to" property, even WITHOUT setting that custom field.


The "Assign" properties allow only ONE choice (one group, one agent, or one group with one agent). So my next question would be: Why not simply allowing multiple choices in the "Assign" property (multiple groups, multiple agents of various groups, etc...)? All of them would then share the ownership.




I understand that

  • The "Assign to" field corresponds to the primary group and primary agent of the ticket..
  • The  "Assign to (internal)"  field corresponds to the 'Internal group' and 'Internal agent' of the ticket. Depending on the status, you can assign an internal group and agent from the list mapped to the status
What confuses me is that it depends on the status. And what confuses me even more is that it depends on a CUSTOM status. To me ti looks as if the status field is used for two purposes and in my experience, that is never a good approach.
But probably I am missing something. I think I've read almost any article I can find here. So, any extra input here or some links to other info is helpful.

Thanks.


I wold tend to agree that the status field should not mix status (Open, Pending, etc) with shared ownership. Why not just allow me to share ownership regardless of the status field value? In fact, it s very cumbersome because the default behavior (through rules/automations) is to remove the shared ownership when the customer replies (sets it back to Open which clears the internal group/agent). So I have to create more rules to prevent this and it isn't always the right thing to do. 


So decoupling the shared ownership from the status would be optimal. Perhaps there just needs to be an Internal/Shared Ownership Status field?



Sarah - to be fair, I think what you want or need is Parent-Child tickets:
https://support.freshdesk.com/support/solutions/articles/224563-parent-child-ticketing-views-filters-and-ticket-scope


This allows you to create a new ticket that could be completely internal and assigned to another agent in any department as the primary rather than internal group/agent.


Cheers

Craig



This is a problem for us as well. There is no reason for linking a status to an internal assignee. A child ticket would only be relevant if the issue was generic or systemic as to why the ticket was created in the 1st place.


For example, child tickets are used when there is a process that needs to be fixed when the existing process has a flaw that initiated the need to create a ticket.


A ticket is assigned an internal agent when a customer service agent needs the help of another internal resource to solve the problem on this specific ticket.


The other problem is that when assigning an internal agent to a ticket, as soon as the status goes to one that can't be mapped the assignment is removed.


Having multiple agents from different groups assigned to a ticket is very useful when a team is required to solve or close the issue.  



My findings this past week were that the notification system is lacking when it comes to shared ownership. There is only 1 automated email (agent notification) that will work when tickets are assigned internally, Ticket Assigned to group. I found that none of the browser notifications worked when assigning an internal group and internal agent. In my opinion the lack of notifications to agents a ticket has been assigned renders this functionality useless.


We are trying to build a workflow in which a support agents is working an issue and an inside sales opportunity, or CSM issue arises from the ticket. The support agent would then share the ticket with the concerned parties. However no useful notifications means the ticket will go into a black hole.



@Sean


If you are referring to the in app notification for the agents (the smart notifications) , it indeed works for the internal agents too when tickets are assigned to them. Please write to us at support@freshdesk.com and our support stars should be happy to assist you further with this.


Thanks!




Reply


Terms of Use