Multibrand - Display the appropriate forms on the correct Help Center (Enterprise)

Note: Support Enterprise includes up to five brands. Support Enterprise with the Multibrand add-on includes up to 300 brands.

This workaround is only necessary in select scenarios like if you want to use a form for Web Widget, but not in Help Center. Please reference Creating and applying branded ticket forms to find out how to selectively display different forms for different brands.

I've created multiple Help Centers for all of my brands, and now I'm ready to roll out ticket forms for each of the brands. But wait! I don't want my forms for my primary brand to show up on my Help Center for my secondary brand. Well this little trick is hopefully just the thing to fix that.

Click the name of the form you want to hide or use as your standalone form

Take note of the form ID in the address bar as shown below:

Repeat for each form you would like to hide or isolate.

Displaying multiple forms per brand

Often times each Help Center will manage multiple types of requests. This section will show you how to selectively hide any ticket forms you do not want to appear in a particular brand's Help Center, while still enabling the end-user to select the remaining forms.

The code

Now that we have recorded the ticket forms that we want to hide as described above , we can now target them with the code below.

You will want to place one of these versions of code in the
$(document).ready(function(){
in the script.js template when customizing your Help Center.

Note: When you copy and paste the code, make sure to enter in your own form IDs, not the ones given in this example.

Option 1

In this first option, you simply repeat the lines where the form IDs are located. My form IDs are
12775
and
31495
.

//remove the options from the dropdown selector
$('#request_issue_type_select option[value="12775"]').remove();
$('#request_issue_type_select option[value="31495"]').remove();
//remove the options from the nesty-input after it's been created.
$('.nesty-panel').on('DOMNodeInserted', function(e){
$(this).children('ul').children().remove('#12775');
$(this).children('ul').children().remove('#31495');
});

Option 2

Now in this 2nd option, I've instead decided to use an array, so we can simply input the list of forms we want to hide inside of the square brackets
[ 12775,31495 ]
. You must separate each ID with a comma. This will loop through the function until all IDs have been removed.

Displaying one form per brand

Now you might be saying, "I only need one form for each brand." That's a perfectly acceptable workflow too! Instead of having to hide all of the extra brands, you could change your 'Submit a request' link to send users to one of your forms directly, and then hide the 'Please choose your issue below' dropdown list on the form.

The code

To send your users to one form, you will need your own form ID found in the steps above .

We can easily replace the 'Submit a request' link by using the Help Center templating language Curlybars. You can find some more Curlybars and templating documentation here .

You will want to place this code in the Header template where you want the 'Submit a Request' link to appear (be sure to replace the
ticket_form_id
with your own). This does take localization into consideration, so the link will be offered in the appropriate language if you have multiple languages offered in your Help Center:

Remove form selection dropdown from ticket form

Next, we want to remove the form selection dropdown from the ticket form, so users don't select an alternate form for the current brand. You will want to place this code in the style.css template of your Help Center:

.request_ticket_form_id{
display:none;
}

Enter the CSS in the style.css template.

How it Works

When the new request page is generated, all end-user facing ticket forms are made available in the dropdown list. The first example removes the form options which you do not want to appear for each specified brand and the second example simply directs users to one specific form for your brand.

23 Comments

This works great but I have found that there is still one problem with the drop down. Thanks to this article, my Brands only shows the ticket forms that are relevant. However, when a customer is asked which form they want to use, they see "Please choose your COMPANY product below". That COMPANY field is the same for all brands, i.e. what seems to be the default brand name.

The text you are referencing is actually set on your Ticket Forms panel under Admin > Manage > Ticket Forms. You'll find a box on the right side where you can enter instructions when multiple forms are available. You may want to enter something more general in the box that doesn't identify the company. Maybe just "Please choose your product below."

I've gotten some feedback from some people that the code above is not removing form options in some situations. I'm still investigating the scope of this issue, but in the meantime, you can make the following updates:

You will want to remove the lines I have highlighted with the red boxes and change the remaining .one to .on like this:

//remove the options from the dropdown selector
$('#request_issue_type_select option[value="12775"]').remove();
$('#request_issue_type_select option[value="31495"]').remove();
//remove the options from the nesty-input after it's been created.
$('.nesty-panel').on('DOMNodeInserted', function(e){
$(this).children('ul').children().remove('#12775');
$(this).children('ul').children().remove('#31495');
});

@Hampus if you are using the default mobile template on your Help Center, this code will not work as the CSS and Javascript for your desktop site will not operate in the mobile template. If you would like to get a head start on making your Help Center responsive, you can have a look at this article.

Please know that making Help Center responsive is something that is on our radar, but I don't have an ETA at the moment..

The default mobile template cannot be manipulated in this manner. You could certainly disable the default mobile template and make your Help Center responsive. We discuss creating a mobile layout in this article which can hopefully get you started.

This works, except when a user, while on the form page, goes to login.. the result is the page refreshes to the default "/hc/en-us/requests/new", which.. if you've eliminated the drop-down, just show a blank page.

I updated the article with the code mentioned in my comment above, and we added a Curlybars friendly method on how to change your 'Submit a request' link if you only want to show one form.

@Ben -

Thanks for bringing this up! I hadn't come across that scenario in my testing.

There are a couple of ways you could approach this. You could leave the dropdown on the request page, but remove the other form options like what is shown in the first example above. Alternatively, you could use a small piece of Javascript to redirect anyone who ends up at the /requests/new page like this:

Hi Jake, This is great! It allows me to have a subtle "report a site issue" form in my company's footer, but not have it appear among our important ticket forms in the "submit a request" dropdown.

I'm having a small issue though. When I use your code from Option 1 above, the forms that I hide aren't given the correct 'Ticket Form' option in the agent interface 'Views'. They're instead appended whatever the default ticket form is in Manage > Ticket Forms.

As an example of my environment, my default active form is nicknamed 'Question,' and appears as the first entry in our submit-a-request dropdown. My hidden form with your code is nicknamed 'Report Site Issue.' I set up a trigger to automatically assign the tickets made via the hidden form to me, with the following condition: [Ticket:form] [Is] [Report Site Issue ]. when I use your code though, the trigger doesn't work because forms submitted by the end-user as 'Report a Site Issue' appear as the default 'Question' in the agent interface.

I don't believe this is a bug. Could you try using .hide in place of the .remove function in the Javascript? When we are using the remove, it's completely wiping out that value, but I feel in your case, it may be worth just hiding it.

with some fiddling it seems to have worked! If both .removes are replaced with .hide, it will cause every item in the nesty-input to disappear. But if I replace only the first .remove with .hide, it works fine:

Correct me if I'm wrong, but as far as I can see these tricks only apply to the user-facing side of ticket forms. Agents who are part of a multi-brand Zendesk are still stuck with a huge list of ticket forms instead of only the ticket forms that apply to the brand they are a part of.
Is there any way to make these tricks work for the agent-facing end of ticket forms?

You are correct, this method will only impact the customer-facing element in Help Center.

There isn't a native functionality in Zendesk that would accomplish the same thing in the agent interface, but it might be possible to do it with a custom app. You can find out more about creating apps here: https://developer.zendesk.com/apps

It's also possible that someone else in the Community has done something similar and may be able to help!

I know that there is now native functionality to selectively show forms in multi-brand situations. I have some forms, though, that I don't want to show in any Help Centre. Specifically, I have forms that are used in web-widgets only and which I don't want to show in the list in the Help Centres.

That would be a legitimate use case here since we don't have the native ability to select between Web Widget and Help Center for a specific form. Feel free to give the code above a try. Hope it works out well for you!

I asked a few folks on our support team, and you should be able to use the functionality outlined in the article to accomplish what you're looking for - just apply the Java Scrpit to each Help Center. Give it a go and let us know if any questions or stumbling blocks show up.

Jake BantzNicole - Community Manager: Similar to Karen I have had to create 2 ticket forms to support the web widget--I want one to display for the help center new request page, and the other one in the web widget. We're set on the web widget, but, the help center new request page (..../hc/en-us/requests/new) displays a drop down "Please choose your issue below" asking the end user to choose between the 2 forms.

Looking at the article it appears I should use the "Displaying one form per brand" steps along with the steps to suppress the drop down...but the Help Center configuration seems to have changed from when this article was written/last updated. The submit a request link is not in the header template as stated in the instructions but in the article template. And, it appears differently now at least for me: it uses the <div class="article-more-questions"> and {{request_callout}} helper.

Can you please clarify the steps now?

We also point to the new request page in the footer but that's a URL so I know I can update that to go to the desired form id :)

The workflow I would suggest would be to use the methods above to remove the unwanted option from the dropdown on the new request page, and then try to route all requests to the specific ticket form you want to be used for the Help Center.

Depending on the theme you are using, the submit a request link could appear in any template. I reviewed a recent version of the Copenhagen (default) theme in my test account, and I do see "{{link 'new_request' class='submit-a-request'}}" in that template. If the request form link has been moved or added elsewhere in your theme, you would want to replace any of those references with a link like I describe below (adding or removing text as you see fit) so that your end-users are directed to the specific form you want them to use.

When interacting with the request callout on the article page, you will want to replace it with something like this (make sure to replace with your ticket form id):

If you need to localize the "Have more questions?" you could implement some dynamic content for that string, but unfortunately the request_callout cannot be be pointed at a specific form, so we have to code this a little more manually like my example here.