Skip to main content
darkknight
Expert ⭐️
August 5, 2026
New Idea

CS: Allow Journey Analytics Dashboard to be cloned/modified and made private

Related products:CS Journey OrchestratorCS Dashboards
  • August 5, 2026
  • 3 replies
  • 59 views

While it’s great that this 7-year old request was finally addressed in the latest release, and that OOTB metrics are now available, there are a few things that make the experience less than ideal.

  1. For starters, the dashboard was made public by default. No dashboard should ever be made public by default–especially without notice. Admins should control how and when dashboards are rolled out/assigned.  (Side note: This dashboards went live for many customers without notice a few days before the recent update.)
     
  2. The dashboard may contain irrelevant elements. There are aspects of the pre-built dashboard that may not be applicable to every customer’s environment. For example,
    • we don’t send emails against relationships, therefore the Relationship filter is irrelevant.
    • there are additional dashboard filters that would be relevant to our environment, yet I’m not able to add them.  
    • we don’t use Gainsight for surveys, so those widgets are irrelevant.

      It would be fine to simply clone the dashboard and make our own customizations to it except….
       
  3. The Journey Analytics Dashboard cannot be cloned or made private.  I get why you wouldn’t want a system dashboard to be deleted, however as noted in item #2 above, it may not fit every customer’s scenario, so we should be able to
    • Clone the existing dashboard and make our own customizations to it AND...
    • Make the system dashboard Private or assigned to techops@gainsight.com only (like the CSQL system dashboard is).  The workaround for this is to “Give access to specific people” and assign to myself.  This at least hides it from everyone else, but leaves a redundant, unnecessary dashboard in the admin view. 

 

3 replies

mobrien14
Helper ⭐️
August 5, 2026

Across the board, any system generated dashboard - be it Journey Analytics, Customer Success Qualified Leads, Community metrics, etc. - should be private by default and only made public when reviewed by the admin. 

As part of our community implementation, we’ve routinely had to manually mark all of the system generated assets to ‘private’ (aka viewable only by the admin team) & only due to getting confused questions by our end users.

I also agree with the need to clone them; the other system generated dashboards allow for cloning so it’s odd that functionality doesn’t persist. 

romihache
VIP ⭐️⭐️⭐️⭐️⭐️
August 6, 2026

100% agree.
Public-by-default rollouts create instant admin headaches and confuse end-users. We need full control over rollout timing, plus the basic ability to clone and customize OOTB assets.

Continuous improvement is better than delayed perfection
alizee
VIP ⭐️⭐️⭐️⭐️⭐️
August 6, 2026

You should have limited yourselves to providing the widgets as reports we can embed in our assets. What’s with what seems to be an obsession to come up with OOB stuff that you won’t let admins configure to their org’s needs?

The most expensive part of building is the mistakes. That's true in construction. Not so much in CSOps. So ask questions, make mistakes and learn. All views expressed here are my own.
dcassidy
Helper ⭐️⭐️
August 6, 2026

Agreed on all of Jeff’s points. We hit the same issues in our environment.

The biggest problem is #1: pushing this public by default, with no notice, days before the release. Dashboard visibility and rollout timing should always be admin-controlled, full stop. Silently changing what end users see is a support-ticket generator and an avoidable trust issue.

#2 and #3 compound each other. Irrelevant widgets (Relationship filters in our case) are a minor annoyance on their own, but combined with the inability to clone or set the dashboard to Private, we're stuck with clutter we can't clean up. The techops@gainsight.com-only pattern already exists for the CSQL system dashboard, so there's no reason that same model can't apply here.

The "give access to specific people" workaround technically hides it, but it's not a real fix. It just relocates the clutter to the admin view and leaves a dead dashboard for other admins to puzzle over later.

Please extend the CSQL-style private/system-dashboard treatment to Journey Analytics, and add clone support so we can adapt the OOTB metrics to fit our own environment.