You can share tickets from your Support account with other accounts. And, those other accounts can share their tickets with your account. You establish sharing agreements with other accounts and specify the terms under which sharing can occur and how shared tickets are managed.
Ticket sharing allows you to assign tickets to affiliated accounts and their agents either provide information toward resolving the issue or solve the issue themselves. The ticket status and comments can stay synced between the tickets in each account.
Once you've familiarized yourself with the ticket sharing process and activated a sharing agreement, as described in this article, you can begin sharing tickets.
Understanding how ticket sharing works
- Any Support account can invite another account to establish a sharing agreement.
- The initiating account (the sender) sets the terms of the sharing agreement, which the receiving account can accept or not.
- Sharing agreements are one way. Once the receiver accepts the agreement, the sender may share tickets with the receiver. For the receiver to share tickets with the sender, they must create and initiate a sharing relationship with the other account.
- If you only have receiving agreements, the sharing ticket field will not appear, and you cannot stop sharing received tickets.
- The sender can only share a ticket with one other account. However, the receiver can share the ticket with an account that they have a sharing agreement with.
- A shared ticket becomes a new ticket in the receiver's account with a separate ticket ID.
- The ticket status, custom fields, and comments can remain synced between the ticket versions in both accounts. The custom fields must be created in both accounts (see Syncing custom fields with another account below). CC recipients are not carried over from the original ticket to the shared ticket.
Note: Any public or private comments added to a shared ticket will be visible to agents in both the original Support account, and the Support account the ticket is shared with. Any public comment to the shared ticket will also notify any users copied on the original ticket.
- All ticket statuses can match, except for On-hold. When a ticket is changed to On-hold in one account, it will be submitted as Open in the other.
- Call recordings (including Voicemail recordings) in a shared ticket, can only be accessed by signed-in agents of the Support account that the original call is associated with. For example, Account A shares a call ticket with Account B, which includes the calls recording. The agents in Account B will not be able to listen to that recording in the shared ticket. If they are agents in both accounts they can listen to the recording by signing into Account A, locating the original ticket and listening to the file there. Transcriptions of voicemails remain visible, as lines of text within the shared ticket.
- Depending on the terms of the agreement, the receiver may directly communicate with the ticket requester and solve the ticket.
- Sharing tickets creates a dummy user in the receiving account for each user associated with the sending account ticket. The user is created even if there is a user in the receiving account with the same name and email address as the dummy profile. If an agent in the receiving account makes a comment on this shared ticket, a dummy end-user account is created in the sending account to represent this agent.
Shared tickets do not pass on user information. Tickets are never be linked to matching users in the receiving accounts, unless an agent of the receiving account manually adjusts the requester of the shared ticket when the user is created in the receiving account. This adjustment is not recommended as it can cause issues with the sharing agreement.
- Each account's business rules remain separate.
- A shared ticket cannot be merged with another ticket.
- An account can automatically refuse to accept all sharing agreement invites.
- Sharing agreements can be cancelled at any time by either the sender or the receiver.
- When you send email to another Support instance, automatic emails notifications are suppressed, but email notifications generated by an agent action are sent. This can cause problems if you have a ticket sharing agreement with the other Support account. In that case, it's possible to create an endless loop of notifications if the email address for the user in the CC or Requester field is the support address of a Support account you have a sharing agreement with. For information about how to prevent endless loops, see About mail loops and Zendesk email.
- When tickets are shared between Support accounts, user fields and organization fields are not shared with the ticket.
- Renaming an account involved in a sharing agreement breaks the agreement. If you must rename a Support account with a sharing agreement, see Can I rename an account where a ticket sharing agreement is setup.
Setting up a ticket sharing agreement
To set up ticket sharing an administrator creates a ticket sharing invite and defines the terms (permissions) of the sharing agreement.
- Make public & private comments, sync status
- Make private comments, do not sync status
The first option allows the receiver to communicate directly with the requester and to change the ticket status (for example, setting it to Solved). These ticket updates are also reflected in the sender's version of the ticket.
The second option (private comments only and no status syncing) limits the other account to providing you with information needed to resolve the support request. For example, imagine a company that builds something that includes components from other companies. Each affiliated company (business partner) can set up a Support account and a sharing agreement to provide more details on issues related to the components they supply. In this scenario, the sender controls the ticket from initial request through to resolution, gathering information as needed from the affiliated account.
- Click the Admin icon (
) in the sidebar, then select Settings > Tickets.
- Select the Ticket sharing tab.
- Select add sharing invite.
- In the window that appears, select another Zendesk Support account or a third-party system.
- Enter the URL for the account you're sharing tickets with. Depending on the option you selected in the previous step, you'll see one of the following fields:
- Zendesk Support account: Partner Zendesk domain field
- Third-party systems: Sharing URL field
- Select an option from the Comment status and permissions field:
- Make public & private comments, sync status
- Make private comments, do not sync status
- Select an option from the Tag synchronization field:
- No, do not share tags between me and the receiver
- Yes, share tags between me and the receiver
Note: As noted on the dialog box, enabling tag synchronising may add more tags.
- (Applies only if sharing with another Zendesk Support account) Select the custom fields syncing setting. You have two options:
- No, do not sync custom fields between me and the receiver
- Yes, sync custom fields between me and the receiver
- Click Send Invite.
The receiver is notified of the invite on their Ticket Sharing page, as shown here:
The receiver can view the terms of the sharing invite and either accept, decide later, or decline the agreement.
When accepted, both accounts can immediately share tickets.
If you decline an agreement, the sender is free to try again at another time. If you don't want to establish sharing agreements with any other accounts, you can set your account to automatically decline invites (see Opting out of all sharing invites). You can also deactivate sharing agreements at any time (see Deactivating a sharing agreement).
All of your sharing agreements (accepted, pending, and rejected) are displayed on the Ticket Sharing page.
Opting out of all sharing invites
If you decide to not share tickets with any other account, you can choose to opt out of all sharing invites.
- Click the Admin icon (
) in the sidebar, then select Tickets.
- Select the Ticket sharing tab.
- In the section Opt out of sharing, select the Decline all sharing agreement invites.
- Click Save Tab.
With this option set, you will never be informed of a sharing invite.
Deactivating a sharing agreement
Sharing agreements can be deactivated by either the sender or the receiver at any time. Deactivated agreements can't be reactivated, but both accounts are free to invite the other to accept a new sharing agreement.
- Click the Admin icon (
) in the sidebar, then select Tickets.
- Select the Ticket sharing tab.
- Locate the agreement you want to deactivate and then select View.
- Click Deactivate Agreement.
Your agreement partner will be informed of the deactivation via email and this will also be reflected on their Ticket Sharing page. Deactivating an agreement means that no new tickets can be shared and that tickets that have already been shared will no longer be synced.
Referring to shared tickets in business rules
Tickets that have been created in your Support account via ticket sharing can be referenced as conditions in automations, triggers, and views. The condition Update via also includes Ticket sharing as a value.
You can create a view of the tickets generated from ticket sharing, as in this example:
This will show you all the tickets that were shared to you. If you want to create a view of the all tickets you shared to another account, you can add a tag to the tickets and create business rules from that.
You can create automations or triggers that include the ticket sharing conditions. Again, using Update via is Ticket sharing as a condition you can create a trigger to escalate the shared ticket to a specific support group, to add tags, and so on.
Additionally, you can filter the view to show only inbound or outbound tickets if you have set up receiving agreements in your account.
- For inbound tickets, add a clause: Ticket sharing: Received from > (instance name of who you are sharing tickets with).
- For outbound tickets, add a clause: Ticket sharing: Sent to > (instance name of who you are sharing tickets with).
Syncing custom fields with another Support account
As described in Setting up a ticket sharing agreement, you can select to sync custom fields with another Support account. To make this work, each account must create the custom fields separately. For example, if you want to sync a custom field called "Camera model" it must exist in both accounts and must have the same title and data type.
The custom field title is not case sensitive so the sync will be successful even if one custom field is called "Camera model" and the other is called "Camera Model".
What is important to keep in mind is the data types used in each custom field; they must be compatible. The simplest way to ensure this of course is to use the same data type for each. In our example, both versions of "Camera model" are drop-down lists.
Other syncing rules include:
- If an incompatibility between custom fields does exist, the ticket will sync but the incompatible custom fields will fail (no data will be transferred).
- If you're using a ticket field that has tags associated with its corresponding values (for example, drop-down fields), the tags must be the same across both instances. If you have matching ticket field names and values, but the tags differ, the sync between ticket fields will fail.
- If a ticket is shared between two accounts, only the account where changes to the field value are made will see a record of that change in the ticket events/audits. The other account will see the altered field value, but will not see any details about the change, such as who made it or when it was made.
83 Comments
Is there any plan to enable customer information to be shared and 'CC' to be shared between the instances with the agreed sharing setup.
What is the recommended way to work with shared tickets when syncing status?
We are sharing tickets with one of our customers and recently changed this to sync status.
The problem we had before was that we sent Ticket A to our customer using status: solved, our customer responds with a status:pending from their end but since we did not sync status the ticket still is considered solved and we don't show solved tickets in our views.
The problem we have now with status-syncing is that they send the ticket in status: pending and we sync it to status:pending on our end which still means we will not see the tickets since we don't generally show pending, solved or closed tickets in our views.
Hi Daniel
Working with Ticket Sharing can be tricky as you undoubtedly have noticed.
For your setup to work, where you have different statuses in each of your Zendesks, i would switch back to not syncing status. That way you can, on either side of the fence, create triggers that change status on different events. ie, you could create a trigger that reacts on "received from = Customer A ticket sharing" + "Status = Pending" -> Change status to Open. Or something similar.
Hi All
I am desperately trying to work out how I can have the Sending Organization and the Receiving Organization of shared ZD instances display the respective ticket numbers.
Any suggestions and description of how this has been done will be welcome.
I did see a snippet in a previous post but unfortunately I am uncertain as to how the user achieved it using placeholders in Triggers / Macros.
Thank you!!!
Hi Russell,
This really depends on how and where you want the ticket ID to appear. If you want an internal note to be included on every shared ticket with the original ticket ID, I would create a Macro that sets the 'Comment mode' to 'Private' and provides a 'Comment/description' that contains the {{ticket.id}} placeholder, such as follows:
I am desperately trying to set up a view that captures both tickets shared and received by each of our Zendesks.
Tickets are tagged, and I'm using this criterion in the conditions:
- Channel is: ticket sharing
- Tags Contains at least one of the following: cs
- Ticket Status Less than Closed
Yet I come out empty handed each time!
Any ideas folks? :)
@Oliver
Would this work? You would just add your tag criteria potentially?
@Nick
Thanks that does work to a degree.
The only problem is both instances need to run a macro. I was looking for something that could auto-populate a filed or the comment of each ticket number.
Thanks all the same.
Russell
@Russell Da Silva
Ah you genius!!
I think I was creating way to many conditions. Sorry I'm new to this.
Thank you so much for your suggestion. You saved the day!!! :)
HI,
When you set up the ticket sharing, does this mean all the tickets from the Sender's instance will be created (with a new ticket number) in the Receiver's instance?
Is it possible to just share a specific ticket to the Receiver's account if needed? Basically, I don't want to share all tickets to the receiver's account. Only those that we need to be worked on by the a "team" in the Receiver's instance.
Also, can I assign the ticket to a specific group in the Receiver's instance?
Thanks,
Albert
@albert
When you set up the ticket sharing, does this mean all the tickets from the Sender's instance will be created (with a new ticket number) in the Receiver's instance? ALL SHARED TICKETS CREATE A NEW TICKET IN THE OTHER INSTANCE.
I SET UP A MACRO THAT HAS BEEN HELPFUL FOR THE TWO TEAMS TO SEARCH AND ADDRESS THE SAME TICKET - RUN A MACRO THAT ADDS THE TICKET ID TO SUBJECT
Is it possible to just share a specific ticket to the Receiver's account if needed? YES
IF YOU SELECT THE SHARING DROPDOWN OF THE INSTANCE YOU WISH TO SHARE THE TICKET WITH:
Basically, I don't want to share all tickets to the receiver's account. Only those that we need to be worked on by the a "team" in the Receiver's instance.
Also, can I assign the ticket to a specific group in the Receiver's instance? I AM NOT 100% SURE IF THIS IS POSSIBLE BUT PROBABLY NOT....YOU MAY HAVE THE RECEIVING INSTANCE TRIGGER TICKETS INTO THE RIGHT GROUP AS AN OPTION MAYBE?
Hope this helps.
Russell is correct regarding assigning to groups. You cannot influence the group this goes to from your end, but the receiving end can create a trigger to do this.
If only some tickets need to go to a specific group, you could provide some text in the title or macro comment to help them trigger something specific. It's pretty straight forward, so if you need more help, just let us know.
On Laurie's comment above: https://support.zendesk.com/hc/en-us/articles/203661466/comments/115000717807
There does not appear to be a way to add the ticket.id to the ticket as a private comment, or into a custom field. It's, of course, very simple using a macro. Any thoughts? Thanks!
Hi everyone,
I've set up a two way sharing agreement with another Zendesk instance (the intention was really to share between two brands in two different instances but seems like that was not possible).
The agreement is to not sync status and only make private comments, not share tags and not sync custom fields.
However, while testing between our two sandbox environments, we found that both private and public comments came through in shared tickets - do you know why that is for public comments?Also, the requester (enduser) from their instance doesn't seem to be recognised by ours even though we have the same end users. Is that because of our choice to not sync custom fields?
Thanks for your hlep!
Hi Catherine,
With a ticket has been shared between two instances, the private comment permission is specifically working with agent permissions. So for example, we would expect that a public comment made by end-user would show up as public when the ticket was being looked at in either instance.
However if an agent in the instance the ticket is shared with tried to make a public comment on that ticket, the update would be converted to a private note because only agents in the ticket's original instance have permission to make that update.
Regarding the end-users, with two separate instances, even if the users are the same in real life, they have different user accounts and ids that will not transfer between separate accounts. You would have to be using multi-brand if you wanted the user data to genuinely sync between the two brands because then there would only be one user profile.
I hope that helps! Please let us know if you have other questions, or open up a ticket if you want to go over specific examples with the sandbox tickets.
Best,
Gail | Customer Advocate Tier 1 | support@zendesk.com
Thanks Gail, this does help some. I did open a ticket with support in the meantime and will take the rest up with support.
the 'sharing' field disappears as soon as I open a ticket.
If I refresh the page, the field appears and once the page load, it disappears again
Hi Massimo!
Have you done any other troubleshooting on this issue? For example. have you tried logging in to Zendesk in a different browser?
Most often this is because a customer replies to an email ticket from an email other than the one it was sent to.
Also if users open tickets on your site without signing in, that could possibly cause this.
Check the ticket events and trace where they are coming from.
Hi,
Is there a way to send all ticket correspondence in a company Zendesk environment to a company mailbox that is outside Zendesk? So if anything happens or if it is decided in the future to move to another platform that all tickets are still available within the company?
Best regards,
Óðinn Thor
Hi Óðinn!
You have a couple of options here. If you're on Professional or Enterprise, you can use the in-built data export tool. If you're on the Team plan or lower, or if you just a preference to do it this way, you can export using our incremental API.
Since you mention an email, you could just set up a trigger to email each ticket's comments to a company email when the ticket is solved. Preferably this would be an agent email so that private comments would be visible. If the email is a secondary email for an agent, you should be able to do this. You may need to use trigger and target.
Hi! I have a question about two statements in this article:
"All ticket statuses can match, except for On-hold. When a ticket is changed to On-hold in one account, it will be submitted as Open in the other."
"Note: To use the On-hold status, both accounts must have that status activated. See Adding the On-hold ticket status to Zendesk Support."
Either these two statements are conflicting each other or the second statement has a different meaning.
Assuming it's the latter, does the second statement mean that the instance with On-hold enabled cannot use this status in tickets currently shared to the other instance that has it disabled?
If it's the former, I confirmed multiple times that the first statement is correct.
Hi Christian, I do see that the statements in the article are somewhat contradictory. I'm going to open a ticket from your comment so we can get this tested and update the docs accordingly. Thanks for bringing this to our attention!
I'm looking to change the name of the instance that we can share tickets with, but not the agreement. It works fine, but the name in the dropdown doesn't reflect the activities of the shared instance anymore.
The only way I can now see this happening is by revoking the current sharing agreements and adding new ones. But that will probably mean that currently shared tickets become orphaned.
Any ideas?
Hello Harold,
So, unfortunately, this isn't something that can be accomplished as the platform currently stands. As you stated accomplishing this would require revoking the current sharing agreements and adding a new one, but that doesn't deliver you to what you are trying to accomplish.
If there is anything else we can help with, please let us know and thanks for reaching out to us.
Hey team,
Just wondering if this can be restricted by group?
We'd love to allow some of our group members to share tickets with external orgs but don't want this to be open to the rest of the business (an extra field that most of the business don't care about).
Are attachments shared when sharing tickets with a separate instance?
Schuyler
Yes, attachments are also shared when using ticket sharing.
Hello, I also want the option to share Public comment only in ticket sharing. It has been a while since this topic was discussed in this thread but is there any future product plan on this soon? I'm seeing that Yann Souetre's comment that summarized well.
Please sign in to leave a comment.