System Action to retrieve if environment is production

Builtin & User functions
On our radar

The idea is to have a system action that retrieves if we are in a production or non-production environment. This would be used, for example, in Timers instead of having a Site Property “isDevelopment” that can be easily changed by an user with access to ServiceCenter.

Created on 19 Dec 2018
Comments (8)

Hi Catia,

  Yes pre built action would be nice but you can currently check to see what mode the environment is using the Activation Entity from the System espace. Do a filter on Info="Server Mode" and text="Development" and if it finds a record then you are in development mode.

There are a couple of other values in that entity which may also be useful such as "LicenseType"

Hi Cátia,

Thank you for your idea. 

Can you please elaborate on the uses cases that you want to fulfill and why do you need this information for those cases? You speak about timers. what are those timers doing that can't run in production? do you have more examples?

Either way, I will mark this as "on our radar" to understand if there is more demand for this.


Changed the category to Builtin & User functions and the status to

On our radar


Hi John,

Thank you, yes that is one way of doing it, amongst others, but if you are working at a factory for example, you can’t reference system tables without special permissions.

Hi Tiago,

I said timers, but this can be used in several different cases. The idea is to avoid that functionalities, that were built solely for the purpose of helping the developers and maybe testers do they’re work, can be active in production. 

For example in a user list we can have a “Login as” action that allows us to login with that user, or we want to allow users to erase data from the application because the tests they are executing need a “clean set of data”. All these kind of functionalities should never be available in PRD.

Hi Catia, yes agree that it isn't ideal, just mentioned in case you needed something now.

@Tiago, it is useful for a number of reasons. One particular is where you want to have logging, test information and other details to help with testing. For example displaying extra fields on a user screen such as ID's that you don't really want showing up in your production environment. Using Site properties is a way around this but as Site properties aren't shareable across applications it is a lot simpler to just check what environment you are in. 

Hi Nordin,

Environment sticker uses system tables. Does not fit the use case.