Wittconsulting21

While I like the new custom fields list, it is not usable for us as 1) we have multiple brands/forms and 2) each client has a conditional field for projects many of which are agent-only. This creates hundreds of options, most of which are irrelevant and will confuse the end user. 

I stayed with the custom development mentioned (requests ajax call code for a specific field) here and was able to get it to work. Here are some roadblocks as I believe the code was written originally for API version 1.

1) To use $.ajax you need to include a Jquery library, which can be any CDN that has it. The Zendesk article which states to use the code.jquery.com and integrity didn’t work for me, so I used the google CDN. Add the latest script to your document head or similar page https://developers.google.com/speed/libraries#jquery. 

2) The URL in your ajax code must match the URL of your help center or you will get CORS issues. In other words, if your zendesk base is company.zendesk.com and your helpcenter is helpcenter.company.com (domain mapping), then your ajax call must be the latter (this is more relevant with multibrand). I am not sure if cache and process data are needed, but this is all I send in the request.

dataType: 'json',
type: 'GET',
cache: false,
data: '',
processData: false,

3) While the tickets API call has more data, it requires an agent/admin login (your end users won’t be able to see it otherwise) and if you include the authentication information a hacker can easily get your information. The requests API call is allowed for end users (no authentication), but it only has access to custom fields that are on the form used, not every field that is customer visible even if not on the form. Also, the API has changed and fields is no longer an option (I used custom_fields) so the code to process must change to custom_fields.

4) Finally, the most frustrating part is that the Zendesk request object does not have organization even though the filter has access to it, and the requests API call only returns organization id (not name). Calling the organizations API to get the name from id requires agent/admin authentication as above and the search API doesn’t do this lookup. The helpcenter object has the user organization (not ticket) but is only available in the script.js file. For fields not available in the requests api, a workaround is to create a custom field on the form and use a trigger (on New or Updates) to call the tickets API (webhook) to move the field you want into this customer visible field. Of course it requires some delicacy since the customer can see it, but you can then use it in the requests grid.

I mentioned this in my ticket that I raised. It used to be that they made the HelpCenter object available in all templates, but now it's only available in the script.js. If you view-source you can see the code at the bottom of each page where they update the HelpCenter object and mention not to use that object as it can always be removed. The userid is available in the HelpCenter object as well as the user's organization id, but you can only access it in the script.js file.

@... An easy solution, assuming not memory/CPU intensive, is to ensure the user object is available in all templates.  

Hello Nadine,

I had the same issue. It used to be that you could access the HelpCenter object on any of the templates, but now it is only accessible via the script.js file. That object has a user field which lists organizations and tags - you can see it in the JS console window by typing HelpCenter. The problem is I haven't found a way to pass data from the .js file to any of the templates, but you can mask certain fields in the templates. In my case I blocked the ability to submit a ticket if the end user is not part of company, meaning I can have internal users submit tickets through Guide without being agents. In the future when we open the helpcenter to everyone I blocked specific ticket forms for internal and external users. This comments in this document provided the best help for me get this to work, and in one of the examples they searched Organization tags (I assume you'd need to div where the product is selected): https://support.zendesk.com/hc/en-us/articles/4408886229146-How-can-I-hide-ticket-forms-based-on-a-user-s-organization-?page=1#comments.

My code, where xxx is the Organization name:

document.addEventListener('DOMContentLoaded', function() {

// This line of code ensures it's only in the ticketing template, otherwise it will fail to obtain the parameters below and block MyProfile from working.

if(document.querySelector("a.nesty-input")){ 

//This code currently blocks non-xxx users from submitting tickets
if (HelpCenter.user.organizations[0].name !== "xxx"){
  document.querySelector('.nav-wrapper-desktop').style.display = "block";
  document.querySelector('.nav-wrapper-desktop').style.visibility = "hidden";
  
  // Once end users are allowed to view the HelpCenter, we should block internal forms (code already here).
  // If additional forms are added and external, they should be added here.
  document.querySelector('#request_issue_type_select option[value="6037656308123"]').remove();
  
  document.querySelector('.nesty-panel').addEventListener('DOMNodeInserted', function(event) {
  event.target.querySelector('li[id="6037656308123"]').remove();})
  
} else {
  // This code blocks the client facing form for xxx employees. 
  document.querySelector('#request_issue_type_select option[value="6037733904923"]').remove();
  
  document.querySelector('.nesty-panel').addEventListener('DOMNodeInserted', function(event) {
  event.target.querySelector('li[id="6037733904923"]').remove();})
 } 
 }