This article is for Support Enterprise customers who are currently using a Hub and Spoke setup to manage multiple brands, and are considering migrating to Multibrand to manage multiple brands.
Prerequisites for migrating to Multibrand
As you are thinking, or even planning, to migrate from Hub & Spoke (H&S) to Multibrand (MB) please review these key roadblocks which will prevent us from fully migrating your account to Multibrand.
Before you read the details, ask yourself if you are really using all of your spokes. We have customers who have set up Hub & Spoke but are only using the Hub. If your Spokes are not being used, or the Spokes are not sharing tickets with the Hub, then it is likely that you do not need a migration.
- Help Center communities You can migrate your community content using the Help Center API. For more information, see Topics and Posts in our developer documentation.
- Multibrand or Hub & Spoke A Multibrand instance cannot exist within a H&S setup. These products are mutually exclusive.
If you are comfortable with all the above, and you want to know more about the multibrand migration, start with the article Steps for Multibrand migration.
Comparing Hub and Spoke to Multibrand
This section outlines the change in behavior a Hub & Spoke (H&S) might encounter after migrating to Multibrand. We have plans to change of the Multibrand behavior for some of the items below but we do not have a specific timeline on those yet.
- Remote Authentication/Single SignOn Each Help Center redirects users to the same Single Sign On protocol and database. This is a side effect of the fact that users are per account, not per brand.
-
Zopim channel branding Tickets created through Zopim are not currently aware of the brand attribute. Again, we intend to correct that in the future. In the meantime, improve the Zopim multibrand setup implementing a subset of the suggestions
- Agent signaturesThere is only one signature per agent. Agents can leverage personal macros to create an agent signature for each brand.
-
End user brand identities There is currently no way to segment end-users for customer lists based on brand identity because we do not track which of your users has interacted with which of your brands.
- Agent permissions All agents have access to all brands by default. You can create brand views for agents to use. If restriction is required, use triggers to assign brand tickets to groups and restrict agent permissions to tickets in those groups.
-
End User permissions You cannot hide certain Help Centers to a subset of your end users. This is by design, but we’re working on a way to support segmented and privileged service based on user type. However, it is possible to prevent access to content, user portal, and communities by using Zendesk user tags and javascripts.
-
Single email templatesAt launch you will be limited to one html template per account. We plan to update this in the future, but for now you can create a shared HTML template and use macros to brand the text of their responses
- Ticket formsYou can restrict access to specific ticket forms by brand (see Creating and applying branded ticket forms). This allows you to control the ticket forms available to end-users and agents based on the brand of the Help Center or ticket they're viewing.
-
Integrations We are working to make sure that the brand value translates over in our major integrations, including JIRA and SFDC. All other apps will need to be updated by their owners.
- Password reset If an end-user requests a password reset from one brand portal, they will reset the password for all brands simultaneously. The password reset email isn’t customizable, but it will list all associated Help Centers so the end user is aware where their password was updated.
Understanding the steps and limitations of the migration
Here are the key elements of the Multibrand migration:
-
Steps and timeline
-
Limitations
Typical steps and timeline
- You will configure your MB instance (“Setting”, “Channels”, “Brands”, Agent roles...).
- Zendesk migrates a sample of the content (tickets and HC articles).
- You will verify that the sample content was migrated as expected..
- Zendesk will complete the migration of content except for tickets less than closed (i.e. tickets which are in "flight").
- You will configure your workflow in your MB instance (macros, triggers, automations, and views).
- You will preparation for the final step of migrating by communicating with your customers about the upcoming downtime (messages on the spokes' Help Center and potentially a warning email).
- Execute the downtime tasks: Zendesk to migrate the remaining tickets and you will switch subdomains (from Spoke to Multibrand) and set host mapping for each brand.
In terms of timeline, this effort is bounded by the Zendesk resources in place for this process, migration complexity of your program, and your responsiveness in completing your tasks. Only after gathering your migration requirements will we be able to tell you what is the expected completion date for your migration.
- Tickets
- We migrate all comments, attachments, and metadata (i.e. the current value of every ticket field and tags)
- We cannot migrate the events (i.e. tag "xyz" was added by trigger 123 on Dec.12, 2014)
- Ticket # ID cannot be migrated as new tickets are created in the Multibrand instance.
- Help Center content
- We migrate articles (and attachments). Every article will have the same author after the migration (the account owner or a person you designate).
- Article creation date, comments, and subscription are not available. So it is for Section's settings and Communities content.
- Templates cannot be migrated (i.e customization made to your Help Center)
- Category or Section settings cannot be migrated. You need to reset them after the migration.
- Category, Section and Article # IDs will change upon migration. Any previous external links will need to be updated.
- User information
- End-user, agents, groups, and organization can be migrated (it does not include custom fields, user notes and details on the above information)
- End-user passwords cannot be migrated. So if your customers are logging into Zendesk directly (i.e. has an authentication profile with Zendesk), then your customers will need to reset their password once after the migration is completed.
- Agent roles is not migrated.
- Org, lang, time zone, Details + Notes, and custom fields on the profiles are not migrated.
- Workflow
- Macros can be migrated
-
We cannot migrate your views, triggers, and automations (would not make much sense you need to review all of those and adjust them for the new brand you have created.
-
Dynamic content is not available for migration
- Other
- Satisfaction ratings: not available
- Migration of "Settings" and "Channels" are not available (and it would not make much sense given the additional brands.
- Bookmarks to specific articles will send user to branded Help Center homepage (not to the equivalent article in the new branded Help Center)
- We are working to make sure that the brand value translates over in our major integrations, including Jira and SFDC. All other apps will need to be updated by their owners.