# Alarm Names Allow Forward Slashes **URL:** \ **Category:** Ignition Early Access\ **Created:** [May 12, 2020, 5:26pm UTC](https://forum.inductiveautomation.com/t/alarm-names-allow-forward-slashes/34663 "2020-05-12T17:26:24Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![WillMT10](https://avatars.discourse-cdn.com/v4/letter/w/7feea3/32.png) [@WillMT10](https://forum.inductiveautomation.com/u/WillMT10)\ **Post date:** [May 12, 2020, 5:26pm UTC](https://forum.inductiveautomation.com/t/alarm-names-allow-forward-slashes/34663/1 "2020-05-12T17:26:24Z")
We recently had some issues with a few alarms in our project due, indirectly, to some alarms being named with forward slashes ("/"). According to support, it sounds like allowing forward slashes in the name is expected behavior, but I didn't get any clarification as to why before the ticket was closed. I'm more just curious if there is a use case for allowing forward slashes in alarm names that I'm not aware of, given that Ignition hides all the text to the left of the "/"? From the [manual](https://docs.inductiveautomation.com/display/DOC80/Configuring+Alarms): > ### Alarm Names and Forward Slashes > > Alarm names can make use of forward slashes ( "/" ). However the alarm name property throughout Ignition is designed to only show characters after the rightmost forward slash. Assume you name an alarm with the following: > > `one/two/three` > > The alarm name property (as seen on the various alarm table components, Tag Browser, and various alarm scripting functions) will omit "one" and "two", leaving the alarm name as: > > `three` > > This behavior can be confusing, but is easily avoided by not using forward slashes in alarm names. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [April 4, 2022, 5:29am UTC](https://forum.inductiveautomation.com/t/alarm-names-allow-forward-slashes/34663/3 "2022-04-04T05:29:04Z")
FYI I just added another topic RE this. Personally I think it's a bug and that alarm names with slashes and commas should not be allowed, as these have consequences especially when trying to read/write to them via scripting functions. > [@\[BUG/FEATURE\] Disallow commas and slashes in alarm names](https://forum.inductiveautomation.com/t/bug-feature-disallow-commas-and-slashes-in-alarm-names/57985): > > v8.1.5 Not sure if this is fixed already, but someone added some alarms into my project and put commas and slashes into the alarm names which is obviously bad and caused issues. Can the alarm name field please do some input parsing to stop illegal characters from making it into this field? Specifically, the issue is that you can’t use script to read these alarms. E.g.: system.tag.readBlocking('Alarms/Stuff Broke Check Something/Alarms/Stuff Broke, Check Something.Priority') \>\>ValueError: I… ---
**Author:** ![WillMT10](https://avatars.discourse-cdn.com/v4/letter/w/7feea3/32.png) [@WillMT10](https://forum.inductiveautomation.com/u/WillMT10)\ **Post date:** [April 4, 2022, 2:25pm UTC](https://forum.inductiveautomation.com/t/alarm-names-allow-forward-slashes/34663/4 "2022-04-04T14:25:59Z")
I was never satisfied with the answer from support that it was expected behavior. At the very least, it would be good to have an understanding for what purpose and scenarios forward slashes are allowed in alarm names. Only thing I can think of, is to allow for a more complex hierarchy of alarms (i.e. - “Alarm Group 1/Alarm 1”, “Alarm Group 1/Alarm 2”, “Alarm Group 2/Alarm 1”, etc). If so, I would guess the number of headaches this causes vs the number of projects that actually use this mechanism is probably more skewed towards the headaches (just me guessing though). At the very least, it would be nice to have a warning in the alarm editor to indicate that the “/” may cause unexpected behavior or better yet, a gateway configuration setting that we can enable to make “/” an illegal character for the alarm name entry field. The commas definitely look like a bug and shouldn’t be allowed. The forward slashes are still an unknown since they wouldn’t cause errors in the scripting functions (at least, I don’t think they would). I just don’t really understand what the usefulness is for allowing forward slashes in the alarm name in the first place. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [April 4, 2022, 2:50pm UTC](https://forum.inductiveautomation.com/t/alarm-names-allow-forward-slashes/34663/5 "2022-04-04T14:50:55Z")
fwiw, you can also add a ! into the alarm name which also kills reading anything from that alarm via script 😕 A warning would definitely be a good start! Something like “Don’t be an idiot… You’ve added dumb characters into the alarm name. You technically _can_ do that, but it’s _your_ funeral”