Articles on: Konfiguration
This article is also available in:



In the context of a complex organizational structure, tags are suitable for triggering an alarm in the higher organization in some or all of the lower organizations. All alarm data, such as text and coordinates, are retained.

If a tag is triggered multiple times within 24 hours in the same sub-organisation and the event name and alarm text are identical, all further triggers after the first triggering are discarded as duplicates.


First create a new tag in your parent organization.
You can configure the following properties:

*Name – short, descriptive name of the tag.
Description – what function does this tag fulfil?
*Colour – for better visual differentiation
*Protected – tag can only be used in sub-organisations after prior approval (see below).

Then assign this tag as an outgoing tag to a scenario of your parent organization. This ensures that the tag is also sent to the sub-organisations in the corresponding alarm.

Now switch to a sub-organisation. There, when creating or editing a scenario, you can select the previously created tag as the inbound tag. This ensures that the tag received from the parent organization triggers this scenario with the same alarm data.

Protected tags

A tag protected in the parent organization can be selected in the sub-organisations, but cannot be used immediately. For this, the use of the tag must first be approved in the parent organization in the Tags > Access Requests area.
With the approval, the incoming tag is immediately assigned to the scenario of the sub-organisation. Subsequent edits of the scenario in the sub-organisation do not require a new access request as long as the incoming tag is not removed.
Rejected requests can be made again at any time by the sub-organisation by assigning the incoming tag.

To ensure that the parent and sub-organisation remain informed of these processes, appropriate emails are sent in the following cases:

A sub-organisation wishes to use a protected tag. In this case, all organization administrators of the super-organisation receive a corresponding e-mail with a request for a decision.
The higher organization decides on the use of a protected tag. In this case, the user who made the request within the sub-organisation receives an email with the decision.

Restrict use

A tag can normally be seen and used by all sub-organisations. If you, as the administrator of a parent organization, want to restrict this behaviour, you can select the sub-organisations that should see and use your tag under "Restrict use". All organizations not selected will then have no access to the tag you created.

If you make this configuration and select a sub-organisation, this sub-organisation and its sub-organisations will have access to the tag. This behaviour is symbolized to you with the grey no longer selectable checkbox.

Manual triggering

Manual triggering of a tag is also possible within the parent organization. This way, you do not have to trigger an alarm through a fully configured scenario in the parent organization if you actually just want to start the alarms in the sub-organisations.
To do this, click on "Trigger Tag" within the tag overview and enter a name for the event and the alarm text. These will be used to generate the alarms in the sub-organisations.

After triggering, you will receive a list of all tags triggered manually, including the event and alarm texts used, in the "Manual Triggering" tab within the tag overview.

Updated on: 09/01/2024

Was this article helpful?

Share your feedback


Thank you!