Recent searches
No recent searches

Eric Ypsilantis
Joined Apr 14, 2021
·
Last activity Oct 27, 2021
Following
0
Followers
0
Total activity
22
Votes
2
Subscriptions
12
ACTIVITY OVERVIEW
BADGES
ARTICLES
POSTS
COMMUNITY COMMENTS
ARTICLE COMMENTS
ACTIVITY OVERVIEW
Latest activity by Eric Ypsilantis
Eric Ypsilantis created an article,
Question
I want to modify the native behavior of the Web Widget (Classic) using Javascript APIs. I read through the Help Center and I found many different implementations. How can I combine these different Web Widget (Classic) API workflows?
Answer
The most important thing to be aware of is when you want to have your widget settings applied. Some workflows need to be run whenever a department is updated, while others need to be run when the widget first connects or reconnects. This is illustrated with this simplified example of setting the CRM department:
There's a couple of things in the above script worth discussing. First, the initial steps of hiding the widget and then showing it when an unread message is received could be omitted completely without changing the rest of the script's functionality. Given that they are being used as soon as the widget is loaded, they were placed at the top of the script. This is not strictly necessary.
Next, it is worth noting that while some custom workflows place a updateSettings API block in a chat:connected callback, you are also able to put this in a chat:departmentStatus, and it will also be applied when the widget first connects (or reconnects after a timed-out session). For this reason, use the chat:connected
API specifically for commands you only wish to fire once, and the chat:departmentStatus
API for commands you want to fire anytime the specified department changes after the page loads.
For more information on different Web Widget (Classic) API workflows, see these articles:
Edited Dec 14, 2022 · Eric Ypsilantis
1
Follower
4
Votes
0
Comments
Eric Ypsilantis created an article,
Question
The routing workflow using triggers described in the article Automatically route chats to departments does not take into account a specific department’s online status. Is it possible to show the Web Widget as online for Chat on my webpage only if a certain department is online?
Answer
It is not natively possible to display the widget when specific departments are online, but you can create a custom script with the use of Zendesk API. With a custom script, you can configure the Web Widget (Classic) to present Chat only when a specific department is online. The script will identify a change in the account’s department status and the API will update the settings for the Web Widget (Classic) as desired based on the current department status.
Below is an example API script that uses this method. This example shows the Web Widget as online for Chat only when the CRM department is online. If the department's CRM status is not online, Chat is suppressed. When Chat has been suppressed only other enabled features of the Web Widget (Classic) are shown to the visitor. For example, the contact form or help center search.
Edited Nov 21, 2022 · Eric Ypsilantis
7
Followers
16
Votes
24
Comments
Eric Ypsilantis created an article,
Question
When a chat session is timed out, and the visitor requests a new chat, the new chat request does not retain the department assigned from the previous session. Is there a way to reapply the department assigned from the previous chat?
Answer
It is expected behavior for a new chat session to not reapply the department automatically after a visitor timeout. As a workaround, use the on chat:connected API callback to identify the reconnection event and update the user settings with updateSettings API to set the department for the new chat session.
The API is applied when the reconnect event occurs after a visitor time out but before the new message is sent by the visitor. This ensures the department gets assigned to the new session.
Below is an example API script that uses these methods to reapply the Shopping Cart department whenever a visitor first connects or reconnects from a timed-out session.
Edited Jan 22, 2024 · Eric Ypsilantis
0
Followers
6
Votes
5
Comments
Eric Ypsilantis created an article,
Question
When a visitor's chat connection times out but they do not close the window or tab that the widget is loaded in, then later reconnect to send a new message, the pre-chat form isn't automatically presented to them. Is there a way to require a visitor to always see the pre-chat form in the Web Widget when they reconnect after a timeout?
Answer
By default, a visitor skips the pre-chat form when they reconnect. Force the pre-chat form to appear by applying the script below, before the existing Web Widget (Classic) script:
Test your workflow. If needed, apply or reapply widget settings by adding the below script after the script you added:
This final step uses the updateSettings API to apply or reapply the settings for the widget. In the above example, the Shopping Cart
department is applied when the widget first connects or is reconnected. This workflow is discussed in more detail in the related article: Can I reapply the department after a timed-out chat visitor reconnects?
Validate that you correctly configured this solution. Check the current state of the widget when it connects. Then close, reset, and reopen the widget to ensure the pre-chat form always shows to a reconnecting visitor.
Edited Apr 24, 2024 · Eric Ypsilantis
1
Follower
4
Votes
5
Comments
Eric Ypsilantis created an article,
Question
If a visitor loads the Web Widget (Classic) before operating hours end, they are able to chat in after all our agents have just gone offline for the day. As a result, they create a missed chat instead of an offline message. Is there a way to ensure the widget will not allow a chat to be requested for a department that is currently offline?
Answer
The native widget behavior is to not be updated in real-time as a specific department goes offline after it was loaded on a page. However, you can force the widget to update whenever this occurs and the visitor isn't already in an active session using the API.
Whenever the chat department has a status update, verify the new status is Offline and then check if the visitor is already in an active session. If the agent's status is Offline and the visitor is not in an active session, then use the updateSettings method to suppress chat.
See the below example that checks if the CRM department is online.
Edited Nov 18, 2022 · Eric Ypsilantis
2
Followers
5
Votes
0
Comments
Eric Ypsilantis commented,
Hi CJ, the script in this article is specifically for setting (and setting again if needed) a single specified department.
Unfortunately there isn't an API to get the prior session's department, which would be required to know which of these 5 departments to use again upon reconnection.
View comment · Posted Aug 11, 2021 · Eric Ypsilantis
0
Followers
0
Votes
0
Comments
Eric Ypsilantis commented,
Hi CJ, I would expect to see this "Uncaught ReferenceError: zE is not defined" error if the script in this article is being used without your account-specific widget snippet being in your code first.
Try adding the widget snippet from your account (on the Channels > Widget page in Support) above the script using the widget APIs - your Web Widget will need to be loaded before these zE APIs would work.
Hope this helps!
View comment · Posted Aug 11, 2021 · Eric Ypsilantis
0
Followers
0
Votes
0
Comments
Eric Ypsilantis commented,
I'm glad to hear you find the article helpful, @...! You know, I had been asked this before back when I was less dangerous with JavaScript, and didn't think it would be possible given how I'm using the API - but let me ponder this and I'll get back to you here. Is the idea to only show the widget as online if a subset of the departments is online, but then not set the department to use in the widget automatically (let the user choose)?
View comment · Posted Jun 25, 2021 · Eric Ypsilantis
0
Followers
0
Votes
0
Comments