Fortunately, this is not a definitive goodbye to the idea, because – as it is rather frequent with ServiceNow – a replacement configuration was provided, called Sidebar. It must be said that while the new features are welcome, the migrating part of the process used to cause several headscratchers each time it had to be performed.
This article was created to help smoothen out the edges of tool replacing, and serve as a small compendium of issues that one might encounter. It might also serve as a small sneak peek into the feature, as it can be said right out from the start that it is one of the best implemented revisions ServiceNow had made recently.
As soon as we have learned of upcoming retirement of Connect Chat, The Cloud People was tasked with the below story description by a customer that had focused its sight on adopting Tokyo as soon as possible, owing to the upcoming fixes of the Next UI/Polaris interface and other heavily-awaited features incoming:
“I was informed by ServiceNow that Connect Chat is being dropped in Tokyo. This is a core feature for us, and we need to establish a replacement.”
Acceptance criteria that followed were a bit tricky to decipher initially:
“Verify and deliver configuration that allows us to replace previous setup with no loss of continuity to current work”.
What was further discussed with the requester reassured us that the continuity did not mean migration of open discussions to the new tool, but rather avoiding the situation where resolver teams would be left without a working feature. “Remember to always ask a customer for clarifications” sounds like a cliché, but it always helps, take our word for it if you will.
The Tokyo upgrade of the PROD environment was said to be halted until the solution is discovered, presented and delivered to lower instances. The feature should also be available specifically within CSM/FSM Configurable Workspace, which that customer was putting a priority to. As you will see, this was predicted by the vendor and easy to set up.
As a preface – all of the setup was performed on Tokyo Patch 1 instances, and later retested under Tokyo Patch 4. One thing that must be mentioned is – starting from the Utah release, the “Omni-Experience Standard Feature Set” application will be trued up and installed out of the box. This is stated straight in the FAQ provided for the new tool.
The provided document was an immense help overall, however the customer has admitted that attempts to adhere to it resulted in failure. While we are not certain that this was due to legacy configuration, or was it early adopter’s curse after all, the procedure left us with enough material to actually convert them into an article expanding on the nuances of the migration.
The main plugins that had to be installed in our case are as below, in that actual order:
1. Admin Center (sn_ace) – installed from Plugins module, but required latest version to be get first via ServiceNow Store
2. Collaborative Chat Server – com.glide.cs.collab – contained by the plugin in step 3, listed out for clarification below
3. Omni-Experience Standard Feature Set (sn_oe_sfs) – first requested from ServiceNow Store, then installed from Plugins module (for legacy instances, new implementations should see the plugin straight away, see point 7)
Please note that “com.glide.cs.collab” plugin will show as “Paid” in the Plugin store on your instance. This does not mean automatically that it will provide additional cost to your target instances, since the “Paid” distinction exists also to separate completely free plugins from those that are bound to larger packages. This initially confused the customer as to why in the world would they lose a core business feature and have to pay for a replacement.
The reason why it says that it is subscription based, is due to the fact that in order to use CSM (standard) features, you have to have a CSM subscription. These elements are seen as optional components by ServiceNow, and as such do not come in the core package to avoid platform overload.
The installation process required obtaining the plugin version higher than available in the Plugin module for sn_ace, which might or might not be the same for your target customer instance. It appears to vary based on the version you will upgrade from and the version you will target. As always, the suggested approach is to first make use of sub-prod instances in order to verify the steps to reproduce. While unlikely to be corrupted or broken, in the worst case scenario the cloneback operation from the PROD instance would remove plugins installed to DEV/TEST environments as part of the wipe. Depending on when the last cloneback was performed, and varying on the instance’s level of complexity, a helping hand might be extended from Now Support as well.
Worth noting is the fact that quite unexpectedly, unless you select to load the demo data in the Omni-Experience Standard Feature Set, the solution is not completely ready to be used without Particular elements such as UX Form Action Layout for “Discuss” button are stored within demo data, and while the documentation states that, it would be easy to omit, causing confusion to the overall delivery. For distinction in the configuration, please note that “Discuss” is the label, the UX Form Action is called “Open collab chat” while declarative action is called “Open create collab chat modal”. UX Form Actions are just a little more complicated than old UI Actions. If there is one thing we would like the readers to take away from this article, it is to remember to load the demo data.
As a side note stated within FAQ, unfortunately there is no way of migrating existing chats by converting them into Sidebar discussions. Customers are required to create a cut-off date, which most definitely will coincide with moving their respective PROD instances into Tokyo release. A small reminder here – unless specifically desired, one should avoid going all in on the first iteration of a new release. The tool became simply too big to ensure everything will work smoothly for every customer with varying legacy configurations, which is why ideally our recommendation for upgrade is – wait for at least Patch 4 of particular release to become available for you. Still, that was not the case in the described scenario, as the customer accepted the risk of potential issues, due to confirmed problem resolution for unrelated Agent Workspace issues, resolution featured within baseline Tokyo update.
Also worthy of note is the fact that the installation process does not force the latest version of that plugin, however, so if for example you would forget to load the demo data on TEST or PROD environment, instead of moving the missing configuration from DEV, you could save yourself by updating the plugin, as the update process also allows to load the demo data. We inquired ServiceNow about why the latest available version is not the one selected by default, receiving below response:
”Due to the amount of variables involved with integrations, we do not automatically upgrade all plugins with instance upgrades. These variables can include Custom Applications where a base version of a plugin is selected for the Custom application and testing would need to be involved before upgrading the plugin. This is just one example. In order to limit issues of upgrading a plugin within ServiceNow's is highly customizable, it is suggested that installed plugins are tested in sub-prod on the newly upgraded instance before migrating to production.”
Admittedly, the state of out-of-the-box integration straight after implementation was satisfying to an extent we have rarely seen - we would like to give a big applause to the ServiceNow team for this. To tell the truth, we were surprised how well-thought, good-looking and consumer-friendly the solution is after completing the installation, things were just ready for use with no need for further amendments. Granted, this would take much longer if we were to rebuild “Discuss” UX action had “Load demo data” not been used, but if you are reading this article point by point, by now you should have easily avoided this prime example of early adopter’s curse. The Sidebar FAQ contains screenshots of the tool at work, but we would like to also point out a few things not mentioned there, which we hope would convince you to implement the feature in your resolver teams’ daily workflow routines.
To start off, one must notice how good the Next UI Experience encapsulates the “command center” feel of the platform. The Sidebar discussion icon is included in the top navbar frame, which is much easier to stay within now – no need for plugins such as ServiceNow Framerizer anymore. The discussions module follows the theme branding seamlessly and can be pinned like Connect Chat previously, which we deem praiseworthy. The other side of the coin, which is Sidebar not being available in the previous “Core UI”, must be mentioned as a limitation of sorts, but at this point we understand this pre-requirement, given the framework behind it was remodeled significantly.
Fig. 1
One of the greatest time-saving features provided by the Sidebar is that every member of the assignment group selected in the ticket is automatically added to the list of the participants. These are optional, and you can remove unwanted attendees by the X icon, which is always faster than typing out the first name or last name of the desired person into a search bar or slushbucket.
Please note that due to data protection policies we have removed last names of the participants, which is why the text bubbles look unusually long.
Moving forward, the customer noticed that while the tool works without a hitch, he does not seem to receive activity log updates about started chats, even when they were shown to him by the sales representative at the previous meeting. A quick peek into the documentation helped us understand that due to previous customization of the target glide.ui.sn_customerservice_case_activity.fields property resulted in a skipped update that would assign out-of-the box fields available in the activity log. What was specifically missing and had to be manually readded, were two values:
- *Sidebar discussion*,
- *Sidebar posted message*
Adding them, along with the asterisks, resulted in the customer confirming he was now satisfied with the end result, as the activity log started showing discussions that occurred in the ticket. This feature is reserved to Workspaces and does not occur in the “backend” side of ServiceNow, even if “Workspace” view is selected.
Fig. 2
This is a preview of an example of “Sidebar discussion” type of activity, visible within the “Compose” section of Agent Workspace. It can be shown or hidden per user preference using the “Post types” dropdown menu.
Please note that all participants have user IDs starting with the ISO code for their country, which is “no”, making it somewhat confusing in that particular screenshot, but this is not a rendering issue after all.
Please remember that the “activity.fields” property is table-based, so each table you will want to utilize Sidebar on will require such an amendment to its property. We specifically mentioned the property used in CSM/FSM Configurable Workspace, but Service Operations Workspace would most likely result in (separate) additions to tables like for example “incident”, “change_request” or “sc_req_item”.
Another immensely satisfying and helpful feature is the power to assign particular messages directly into the activity stream, in a “pinning” way of sorts. Below screenshot will present and elaborate upon the subject.
Fig. 3
Here you can see that a picture has been copy-pasted into the chat – another useful quality – which was then added as a Sidebar posted message using the “Post to activity stream” option. This operation can be easily reversed, which is why we seem it more akin to pinning rather than posting.
Expanding upon the previous screenshot, here the post types and predefined filter sets for rendered activities are visible, further helping customize user experience for browsing history log of the case. All in all, this feature is a nifty little helper that keeps surprising us with the level of detail that was put into it. At the risk of repeating ourselves, please do not hesitate to read through the Sidebar FAQ, as further customization is also possible and available at hand, for example Quick Actions.
One additional “hack” of sorts that we would like to present, regards the attachments. On the above screenshot you can see that a PNG file was uploaded to the conversation. The only option under the ellipsis icon is “Download”, but not everybody wants that. Unfortunately, there is no direct way of simply opening the image in the same or new tab, but what can be done to circumvent this, is to right-click the small image in the conversation window, and select “Open in new tab”. True, you will receive an unreadable thumbnail of the picture, but quick inspection of the URL shows that this is all achieved via an additional parameter:
https://customerinstancedev.service-now.com/f19089a99714e1103f7ee2bfe153af30.iix?t=small
So by simply removing the part in bold, you are presented with the full-size image. You can even leave the question mark in the URL. If only a quick peek is needed, and you do not want to pollute your hard drive, this seems like a reasonable approach. Of course ideally, this action should be available as an onClick event out of the box, and links pasted in the chat should become clickable. We hope that these features will become available in the future releases. Please expect an update to this article come Utah release.
And lastly, while not exactly a limitation, we found it a bit confusing and counterproductive that searching for “Sidebar” in the Plugin repository module yields only one result: “servicenow-now-contextual-sidebar”. Installing it predictably does not complete the procedure, as we did not even mention this plugin in the above installation list.
While this mishap should not discourage persistent administrators from implementing the feature (as the next obvious step would be to turn to the documentation for hints), it feels fairly counterintuitive to keep the Sidebar name outside of the title of “Omni-Experience Standard Feature Set”. It is either that, or search in the Plugins module should return results from short descriptions of the plugins as well, specifically as there is no additional configuration for search sources. Perhaps raising a suggestion via Idea Portal would help…
Assuming that the question above would mean an interactive demo, and not just screenshots, which are provided both here and within Sidebar FAQ, or even within baseline documentation, there are other options. Admittedly, the plugins can be installed on the personal development instances, but attempting replication of the steps from customer instance I reached a dead end, as on PDI I found it impossible to use Discuss UX Action from Service Operations Workspace, as even though I could see Declarative Action installed to the platform, targeting “task” table, the button did not show up for task table or any of children tables in Service Operations Workspace. Fortunately, the answer was found within Product Documentation, although it seems counterintuitive in the first place. The culprit, as it turned out, was the selected type of the Workspace selected on the PDI – what we found out in the manual, we state below:
“You do not need to add the Discuss button to these workspaces because it is automatically installed:
As you can see, the Service Operations Workspace is missing from the list, even though from our experience it would be the one that is most frequently requested by the customers as the replacement to previous Legacy Workspace used within ITSM subscription, so it would make every sense to include it for this type of Workspace as well. Had I selected CSM/FSM Configurable Workspace to mirror customer instance installation at 1:1 ratio, the issue would have not been encountered. But we still count this as an inconsistency issue, which we feel came from time constraints and push to deliver a “migratable” tool come Tokyo release. To remedy this, however, we kindly forward instruction steps that are necessary at the moment to make the button visible and available within that particular Workspace.
We really hope that come future release, this action, albeit not very time-consuming, will be integrated within the installation process, making it even more seamless. We also vouch to revise this article come Utah release to check and provide any addendums necessary. One can only assume that new implementations will have it easier than legacy configurations trying to migrate, but some rough edges are definitely expected to be smoothed out around the process.
Sidebar rightfully deserves the moniker of “more advanced than Connect”. While not everybody might like the policy of replacing one module with the other, that ServiceNow is very keen on enforcing, the end justifies the means at least in the aforementioned case. Sometimes it is the core framework limitation that binds the progress, and it is better to get a fresh start, if benefits add up. The modularity is after all why we all love this platform.
We are happy to confirm that this specific migration went smoother than expected, needed little adjustments, yielded great feedback, and resulted in a happy customer, which is also something we all love. The scope of enhancements is immense and obviously the above does not cover all usage scenarios. We hope that this article helped shedding some light on the quirks and features of this – in our opinion – soon-to-be mandatory addendum to the ServiceNow resolver portfolio.
Another feature worth mentioning from the same category is Microsoft Teams integration spoke, which allows for discussions within an external tool, that we hope needs no introduction. Suffice to say, The Cloud People spearheaded the implementation of the plugin for the same customer as soon as it was released, receiving high praise from the process. If you would like to read the article documenting the implementation, do not hesitate to find it here on this very blog.
Again, please remember that this is a relatively fresh position in the ServiceNOW application portfolio. Should any breakthrough update occur in the near future, this article will be updated accordingly. Nevertheless, positive customer feedback tells us that is pretty much a must if you plan on enabling – or continuing with – a more interactive approach between your end users and resolvers. Should you wish The Cloud People to implement this feature for you, or preview the working demo, or perhaps the Teams integration mentioned above, please do not hesitate to contact us.