Elaine

Hello Ignesh,
 
Thank you for reaching out! Creating a report that captures multiple keywords from the Ticket Summary field can definitely enhance your insights.
 
One way to consolidate the data into a single report is by using tags or custom fields. If you can categorize the tickets based on the keywords you're interested in, you can create a single report that filters by those tags or fields.
 
Another option is to use reporting tools that allow you to create custom queries or dashboards, which could help in visualizing the data according to the keywords you need.
 
I hope this helps! If you have further questions or need specific guidance on setting this up, feel free to ask.

Hello Kyle,
 
Thank you for sharing your detailed experience with the dashboard issue. It sounds frustrating to have the formatting change between the builder and scheduled deliveries.
 
From what you've described, it seems like a spacing issue that might be related to how the dashboard elements are rendered in different contexts. It's great that you've identified a workaround, but I understand it can be quite tedious.
 
Here are a few suggestions that might help streamline your process:
 

1. Check Responsive Settings: Ensure that all dashboard elements are set to be responsive. This may help maintain consistent spacing across different delivery methods.
    
2. Browser Compatibility: Since you've mentioned testing in both Opera and Chrome, consider clearing the cache or trying another browser to see if it impacts the output.
    
3. Feedback to Zendesk: Since you're experiencing this in the Beta version, providing feedback through your Zendesk account could help the team identify and address the issue in future updates.
    
4. Community Input: You might also find it helpful to ask in the community if others have faced similar issues. Sometimes, other users may have found different solutions or workarounds.
    

I hope these suggestions help! If you continue to experience issues, please let us know, and we can assist further.

Hi Irfan,
 
Thank you for your post. It sounds like you're facing a common challenge with Google SSO integration when deploying the Zendesk app via Intune.
 
When users are required to log in using a single corporate Google account, it can indeed cause issues if the app defaults to that account. Here are a few suggestions that might help:
 

1. Change Default Account Settings: You might want to look into the settings in Intune to see if it's possible to allow users to choose which account to log in with upon opening the Zendesk app.
    
2. Account Selection Prompt: Ensure that the login flow is set to prompt users for account selection rather than defaulting to the corporate account. This could require changes in either the Intune deployment settings or the app's configuration.
    
3. Test with Personal Accounts: If feasible, test logging in with personal Google accounts on devices that have the app installed to see if the issue persists. This might give you insights on whether it's an Intune-related configuration or a broader app issue.
    
4. Review Zendesk's SSO Documentation: Check the Zendesk support documentation related to SSO setups, as there may be specific configurations recommended for use with corporate accounts and Intune deployments.
    

If you're still encountering issues, consider reaching out to Zendesk support for further assistance. If someone else has implemented similar changes successfully, it would be great for them to share their experience.
 
Let us know how it goes, and feel free to share any updates!

Hi Shane,
 
It sounds like you're working on a complex setup to manage multiple domains for your customers, and I appreciate the details you've provided.
 
Regarding the 422 unprocessable entity error, it’s likely related to how the placeholder for is being handled. Here are a few suggestions that might help:
 

1. Check Your Placeholder Syntax: Ensure that the placeholder is correctly formatted and that the field exists in the organization’s custom fields. It might be helpful to log the output to see what value is being sent.
    
2. API Endpoint Structure: Verify that the API endpoint structure is correct. It should properly include the organization ID you are targeting. The endpoint should look something like /api/v2/organizations/{organization_id}.
    
3. Testing with Dummy Data: If possible, test the webhook with dummy data specific to your organization to see if the issue persists. This can help to isolate whether the problem lies with the data or with the API call itself.
    
4. Call from Organization Directly: Regarding your question on making direct calls from the organization—yes, you can do that even if there isn’t a preceding user or ticket, provided you have the correct authentication in place.
    

If the error continues after these checks, feel free to share more details, and we can troubleshoot further!

Hi Judy,
 
Thank you for your feedback! You’re absolutely correct—the business hour metric will depend on the specific settings you have configured for your account. If your business operates Monday through Friday and does not provide 24-hour support, weekends will not be included in the calculation since the business hour metric will depend on the business hour you have set on your account.

Hi Alessandro,
 
It looks like you've put in a lot of effort to implement the changes outlined in the article. Here are a few suggestions that might help you troubleshoot the issue:
 

1. Double-Check Form ID and Module ID: Ensure that the form ID and module ID you copied are correct and associated with the right organization.
    
2. Inspect the Script for Errors: Look for any JavaScript errors in the console that may indicate why the dropdown isn't updating.
    
3. Verify Organization Name: Make sure that the organization name you specified in the script matches exactly what’s in the system (case-sensitive).
    
4. Review CSS Selectors: Confirm that the jQuery selectors ($('#request_issue_type_select option[value="' + formID + '"]')) are targeting the right elements on the page.
    
5. Clear Cache: Sometimes changes might not appear due to caching. Clearing your browser cache or checking in an incognito window could help.
    
6. Testing Alternative Users: If possible, test with different user accounts that belong to the new organization to see if the behavior varies.
    

If someone else has implemented similar changes successfully, it would be great for them to share their experience.
 
Let us know how it goes!
 

Hi Matthew,
 
Yes, you can create a custom Help Center page template and insert a form dropdown for a different brand. This allows you to tailor the user experience based on the specific needs of that brand.
 
Use the Liquid markup to insert the dropdown. For a different brand, you may need to reference the specific form using the brand’s ID. The Liquid syntax typically looks like this:

<select name="form">
  {% for form in forms %}
    <option value="{{ form.id }}">{{ form.name }}</option>
  {% endfor %}
</select>

 

Hi Aaron,
 
Thank you for bringing this up! I understand the challenge of managing messages from multiple Instagram and Facebook accounts without clear identification of the source.
 
While the current setup only shows "Instagram direct" or "via Facebook Messenger," we acknowledge the need for more specific indicators.
 
To address this, we recommend exploring the possibility of using tags, custom attributes or fields to capture which specific account the message is coming from. This could provide you with better context when responding to inquiries.

Hi Kaley,
 
Yes, you can filter data in Google Analytics by user organization information that you've set up in Zendesk. To achieve this, you typically need to:
 

1. Integrate Zendesk with Google Analytics: Ensure that your Zendesk is connected to Google Analytics, either through a direct integration or by using GTM (Google Tag Manager).
    
2. Custom Dimensions: Set up custom dimensions in Google Analytics to capture organizational data from Zendesk. You'll need to send this data as part of your tracking implementation.
    
3. Filter Views: Once your data is being sent to Google Analytics, you can create filters or segments based on these custom dimensions to view data specific to different user organizations.
    
4. Reporting: Use the custom reports feature in Google Analytics to analyze the data filtered by user organization.

Hi Matthew,
 
It's great that you’re diving into the new email error feature! Regarding your query on the email error history, there are no specific limitations on how far back the data goes. However, do keep in mind that the API limits results to 100 per page. For more details on pagination, you can check out the Zendesk API documentation.
 
If you have any further questions or discover anything noteworthy during your exploration, please share!