Hi, new to the forum and also new to Ignition. Was hoping that I might be able to post this query to see if anyone had any suggested solutions. I am currently collecting a large number of tags out of our historian into Ignition. All our tags use (.) full stops as separators and our tools and reports all make reference to these tags. The I have is that when I assign a name to those tags within designer, I am not able to use the full stop and have had to settle with a space instead. This has obviously not gone down very well with users. The documentation limits the use to a set of 4 special characters. Someone must have come across the challenge before and I’m hoping to find some means of assigning the full stop back into the tagnames. Thanks in advance.
The restrictions on tag names are really a bummer at this point but you’ll just have to live with it. There’s no hidden workaround or trick.
Thank Kevin. You wouldn’t happen to know if this is one of the items that are being looked at as an enhancement would you?
It’s not something we’re actively looking at right now. The backwards compatibility implications would be a nightmare. We currently use the .{property} at the end of tag paths to indicate a tag property is being addressed.
It’s probably worth posting on ideas.inductiveautomation.com to see if it gets any traction though 
I am one who would be strongly opposed to such a change. I’m horrified that spaces are allowed, actually. /:
What’s wrong with spaces?
Dots no, spaces yes! Spaces mean your tag paths and names can be natural text, usable in your graphics. I couldn’t imagine for example not having spaces in alarm tag names. Akin to file and folder names in your OS. I’ve never had an issue with using spaces in tag names in 7 yrs
I don’t think spaces is best practice for most. I prefer no spaces as well.
One such conversation I saw,
I see programming variables completely differently to tags. Tags I see more as user-facing. 🤷 (I couldn’t find the boy shrug) I don’t really have a better formed opinion than that though, other than it being a nightmare for things like alarm tags to use no spaces
#Nminchin. Nothing wrong with spaces. But the issue is that we have a legacy system that has been around for a long time that makes use of ‘dots’. What if you implemented a new system tomorrow that forced you to replace your spaces with dots…wouldn’t that be a nightmare for the 7 years of config and references that you have grown so used to.
I feel tags are not supposed to be descriptions and in my eyes a system should be able to cater for either and not limit users to make a changes.
If we were starting over I’d be in favor of allowing spaces, but perhaps not leading or trailing. If you mistakenly double-spaced in the middle of some reference that would be your terrible bug to track down.
Alas, these restrictions originate from probably 15 years ago, and now have 15 years of baggage built around them, so I wouldn’t hold your breath for a change.
On the contrary, that is pretty much exactly what they are. You should be able to read a tag name and understand what it is used for. They shouldn't be a full blown description, but at least somewhat human readable to the point that they are easily understood.
FT25612 LOW LEVEL SETPOINT or FT25612 LLVL SPT or FT25612_LLVL_SPT(my personal preference) is far more readable than say N7:15 or H01 or V07 (pick your flavor).
Exactly the reason I prefer underscores to spaces.
Or FT25612/Setpoints/Low
Or FT25612/Setpoint/LevelLow–sorts all level related setpoints together with alphanumeric sorting and camel case is pretty readable without spaces. Spaces in tag names look wrong to me!
Actually I wouldn’t even put level in there, as the device type should determine that. I’ve amended my other post
And now we've eliminated the need for spaces in tag names 
FT25612/Setpoints/High High
What’s wrong with FT25612/Setpoints/HighHigh?
So…I feel that we have someway lost the purpose of what I was submitting the original post for. I just need the ability to put a full stop in my tags…not a space, not a slash and not a underscore. Appreciate everyone’s suggestion…but I just dont like green eggs and ham 
Thanks Guys
Nothing, but what about when it comes to alarms, and more complex alarms?
Do you want the alarm to display as "PressureHighShutdownFault" or "Pressure High Shutdown Fault"?
And what about if you want to use the tag name in the binding of a label that displays its value? I want my graphics to use proper English, not PascalCase
Yes indeed! Can you use replace() to replace dots with underscores dynamically? Otherwise, as everyone else has said, dots are not supported at all in tag names unless it's to reference a tag's properties