Well, at least you have at least one other option which does not require coding.
You can setup a field security profile:
By the way, if you are not familiar with the field security profiles yet, you will need to read this:
What may not be clear is that you can allow “update” and “create” without giving “read” permissions.
As a result, a user who is not a system administrator, and who has been assigned that kind of field security profile will see masked values when he/she will be looking at the data:
Yet such a use will still be able to enter new value into the protected field:
Still, it’s a quick and robust solution: it works everywhere (on the forms, in the views, in the reports), and it does not take long to set up a field security profile.
Interestingly enough, if you know how to update customizations.xml file, it seems there is an attribute that you can add to the file manually and that is supossed turn an input control into a password control:
However, it did not really work for me when I tried. It did, but in some strange way – here is what I got:
It does not depend on the browser – it was exactly the same behavior in both Edge and Chrome.
I had a question on this field hiding. What if the user/team doesn’t want anyone but them to see data in certain sensitive fields. How do you hide those from the ‘System Administrators’ who are supporting the dynamics instance?
Thank you in advance.
there is not, really, a lot you can do to hide data from the System Administrators. This is what “administrative” access mode is for, but it’s not that granular (it hides all data, not to just some specific fields). Potentially, you might create a plugin; however, plugins don’t run for SSRS reports and (I think) for Word Templates… Long story short, I think it’s just counterproductive to try limiting a System Admin. Although, I know it might not be that obvious to the clients trying to protect their data by all means necessary:)