Considering one or multiple Zendesk instances

<p>Your company may have multiple organizations that include a variety of departments with different processes, security needs, and workflows. It's useful to consider if one Zendesk instance will work well for your situation, or if multiple instances would be better. This article describes the benefits, considerations and consequences of using multiple Zendesk instances instead of using just one. It includes the following topics:</p><ul>
<li data-list-item-id="e5cc2013fd192fb6ece606040a0da15cb"><a href="#h_4668644872031535056322970">Feature considerations</a></li>
<li data-list-item-id="eae9ad4e4720c16e411a4a913bfbd2bdc"><a href="#h_8232884472121535056343026">Scoping questions</a></li>
<li data-list-item-id="e9520c094cf0335dfa57ea2ab61a92e39"><a href="#h_1108117232291535056381715">Summary</a></li>
</ul><h2 id="h_4668644872031535056322970">Feature considerations</h2><p>This topic covers the impact of using one Zendesk instance for multiple teams for the following features: </p><ul>
<li data-list-item-id="efd81c65e5be1623b35fbd6f19be2264f"><a href="#h_6987689601331535049025839">Global settings</a></li>
<li data-list-item-id="e78d06c9f585c3e73e711386b6efa77bc"><a href="#h_4426346181541535049096896">Business rules</a></li>
<li data-list-item-id="e565329a7e6dee3678e9ff9cdfe953134"><a href="#h_1805212981641535049114989">Integrations</a></li>
<li data-list-item-id="e4565fb71f6256810b86b2bb0273b8a52"><a href="#h_4083103611731535049132138">Authentication and access</a></li>
<li data-list-item-id="ef664a704179b3d8333a30b8a91322314"><a href="#h_8289472011811535049153997" rel="undefined" target="_self">End user management</a></li>
<li data-list-item-id="ec2f14c23489475ece3d31845981be540"><a href="#h_01GXYEHBC8GHBVFRJX6EBSYDJS" rel="undefined" target="_self">Agent permissions and ticket access</a></li>
<li data-list-item-id="e20e81cdadd1c86c5b76576b74ba163b3"><a href="#h_8513726261911535049172882">Reporting</a></li>
<li data-list-item-id="e6b9e03b397be050ef4bb870bbc02b760"><a href="#h_5768327541971535049188395">Web Widget (Classic) and Chat widget</a></li>
<li data-list-item-id="ef26e5f5ab683f345342b18ee9ec3905e"><a href="#h_4578988162021535049200694">Guide</a></li>
</ul><h3 id="h_6987689601331535049025839">Global settings</h3><p>This section describes considerations for global settings. </p><ul>
<li data-list-item-id="e6f5c2fb4de690ce9f6bf732c985454e9">
<strong>Subscription</strong><br>If you have one Zendesk instance, all agents must be on the same plan type for Support, Guide, Talk, and Chat. For Guide in particular, all Support agents have to be Guide agents. If only one team leverages Guide, this is a cost saving consideration.</li>
<li data-list-item-id="e69efc1de894c63ff0ec86b80ca392c59">
<strong>Agent Signatures</strong><br>There is one native global agent signature per Zendesk. As a workaround, you can customize triggers for each team, with the signature in the trigger or Liquid Markup conditions.</li>
</ul><div class="p">
<ul>
<li data-list-item-id="ecf7c19955145244e897771e2db5eddfb">
<strong>Email template</strong><br>There is only one native email template per Zendesk. The workaround is customizing all business rules, which support HTML, CSS, or Liquid Markup. See <a href="https://support.zendesk.com/hc/en-us/articles/4408883291290-Understanding-Liquid-markup-and-Zendesk-Support" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">Understanding Liquid markup and Zendesk Support.</a>
</li>
<li data-list-item-id="e440cbf7abc9250ce5736fd8eef658104">
<strong>Welcome/verification emails</strong><br>There is only one native end user welcome email/verification that follows the account name added in Settings &gt; Account.</li>
<li data-list-item-id="eccd1ce93ec29fdf6405126d367394f62">
<strong>Subdomain</strong><br>You can only have one subdomain for all agents to use and remember. It is not possible to customize the agent subdomain to team names.</li>
<li data-list-item-id="e62484490e28b27280df1dec6fbd57359">
<strong>Anybody can submit requests?</strong><br>One Zendesk account needs to be either open to all users or closed to all users. If open, anyone can submit a request, login to Guide, or submit a ticket with the widget. If closed, the end user must be an existing user in Support to submit a request, or access Guide. See <a href="https://support.zendesk.com/hc/en-us/articles/4408887573274-Configuring-how-end-users-access-and-sign-in-to-Zendesk-Support" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">Configuring how end users access and sign in to Zendesk Support</a>.</li>
<li class="wysiwyg-list-bold" data-list-item-id="e399efbb7c954acd2dc51d13139b937a0">
<strong>Account name</strong><ul>
<li data-list-item-id="e9cc9acb385ffa824ceaddb768d67043c">There is only one account name. See <a href="https://support.zendesk.com/hc/en-us/articles/4408894168602-How-do-I-change-my-account-name-in-Zendesk-Support-" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">How do I change my account name in Zendesk Support?</a>.</li>
<li data-list-item-id="e0aef1872f6b69cef4cb803f2b68d2efd">The account name is visible in emails if using <em>formatted</em> placeholders. The account name is a part of the email sent and visible to end users. To bypass this, you need to stop using formatted placeholders and use rich content placeholders instead which support rich text. However, this eliminates the aesthetic experience of formatted placeholders.</li>
<li data-list-item-id="e1aad62f9f6c7eaae935853b7c1620e72">Finally, the account name is visible on login page/prompt and is not editable.</li>
</ul>
</li>
</ul>
<ul>
<li class="title topictitle2" data-list-item-id="e48c4c37ddcf08f52f8d998482c435102" id="heading8">
<strong>Allow users to belong to multiple organizations</strong><br>If you decide to use one Zendesk instance across different teams, there is one global setting that is enabled or disabled for the entire instance.</li>
<li class="title topictitle2" data-list-item-id="e13294df223971bf57631f4768a6aaa07" id="heading9">
<strong>Satisfaction survey</strong><br>Even though satisfaction surveys are enabled or disabled for the entire Support instance, you can edit business rules to not fire for certain groups. A satisfaction link can be generated for any ticket using placeholders. See <a href="https://support.zendesk.com/hc/en-us/articles/4408886173338-Using-customer-satisfaction-rating#topic_hlb_fjw_cc" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">Using customer satisfaction rating placeholders</a>.</li>
<li class="title topictitle2" data-list-item-id="e4c61a167802976197c5e728fc8cb8034" id="heading10">
<strong>Data export</strong><br>Data exports of tickets, users, and organizations are global for the entire account. However, you can use the Zendesk <a href="https://developer.zendesk.com/api-reference/introduction/introduction/" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">Core API</a> to fetch more specific data.</li>
<li class="title topictitle2" data-list-item-id="e0a95251adc9dc5156dfe6aa3e340ec72" id="heading11">
<strong>Tags</strong><br>In an instance with multiple teams, tags should not be recycled for multiple workflows or resources.</li>
</ul>
<h3 id="h_4426346181541535049096896"><span style="font-weight: 400;">Business rules</span></h3>
<p><span style="font-weight: 400;">This section describes considerations for business rules.</span></p>
<ul>
<li class="title topictitle2 wysiwyg-list-bold" data-list-item-id="ec5261b1329d47dcf3f0aeb4824c4c130" id="heading12">
<strong>Triggers, automations, views, and SLAs</strong><ul>
<li class="title topictitle2" data-list-item-id="e326a688666b6335151de3f239fc4a4a3">Business rules run on all tickets, but they can be easily restricted with conditions that look up at ticket group or brand. See <a href="https://support.zendesk.com/hc/en-us/articles/4408894175130-Creating-managing-and-using-groups#topic_uxo_gag_bc" rel="noopener noreferrer" target="_blank">Using groups in business rules.</a> Admins are global and can create rules for groups outside of the ones they administer. This creates a risk of an admin for one team editing rules that impact other teams' tickets and workflows. </li>
<li class="title topictitle2" data-list-item-id="efa514629c48e339e24673f95b4a4a46a">If you use different teams within the same Zendesk instance, there is an increasingly large number of rules to manage. Increased complexity requires a change management strategy and on-going cross team collaboration. There is also an increased risk of tickets being misrouted to incorrect groups, which can have implications on SLAs.</li>
<li class="title topictitle2" data-list-item-id="ec72ab49ea571188abc97c9672890b2ba">You also need to make considerations for confidential or secured information being visible to agents who should not have access to it. There isn't a native method to organize business rules by group.</li>
<li class="title topictitle2" data-list-item-id="eeabcd705a6b0177a7fac712aa3f1eef2">You can create trigger categories to organize your ticket triggers. See <a href="https://support.zendesk.com/hc/en-us/articles/4408834781594">Creating categories to organize your ticket triggers</a>. It's not possible to create automation categories, but you can create placeholder automations that have no function other than a name to help organize your automations. </li>
</ul>
</li>
<li class="title topictitle2" data-list-item-id="eb724dd624392c369747f19b9da9daf6b" id="heading13">
<strong>Macros</strong><br>Macro access can be configured to all agents or agents in groups. See <a href="https://support.zendesk.com/hc/en-us/articles/4408844187034#topic_zh2_4nw_4y" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">Creating personal macros for tickets</a>.</li>
<li class="title topictitle2 wysiwyg-list-bold" data-list-item-id="e7c36baad9474ca8be670f676bdbd8e47" id="heading14">
<strong>Ticket fields and ticket forms</strong><ul>
<li class="title topictitle2" data-list-item-id="ec963d86cd7932c4803356f471d884df7">Ticket fields and ticket forms are global for the entire instance. All teams can see all forms and fields. Custom ticket forms are required to have unique forms for different teams and end user experience.</li>
<li class="title topictitle2" data-list-item-id="e1154e115bf24732d87b3a85bc4a357aa">In Agent Workspace, a custom app could hide or show certain fields depending on the current agent viewing the ticket.</li>
<li class="title topictitle2" data-list-item-id="e7708a09ae36b1fbccc3c83790655951a">
<span style="font-weight: 400;">Help center code customizations can hide non-required end user editable fields from the request</span><span style="font-weight: 400;"> form.</span>
</li>
</ul>
</li>
</ul>
<h3 id="h_1805212981641535049114989"><span style="font-weight: 400;">Integrations</span></h3>
<p><span style="font-weight: 400;">This section describes considerations for integrations.</span></p>
<ul>
<li class="title topictitle2" data-list-item-id="e8e7e76c121b42da7de150f02c35f3cac" id="heading15">
<strong>JIRA</strong><br>The v3 of the Zendesk JIRA integration is one-to-one. You cannot link multiple JIRA integrations to one Zendesk Support account. </li>
<li class="title topictitle2" data-list-item-id="e4c4d075aa6869580d93831006f4499a3" id="heading16">
<strong>Custom integrations</strong><br>Multiple Support instances require setup and configuration of each custom integration. For example, running data exports or connecting to a user database require development and configuration on both sides for each Support instance.</li>
<li class="title topictitle2" data-list-item-id="ee142da283d5c4cdcf8b62ba9d8c1daa9" id="heading18">
<strong>Apps</strong><br>Apps need to be installed and configured in each Support instance. If native options are not granular enough for your needs, you can code a custom app to check the user group and hide or show the app. It is possible to specify access to apps per group or custom role natively.</li>
</ul>
<h3 id="h_4083103611731535049132138"><span style="font-weight: 400;">Authentication and access</span></h3>
<p><span style="font-weight: 400;">This section describes considerations for authentication and access.</span></p>
<ul>
<li class="title topictitle2" data-list-item-id="ed2064aff777100a23a87708e52897c99" id="heading19">
<strong>Basic authentication</strong><br>With multiple Zendesk instances, logins (username and passwords) are unique to each instance. Agents and end users would need to manage and remember two sets of credentials for multiple instances of Zendesk that use native Zendesk authentication.</li>
<li class="title topictitle2" data-list-item-id="e11511be5f60e6fe4b1a924d31a3758b2" id="heading20">
<strong>API access</strong><br>API tokens are global, which means that any user with an API token can access all resources and data in the account.</li>
<li class="title topictitle2" data-list-item-id="e8b6110d06e3fc2aa94b756236596a7d9" id="heading21">
<strong>OAuth</strong><br>OAuth tokens can be scoped to only access certain resources. However tokens <em>cannot</em> be <a href="https://developer.zendesk.com/rest_api/docs/core/oauth_tokens#scopes" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">scoped to agent groups</a>.</li>
<li class="title topictitle2 wysiwyg-list-bold" data-list-item-id="eb30c4c18facb11845944d8a025ebbe47" id="heading22">
<strong>Single sign-on (SSO)</strong><ul>
<li class="title topictitle2" data-list-item-id="ee2a6beefe9fa48845c94f919c5e00b12">The native SSO applies to the entire instance for both agent and end user configurations. Agents and end users for all teams would need to be configured in the SSO identity provider.</li>
<li class="title topictitle2" data-list-item-id="e5e5705c6bb2811098a79039f720ec0f6">There are workarounds for users to be able to use different authentication methods (Zendesk auth and SSO), but this would have to be built on the customer side.</li>
</ul>
</li>
</ul>
<h3 id="h_8289472011811535049153997"><span style="font-weight: 400;">End user management</span></h3>
<p><span style="font-weight: 400;">This section describes considerations for user management.</span></p>
<ul>
<li class="title topictitle2" data-list-item-id="ecf54bf46f9330282eb7187fdfe8f34c9" id="heading23">
<strong>Organization and user fields</strong><br>Organization and user fields are global for the entire instance, which means that all agents can see and possibly edit them all. As with the ticket fields, a custom app can hide or show certain organization/user fields depending on the agent who does the viewing.<br> </li>
<li class="title topictitle2 wysiwyg-list-bold" data-list-item-id="e051e2b6396190d0f0bf3cd4b8b8411df">
<strong>Organization management</strong><ul>
<li class="title topictitle2" data-list-item-id="e0237c01d288a30b5e4a5b01b2b9442c9">Organizations are global for the entire instance. It is not possible to segment organizations or organization viewing permissions by agent groups.</li>
<li class="title topictitle2" data-list-item-id="e958511ad98424ecb5251e3efb8e1d4fc">For the <a href="https://support.zendesk.com/hc/en-us/articles/4408882246298-Creating-managing-and-using-organizations#topic_nat_vgn_bc" rel="noopener noreferrer" target="_blank">organization ticket sharing feature</a>, the access permissions are global to all tickets in an organization. If this option is enabled, it impacts all teams’ tickets using Support and Guide.</li>
<li class="title topictitle2" data-list-item-id="ef67dabe87d6465f5c7447ecc6acccf47">Organization names must be unique. While it is possible for users to belong to multiple organizations, it is not possible to have two organizations with the same name to accommodate multiple teams.<br> </li>
</ul>
</li>
<li class="title topictitle2 wysiwyg-list-bold" data-list-item-id="e2f6bc46b914a0b6dca5e4379fa2bc036" id="heading25">
<strong>End user permissions and access</strong><ul>
<li class="title topictitle2" data-list-item-id="ea999dd0aafd138a6ad6e2d5005ce2c0f">All end users are global to the entire instance. <span style="color: #000000;">It is not possible to allow one end user to submit requests to one team in an instance, but not allow requests to another.</span>
</li>
<li class="title topictitle2" data-list-item-id="e81c36ad548b2d8c8fdce4daf112176f5">Only one primary method of end user authentication is supported natively. End users are able to login to all help center instances. There are workflows that bypass this behavior, but they are highly customized and require some development on the customer side. </li>
</ul>
</li>
</ul>
<h3 id="h_01GXYEHBC8GHBVFRJX6EBSYDJS"><span style="font-weight: 400;">Agent permissions and ticket access</span></h3>
<ul>
<li data-list-item-id="ee7216a007e85917cdcafc3a87c0a496e">
<strong>Agent permissions to edit end users</strong><br>There are several considerations depending on plan type:<ul>
<li class="title topictitle2" data-list-item-id="e88c4fae3647003fcdd99a3d7b61c4e36">
<span style="font-weight: 400;"><strong>Custom agent roles</strong>: If your plan type includes custom roles, </span>you can allow one group of agents to edit end user profiles but not another. Agents are able to view the user profile of all end users. There are edge-case configurations where an agent does not have access to a ticket in another group, but does have access to edit end users. This includes end user assumption where the agent could see ALL tickets the end user requested.</li>
<li class="title topictitle2" data-list-item-id="e82d3c3dab5dfe38b430168bfa6b64735">
<span style="font-weight: 400;"><strong>Agent role</strong>: </span>On plan types without custom agent roles, only agents with access to <em>all tickets</em> will be able to add, edit, or assume end users.</li>
<li class="title topictitle2" data-list-item-id="ef3b4312270338e01f3df90b6231cc6e8">
<span style="font-weight: 400;"><strong>Special use cases </strong>where agents for one team are considered end users for another team: </span>Agents cannot submit tickets using the help center, and because of that, any end user forms will not work for agents. Regardless of group permissions, agents have access to tickets where they are the requesters, which means they can access any internal communication for their requester.</li>
</ul>
</li>
<li class="wysiwyg-list-bold" data-list-item-id="e513eb826c06c4b352f1e5b2dc119c08a">
<strong>Groups management and ticket access</strong><ul>
<li data-list-item-id="e5da4a30065f67ad1a9be946b19bd8355">Groups are global for the entire instance. It's possible create groups to manage multiple teams and restrict ticket access by group.</li>
<li data-list-item-id="e53dd3fffb32bdd9f61c4947b2657c1ef">On Enterprise plans, you can <a href="https://support.zendesk.com/hc/en-us/articles/4767122732058" rel="noopener noreferrer" target="_blank">create private ticket groups</a>. Private ticket groups provide more granular control over the visibility and access to tickets based on group assignment by completely hiding private tickets from agents who don't have permission to view them.</li>
<li data-list-item-id="e5c22db46379cd5663d8208390505a45f">Also on Enterprise plans, you can use custom agent roles to control agents' access to private ticket groups, including their ability to assign tickets to private groups.</li>
</ul>
</li>
</ul>
<h3 id="h_8513726261911535049172882"><span style="font-weight: 400;">Reporting</span></h3>
<p><span style="font-weight: 400;">This section describes considerations for reporting.</span></p>
<ul><li class="title topictitle2 wysiwyg-list-bold" data-list-item-id="ebac75fa86f15e4aad492013333eb82a0" id="heading27">
<strong>Reporting</strong><ul>
<li class="title topictitle2" data-list-item-id="eba8c92692c21f6ade0dd0fe46eb0f9ac">If using one instance, reporting is centralized. All ticket, user, and organization data is available to all users with access to reporting.</li>
<li class="title topictitle2" data-list-item-id="e4147f8541e30b6adddc6c9dbde83d0c6">In different plans, access to tickets controls access to reporting. Agents need access to all tickets to view reporting.</li>
<li class="title topictitle2" data-list-item-id="e03a5a66268afabc6a9da4dbb97c961f7">The default reporting dashboards are global to all Support data, which means that reporting broken down by group or some other ticket level attribute (custom ticket field, ticket brand, etc.) would need to be custom built.</li>
</ul>
</li></ul>
<h3 id="h_5768327541971535049188395"><span style="font-weight: 400;">Web Widget (Classic) and Chat widget</span></h3>
<p><span style="font-weight: 400;">This section describes considerations for the Web Widget (Classic) and Chat widget. They may not apply to the messaging Web Widget.</span></p>
<ul>
<li data-list-item-id="eabe2a383b82243db680830496a88b4ce">Native customizations and appearance (color, position, button text) are global. It is possible to use the <a href="https://developer.zendesk.com/embeddables/docs/widget/api" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">Widget API</a> to customize the widget per team, but this requires custom development.</li>
<li data-list-item-id="e960ebb2970144f1555744e5ac876839c">Ticket forms would be required to have a tailored form/field experience per team.</li>
<li data-list-item-id="e8673d6992e53dd5ba3aea96266b08517">The help center Search in the widget searches the entire knowledge base and only one knowledge base. However, with some custom development, you can <a href="https://developer.zendesk.com/embeddables/docs/widget/api#ze.sethelpcentersuggestions" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">possibly</a> customize search results.</li>
<li data-list-item-id="ee815adc5f10d85e82f82de7607ccf9f2">Chat can be either on or off for the widget, which can have implications if only one team uses Chat. You might be able to override this setting with <a href="https://developer.zendesk.com/embeddables/docs/widget/api" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">Widget API</a> and <a href="https://developer.zendesk.com/rest_api/docs/chat/introduction" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">Chat API</a> customizations.</li>
</ul>
<h3 id="h_4578988162021535049200694"><span style="font-weight: 400;">Guide</span></h3>
<p><span style="font-weight: 400;">This section describes considerations for guide.</span></p>
<ul><li class="title topictitle2 wysiwyg-list-bold" data-list-item-id="efaf444db802be8ca2ff5dcf2504a6d26" id="heading30">
<strong>Permissions for agents</strong><ul>
<li class="title topictitle2" data-list-item-id="e2addea5da8724889bbbbe835b1151541">A collaborative strategy is required if multiple teams are using one Guide. For instance, agents on one team who are managers will be able to manage content and edit themes for other teams, even if you are using <a href="https://support.zendesk.com/hc/en-us/articles/4408833921306-Multibrand-resources-Enterprise-" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">Multibranding</a>.</li>
<li class="title topictitle2" data-list-item-id="e2b1e3e5e34083e8d61f46fe7a3f81a99">Article edit and creation permissions are a mix of Support settings and Guide section level settings. Zendesk Support administrators are Guide Managers by default.</li>
<li class="title topictitle2" data-list-item-id="ea52491fe015e1a06866515de5ec1d6e0">If you are on a plan type with custom roles, you can create a custom role and set the Guide Manager permission. If you belong to a different plan, you can control who is a Guide Manager or Viewer in the agent's profile page. See <a href="https://support.zendesk.com/hc/en-us/articles/4408827842458-Understanding-Guide-roles-and-setting-permissions" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">Understanding Guide roles and setting permissions.</a>
</li>
<li class="title topictitle2" data-list-item-id="ebe710090d8163f71b8eb73e2ec530e5c">Agents can be set as a Viewer in Support, but still create and edit articles in all sections set to managers and agents in section-level permissions.</li>
</ul>
</li></ul>
<div class="p">
<ul><li class="title topictitle2 wysiwyg-list-bold" data-list-item-id="e39c60cb99a4084fe35da5481c7effc7b" id="heading31">
<strong>End user experience</strong><ul>
<li class="title topictitle2" data-list-item-id="e44df5d3d4a956f3516ce2ce447fb2e41">If using one Zendesk, all end users would be able to login to all help centers. If there are common end users when multiple teams are using one Zendesk Support instance for ticketing, end users would have one set of login credentials as opposed to multiple login credentials if the teams use separate Support instances.</li>
<li class="title topictitle2" data-list-item-id="efd145b9c1586530d1752eb909b4e5678">End users can see all tickets in one place if using one Support instance. However, this does not apply if tickets are in different brands.</li>
<li class="title topictitle2" data-list-item-id="eb3579ca3d97f9f5e0d4c016ecfd84282">
<a href="https://support.zendesk.com/hc/en-us/articles/4408824005914-Applying-user-segments-to-restrict-access-to-Help-Center-knowledge-base-content" rel="noopener noreferrer" style="background-color: #ffffff;" target="_blank">User segments</a> and permission strategy is required to manage who can view what content for all help centers associated with one Support instance.</li>
<li class="title topictitle2" data-list-item-id="ef06f43612f7baf2f458259e351421d35">Finally, if agents on one team are end users on another team, they will have a diminished help center experience. They would be redirected to Support to submit and view requests.</li>
</ul>
</li></ul>
<h2 id="h_8232884472121535056343026">Scoping questions</h2>
<p>Before you make a final decision, consider these scoping questions:</p>
<h3 id="h_01KK01VVKH8NGX3MBGYJHG3HV5">Should all agents have access to all tickets?</h3>
<p><span style="font-weight: 400;">If you are using one instance of Support with multiple teams, here are the considerations for allowing access to all tickets, or not allowing access to all tickets.</span></p>
<p><span style="font-weight: 400;">Allow access to all tickets:</span></p>
<ul>
<li data-list-item-id="e3ee8c8e1ce532a019cc5ea123c1ddcf8">If agents can access all tickets, how complex/scalable would it be to set up and separate ticket routing using Business Rules (views, triggers, automations, SLAs, email templates) for each team as Business Rules are global for the entire instance? </li>
<li class="wysiwyg-list-color" data-list-item-id="e2d41633c0060162f98dc2b53f0cdd4a6" style="--wysiwyg-list-marker-color: #000000;"><span style="color: #000000;"><span style="font-weight: 400;">For example, if two teams (Support &amp; Sales) use one Zendesk, a routing trigger for each team (as well as separate triggers for each auto-reply/comment update) are required to customize the end user experience for each team. </span></span></li>
<li data-list-item-id="eea69e403a41f12c132bc4267199b9406"><span style="font-weight: 400;">Increased risk of a ticket being misrouted in terms of SLAs.</span></li>
</ul>
<p>Do not allow access to all tickets:</p>
<ul>
<li data-list-item-id="eda2d567d07806cc5c7738757da9e1147"><span style="font-weight: 400;">Configuration of groups or custom roles is required to restrict access.</span></li>
<li data-list-item-id="ebbbd7a8bcbb37a6a6efb9747e2efc7db"><span style="font-weight: 400;">Careful ticket routing management is required so tickets are not accidentally routed to a group that should not access the ticket.</span></li>
<li data-list-item-id="ee025e324e61dec57bb5b582a961fc15d"><span style="font-weight: 400;">Limits visibility for agents into the other historic or current requests. Ticket access restriction can also restrict agent access to reporting.</span></li>
<li data-list-item-id="ee74a139c660f03b372f044d08840eb87"><span style="font-weight: 400;">Depending on your configuration, if restricted agents have the ability to assume end users, they would potentially be able access tickets outside of their group from <strong>My Activities</strong> in help center.</span></li>
</ul>
<h3 class="title topictitle2" id="heading2">Is there a centralized or existing user management strategy?</h3>
<p>Items to consider for agents and end users include:</p>
<ul>
<li data-list-item-id="e86dcd61e08cd0e70c1a85e448202e340">In terms of Zendesk authentication, users who are agents in both instances would have two sets of credentials.</li>
<li data-list-item-id="e52a52115be3b67be67de904e42320950">If you are using SSO, Zendesk needs to be configured as a service provider for both instances. If you are passing custom user data, you need to create user or organization fields in both instances. All custom user fields, organizations, and role have unique IDs, which requires configuring unique SAML/JWT assertions.</li>
</ul>
<p>Additional considerations for end users include:</p>
<ul>
<li data-list-item-id="edee98f39a8ee3857b51b705f7d4162d5">Should end users have access to help center content for both teams (for example, both HR and Support use one instance?</li>
<li data-list-item-id="e8b8752b55c9b263ef3d3bbe8c823a8ac">Should end users have access to all HR and all Support content?  </li>
</ul>
<h2 id="h_1108117232291535056381715"><span style="font-weight: 400;">Summary</span></h2>
<p class="p">Here's a quick overview of the benefits and considerations of using one instance vs. multiple instances:</p>
<p><span style="font-weight: 400;">If you're using one Zendesk support instance, benefits include:</span></p>
<ul>
<li data-list-item-id="eead8c9804a2187676e530c5a8c5d3cd4" style="font-weight: 400;"><span style="font-weight: 400;">Unified customer experience</span></li>
<li data-list-item-id="eaa7d846b313e2c2be1999c2e3b36811b" style="font-weight: 400;"><span style="font-weight: 400;">Unified reporting</span></li>
<li data-list-item-id="e031e3b4f00a5d210940251be5b711516" style="font-weight: 400;"><span style="font-weight: 400;">Agent cost: agents on both teams only require one license</span></li>
<li data-list-item-id="e5410bc88809922ec1fa7c1ecc4024f24" style="font-weight: 400;"><span style="font-weight: 400;">Cross-department escalations or tracking of issues are easier within one Support instance</span></li>
<li data-list-item-id="eb7d910083da46facabcfad06bd8b86d6" style="font-weight: 400;">
<span style="font-weight: 400;">Unified user management and authentication:</span><ul>
<li data-list-item-id="e11d106afd753c4e6279f9fd50abafd99" style="font-weight: 400;"><span style="font-weight: 400;">Single source of truth for users</span></li>
<li data-list-item-id="e502692624df748ed774ec7c69bd50e29" style="font-weight: 400;"><span style="font-weight: 400;">360 view of customer</span></li>
</ul>
</li>
</ul>
<p><span style="font-weight: 400;">Items to consider are:</span></p>
<ul>
<li data-list-item-id="eb292f6103a7a381203df17af0fc1ae9d" style="font-weight: 400;"><span style="font-weight: 400;">On certain plan types, restricting access to tickets is complex</span></li>
<li data-list-item-id="e1254ddccba6b5f459304b8441ca72d2a" style="font-weight: 400;"><span style="font-weight: 400;">Experience of agents who are end users for other teams is diminished</span></li>
<li data-list-item-id="e6a402c76fdd30518999c3d0db9c1b2a2" style="font-weight: 400;"><span style="font-weight: 400;">Requires a defined change management process and strategy</span></li>
<li data-list-item-id="edc5d545b88a3fba5114eff48c6b8d5d3" style="font-weight: 400;"><span style="font-weight: 400;">Increased complexity for ticket routing and business rules</span></li>
<li data-list-item-id="e89612236a8bb3b239459b5dc68c883c1" style="font-weight: 400;"><span style="font-weight: 400;">Many customizable features are globally configured (such as authentication, email template, account name, or welcome emails)</span></li>
</ul>
<p><span style="font-weight: 400;">If you're using multiple Zendesk instances, benefits include: </span></p>
<ul>
<li data-list-item-id="ea59fea5d54e2a0a3959135efb884d066" style="font-weight: 400;"><span style="font-weight: 400;">Compartmentalization is easier</span></li>
<li data-list-item-id="ed7eb8991756ae7ce703d11daa3a3a934" style="font-weight: 400;"><span style="font-weight: 400;">Flexibility to make changes that do not risk impacting other teams</span></li>
<li data-list-item-id="e4475330d434922ea9ae19e70b3239bac" style="font-weight: 400;"><span style="font-weight: 400;">Independent and fully customizable Tier 0/self-service and knowledge workflows</span></li>
<li data-list-item-id="eda32f3b4da8e7d615a438d77b291d077" style="font-weight: 400;">
<span style="font-weight: 400;">Fully customizable and tailored end user experience per team (p</span><span style="font-weight: 400;">roper end user experience for agents who are end users for other teams)</span>
</li>
<li data-list-item-id="e2d442fc04b317e0bcaa95cd05f386f79" style="font-weight: 400;"><span style="font-weight: 400;">Control by team over ticket access and security</span></li>
</ul>
<p><span style="font-weight: 400;">Items to consider are:</span></p>
<ul>
<li data-list-item-id="e1956027e5d21fe7bd4b3d60e4d1fcca6" style="font-weight: 400;"><span style="font-weight: 400;">Overhead cost for configuration and analytics for multiple instances</span></li>
<li data-list-item-id="e950eb5906a84063f271aa5e7a2041aa6" style="font-weight: 400;"><span style="font-weight: 400;">Configuration of SSO, apps, and integrations required for all instances</span></li>
<li data-list-item-id="e7e073a439b363ac1bc08696ced679a6b" style="font-weight: 400;"><span style="font-weight: 400;">End users need to go to different places for submitting requests or self-service</span></li>
<li data-list-item-id="e9536f6c3d2276cfbefc4f960a7e3ebfd" style="font-weight: 400;"><span style="font-weight: 400;">Agent collaboration complexity increases due to having to use ticket sharing between Support instances</span></li>
<li data-list-item-id="e02353aa012589a8985f778cdc95b8abd" style="font-weight: 400;"><span style="font-weight: 400;">The agent collision feature does not work between two Support instances</span></li>
<li class="wysiwyg-list-color" data-list-item-id="ed019b6aa8f1105c8ac30df481b226659" style="font-weight: 400; --wysiwyg-list-marker-color: #000000;"><span style="color: #000000;"><span style="font-weight: 400;">While Ticket Sharing can allow two teams both using Zendesk to collaborate, the ticket updates would be asynchronous from the ticket of one Support instance to the other</span></span></li>
<li class="wysiwyg-list-color" data-list-item-id="e9eb147f3b25966baec40fd85efb21b65" style="font-weight: 400; --wysiwyg-list-marker-color: #000000;"><span style="color: #000000;"><span style="font-weight: 400;">On certain plan types, controlling ticket access and security by team can be accomplished in a single instance by creating private ticket groups</span></span></li>
</ul>
</div>
</div><script id="docs-schema-markup" type="application/ld+json">{
"@context": "https://schema.org",
"@type": "TechArticle",
"@id": "https://support.zendesk.com/hc/en-us/articles/4408883091994",
"url": "https://support.zendesk.com/hc/en-us/articles/4408883091994-Considering-one-or-multiple-Zendesk-instances",
"headline": "Considering one or multiple Zendesk instances",
"description": "You can evaluate the benefits and challenges of using one or multiple support instances to determine the best configuration for managing teams, workflows, and user access in your organization.",
"articleSection": "Zendesk basics",
"datePublished": "2021-10-16T16:26:49+00:00",
"dateModified": "2026-03-05T23:46:51+00:00",
"inLanguage": "en-US",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://support.zendesk.com/hc/en-us/articles/4408883091994"
},
"author": {
"@type": "Organization",
"name": "Zendesk",
"@id": "https://www.zendesk.com"
},
"publisher": {
"@type": "Organization",
"name": "Zendesk",
"@id": "https://www.zendesk.com"
},
"isPartOf": {
"@type": "WebSite",
"name": "Zendesk Help",
"@id": "https://support.zendesk.com/hc/"
},
"about": {
"@type": "SoftwareApplication",
"name": "Zendesk",
"@id": "https://www.zendesk.com",
"softwareAddOn": {
"@type": "SoftwareApplication",
"name": "Copilot",
"@id": "https://support.zendesk.com/hc/en-us/sections/4405303717658"
}
}
}</script>