Different Service Center colors for different environments

By João Pedro Abreu on 13 May 2010

So you don't accidentally publish a full solution on your production environment, thinking you're on DEV. It could be taken a step forward, by changing Service Studio's menu color to the one of the Service Center it's connected to. 

J.13 May 2010

Don't like the idea of colouring much.

tbh, a developer should not be allowed to publish to a product environment anyways.

Still I understand why you want it :)


Fernando Sousa27 May 2010

I totally agree with João, and since Roles & Permissions aren't flexible enough, I think that this could prevent errors.
Gonçalo Veiga30 May 2010
This little trick has been used for decades, since mainframes... for example, our desktop colors are differente depending if we are on the production server, quality or development.
Gonçalo Veiga24 Jun 2010
The top bar could have different colors depending on the environment it is. For example, gray for development, blue for quality assurance and red for production.

This is important to make sure you don't deploy in the wrong environment.


Merged from 'Have different colors for Service Center depending on environment' (idea created on 2010-06-24 09:31:31 by Gonçalo Veiga), on 2010-06-28 11:34:00 by Pedro Oliveira
Fernando Sousa24 Jun 2010

Similar to Different Service Center colors for different environments.

Merged from 'Have different colors for Service Center depending on environment' (idea created on 2010-06-24 09:31:31 by Gonçalo Veiga), on 2010-06-28 11:34:00 by Pedro Oliveira

Because all the environments look the same it's easy to make a mistake while working on servicecenter/enterprise manager. It would be nice to have a customizable topbanner in both systems so it's possible to clearly mark on which environment you are working to prevent accidental changes to production system. Sample:


Merged from 'Use a customiziable topbanner in servicecenter/enterprise manager to clearly mark prod/dev environments' (idea created on 2010-07-06 07:33:07 by Wim van den Brink), on 2010-07-08 16:44:30 by Paulo Tavares
Pedro Sêncio6 Jul 2010
This is a MUST to avoid disaster

Merged from 'Use a customiziable topbanner in servicecenter/enterprise manager to clearly mark prod/dev environments' (idea created on 2010-07-06 07:33:07 by Wim van den Brink), on 2010-07-08 16:44:30 by Paulo Tavares
J.7 Jul 2010
similar to http://www.outsystems.com/wisdomofthecrowds/IdeaComment_List.aspx?IdeaId=123


Merged from 'Use a customiziable topbanner in servicecenter/enterprise manager to clearly mark prod/dev environments' (idea created on 2010-07-06 07:33:07 by Wim van den Brink), on 2010-07-08 16:44:30 by Paulo Tavares
Fernando Sousa7 Jul 2010

I'd rather have a different color scheme than a top banner. Service Center already has a box at the top right on every screen that says the server/environment name, but that seems to be insufficient.


Merged from 'Use a customiziable topbanner in servicecenter/enterprise manager to clearly mark prod/dev environments' (idea created on 2010-07-06 07:33:07 by Wim van den Brink), on 2010-07-08 16:44:30 by Paulo Tavares
PG@Jumar11 Nov 2010

If logging into multiple ServiceCenters and EnterpriseManagers it would be useful to be able to assign DEV = Green banner, TST= Orange PRD=Red - just so you can immediately see if you are about to delete/takedown an application in PRD by accident!

Similar idea to different coloured terminal setups in other environments.



Merged from 'Allow setting of colour scheme of Service Center and or Enterprise Manager on different platform servers' (idea created on 2010-11-11 09:13:06 by Paul Graves), on 2011-08-24 16:14:47 by Pedro Oliveira

Hi,

The original idea and latest feedback is from 2010, since then Service Center UI has evolved.

Does the current UI (below) of Service Center fulfill this idea?

The current UI allows us to differentiate the environments. Having different colors would make those differences more striking, but I think the general purpose of this idea was fulfilled.

Plus, setting Roles & Permissions (which were mentioned in the beginning of the thread) help in avoiding this error as well.