Connecting up the 'Support' Dots...


  • Amie Brennan

    Hey Gary, 

    I had a read over your post here a couple of times. In reality, the truth of the post came down to your last line:  join up the dots of the key items of CRM data: organizations, the users who work for them, and the tickets they raise. 

    As far as my understanding goes... this is the way the data works in Zendesk, exactly how you describe it. 

    - You have an Organisation i.e Org A.

    - You then have a bunch of users who all work for Org A and submit/raise tickets to your Zendesk. For example's sake, you have 5 different users. 

    In this scenario above, the 5 users themselves, their individual Zendesk profiles each need to be linked to the organization in Zendesk which has been created for org A. 

    From this point, after the users have been linked directly to the org in Zendesk, when any of those 5 users then submit a new ticket, the ticket will automatically be raised against that organization and be represented on the ticket visually for the agent to the left of the Requesters name and Ticket ID in the top right-hand corner of the ticket window. - There's no need for you to have a manual ticket field to capture the organization on the ticket. 

    Feel free to correct me if I'm on the wrong path with this for you, however, this is basic functionality in Zendesk already. Once you have users linked to orgs, you can then create all types of different automatic workflows with triggers etc based on the org itself. 

    This might also be a good read for you as well in case you need:

    Hope this helps. :)



  • Gary Donoghue

    Hi Amie,

    Many thanks for coming back to me so promptly - much appreciated. Before responding I should, perhaps, provide the wider context of this post into the Support feedback forum...namely and community moderator Devan's response to it viz...

    Hello Raman Kalia & Gary Donoghue,

    These are phenomenal posts from both of you that breakdown your use cases perfectly. I'm going to be passing this along to our product managers, but I can't stress enough that sharing this in our product feedback forum would be helpful for other users and our product team. It is where we keep conversations on topics like this and often where our PMs look for use cases from the community.

    In your response you mention the relationship between organisations and users which I am clear about (as ZD allows organisations to be defined (based on domain name(s)) and users then connected to that organisation. A user can then be connected to a ticket via various means, the ultimate reference being the 'requester' - so, yes, the dots are connected...but perhaps, to push the analogy a bit further, they are just a little faint than I would expect or prefer them to be.

    The main point of my contribution in this discussion on the original forum posting was that there is valuable OTHER data contained/stored within an organisation (and a user for that matter) that would be useful to see appear within a ticket itself. I cite an example of our own...the 'release level' of our software a specific customer is using. This is useful information we like to store on a ticket yet it is NOT presently possible for me to do this via the relationship the requester (user) has to an organisation (he/she belongs to) and the 'release level' field stored for that organisation. Each time a ticket is created we have to check the value of the Release level field in Organisation to make sure it is transposed onto the denormalised Release level field within a ticket. 

    So while the underlying architecture of Organisation-<User-<Ticket does exist (though there is no ability on the standard dashboard to open up a list of Organisation and/or Users - separate issue) it is the lack of interaction of fields (i.e. useful data) from the Organisation/User into tickets that is the main concern. A normal relational system should, I feel (and others agree - see the forum) provide this capability...i.e. to allow ticket fields to be defined from Organisations/Users (if present) where the key data for each is connected to a ticket: respectively the ZD ticket customer and ticket requester. 

    I hope this helps clarify the requirement further and also provide some wider context. 

    Kindest Regards

    Gary Donoghue


  • Raman Kalia
    Zendesk Luminary


    Adding my use case from the community post:

    Many organisations have contracted us and we are supposed to provide services to them. Service can only be rendered for the period of contract, which must reflect in the ticket by date of start or end of contract so decision making at agent level can happen. Contract dates must be defined at the organisation level as there can be anyone from client's domain email address raise the ticket. When raised, ticket must automatically pick up the date value (ie. start or end date of contract) from the organisation. This is because, other parameters like text, drop down, checkbox values can be copied automatically if custom ticket fields carry tag names same as of the organisation's "field key". But when it comes to passing on values from a custom 'date' field organization organisation to ticket's date field, system fails miserably to do so.

    Such a facility is important in applying appropriate workflow / trigger / automation / macro to the ticket. Any ticket, which is past expiry date of contract may need to be directed to sales instead of support. Alternatively, agent can take a decision if to address the ticket based on the date of start of end of contract.

  • Gary Donoghue

    Hi Raman. Many thanks for adding. Hopefully a few more people will join in too. Take care. 

  • Fernando Duarte

    The Jira Integration does not support Organization fields to sync.

    We need to be able to pass the organization value to the linked Jira.  The only workaround here is to create an individual trigger for each Organization to populate a custom ticket field.

    Just imagine the load on the system as we continue to add a trigger per organization



Please sign in to leave a comment.

Powered by Zendesk