CS Quarterly Patch: Lack of proactive communication

Well written, ​@mobrien14!

We had a similar experience a few weeks back during our implementation of CC when we hooked up the CS+CC connection. Data was flowing, but none of the default CS+CC reports (nor the default dashboard) were available for use.

Following nearly a month-long support ticket, it came out that we didn’t have system folder in report builder. In looking at that folder today, it appears that the system folder in Reports Builder can be deleted?!? This seems like a massive oversight -- and nowhere in any of the documentation around building Community reports or dashboards does it mention that the System folder needs to be present. If I had to hazard a guess, I’d wager a previous admin might have deleted that folder during a prior spring cleaning, since nothing (at the time) was dependent upon it.

Please, Gainsight. If something is going to impact our systems, whether it’s an upcoming release or a potential integration with one of your other products that we might not yet own, let us know. And if we’re about to delete something that could be important, a dependency popup would be nice!

Hi @mobrien14,

Thank you for sharing your experience and concerns. I’m truly sorry for the inconvenience caused by the unexpected requirement for Microsoft365 admin consent—it’s clear we could have communicated this more effectively.

I’d like to explain our situation briefly:

• Initial Oversight: At the time of the patch release, our team was not aware that admin consent was required. This detail came to light only later in the process.
• Communication Challenges: We intended to alert admins about the change, but due to technical limitations in identifying which tenants had the Outlook plugin enabled, we were unable to send targeted notifications without impacting a broader audience unnecessarily.

Your feedback is invaluable, and we’re actively reviewing our processes to ensure that any future changes, even those impacting only a subset of users, are communicated clearly and in advance. If you have any suggestions or further insights on how we can improve our notifications and change management, please let me know.

​@Ritika Jindal I appreciate that explanation and totally get that things come up last minute, I think we’ve all experienced that sort of thing.

However, given that the change was discovered at the last minute and despite that there was an inability to segment, this arguably should have been communicated out via in-app methods. Even if it was simply a banner message (vs. a full pop-up) to alert us of the change and direct us to the release notes, that would’ve allowed some notification to impacted users without necessarily detracting from the overall experience.

Like ​@dayn.johnson said, we need to know about changes that impact our instances & I’d rather you all overcommunicate with us as admins instead of us being in the dark on these things. At the very least, it prevents us from looking unprepared or out of the loop to our leaders and users. 

​@mobrien14  Thank you so much for this post. Our CSM JUST reported the issue to us today and thanks to your post I was instantly aware of the issue. Honestly, had I not seen it my 1st thought would NOT have been that it was related to any Gainsight changes and it probably would have taken me longer to diagnose. 

I agree with communication needing to be more proactive as it’s likely to take several days for me to get teh MS Admins to action this for us. 

There’s gotta be something in our instance that keeps track of what features we use (Chrome Extension, Outlook Plugin, CS+CC Connector, etc.) so those communications/banners could be targeted based on our feature flags. 🤔