Add banner to Sandbox(es) so can identify easily

@HollySimmons you might be interested in this post as well: 

Please for the love of everything, help protect me from myself - I get extremely paranoid working in the sandbox because it is indistinguishable from prod at a glance and so I spent AT LEAST as much time verifying that I am in the sandbox vs prod as I do actually testing and getting stuff done.

A simple banner please. This is even more important now that you have the app switcher and you have to guess which environment you will be dropped in. Here is an example:
 

And here is the code snippet:

  <div id="banner" style="background-color:#f5e042;">
    <div id="banner-content" style="text-align:center;">
    This is a Sandbox.
    </div>
  </div>

@HollySimmons check out Andrew’s idea below...also Hi, I hope you’re having a great start to your new year! 

Can we please see some traction on this? It seems like a relatively low-lift thing to do, but would be very valuable for admins, just from a “peace-of-mind” perspective alone.

This is especially critical now that Gainsight has introduced single-sign on for their applications INCLUDING sandbox instances. Whereas before SSO, we had two separate instances to log into (and two separate Okta tiles, if you used something like that for authentication), this update consolidates instances into one, making it even more difficult to distinguish between being in sandbox vs production.

Let’s please get some traction on this! But also please make sure that if a banner is introduced, that it does not sit over any critical elements in the application. I’ve also worked in many a sandbox where the banner sits on top of and blocks access to functionality 😫

I agree with the posts above. This needs to be a priority and it seems like something very achievable. We use Okta for SSO and I have users who have complained to me that they are being directed to the Sandbox when they click on the Okta tile (because that was the last environment they were in) and they build or look for information there when they are intending to be doing it in Production. This is causing them rework and is causing me unnecessary distractions when people are logging tickets to me telling me the data is wrong or their information is not appearing. I have to stop what I am doing and troubleshoot only to find out they were in the Sandbox. I am afraid this kind of issue could happen where someone intends to build something in the Sandbox and instead they do it in Production and break something.

We don’t have a Sandbox (at least right now) but this seems like a super basic thing to realize at a glance the environment were we are working on.

When I was preparing the certifications I had access to a training org and found myself in several occasions trying to do something in my actual org instead of the training one, they looked the same…

It makes my skin crawl thinking about the repercussions of confusing the Sandbox/Production environments! An honest mistake could cause chaos, and that can be easily avoided by simply including a visual cue.

The Auto-Group Tabs chrome extension is useful for this in the meantime. It allows you to group and style groups of tabs based on the domain/sub-domain

Hi All,
Yes this scenario, comes whenever someone is trying to access through identity provider home page eg: okta, where now only one tile is present for all gainsight instance (after SSO), and in case user has access to multiple product instances, we are using their last used log-in to redirect to that particular instance. The confusion might not only with prod/sandbox, but with multiple px subscriptions, community control instances, and education instances. So, we plan to enhance this by adding an intermediary step after clicking on the gainsight tile in okta, which will show the list of instances, the user has access to (similar to app switcher) and then re-direct him to that instance, based on the selection. We have added this to our roadmap and will be available soon.