In a Support discussion titled Can admins create user fields that are only visible/editable in the admin panel?, users explore whether Discourse allows creating internal-only user fields accessible solely by staff. copymonopoly initially notes that custom fields are always exposed to users unless hidden. Moin references a feature request and suggests hiding fields during signup and disabling editing/searching to make them invisible to users. Anton_Akhmerov shares a use case: storing student numbers internally. Moin confirms this approach works if all visibility/editing options are disabled. copymonopoly reports a bug where editable fields auto-show on signup. Later, they discover the “Staff user custom fields” admin setting 6, prompting clarification from ToddZ, who explains it requires precise field names or IDs (e.g., 7_user_field). Moin confirms IDs are needed, not names. JammyDodger suggests adding documentation links to settings. copymonopoly concludes that User Notes (a built-in plugin) better suits their need for internal user annotations. tobiaseigen endorses User Notes for staff collaboration, noting they’re more intuitive than custom fields. The thread ends with consensus that while “Staff user fields” exist, User Notes are often a more practical solution for internal-only data.
I noticed that custom user fields are always visible to users during signup or in their profiles, depending on the settings.
Is there currently a way to create a user field that’s only visible and editable by staff (for internal use), not exposed to users?
If not, would this be something the team might consider supporting in the future?
There is a feature request for that: Option to include user field that is only editable by staff
You may want to share your use case there to support the request.
Depending on what you want to use the field for, it may be sufficient to hide the user field for everyone except staff with a theme component.
I run discourse for university courses, and the custom user field would be the student number. A theme component seems like an OK stopgap solution, but making a custom field completely invisible to anything but staff or system API would be cleaner.
Actually, I wonder if the option to hide the user field on sign up, which was added recently, makes user fields that users cannot see possible.
I think user fields are only shown to users when they are editable. So if you hide it on sign up and disable editing (and showing and searching) the field should be hidden for the user.
Really appreciate your help earlier! I’ve drafted a bug report showing this behavior clearly.
Hey, I noticed a setting in the admin called “Staff user custom fields”. I’m not entirely sure what it’s for or how to use it.
Could you help me understand how this works? Thanks!
So far I had no use case for using custom fields through the API. So I cannot tell you more than what I learned from
Have a look at Discourse User Notes, a plugin now included in core. It’s meant for staff to internally share notes about users. (Loves cats – Golfs with the CEO – etc.)
@copymonopoly did the suggestions from Moin and Toddz help you resolve your issue? FWIW, we here on meta make very active use of user notes to share information amongst staff about our members. It works well (arguably better than custom user fields) because notes are right at your fingertips:
You can also access user notes via data explorer and likely also add/access them via the API.
I wasn’t sure about this either but found a couple of clues…
It makes more sense next to the companion setting Public user custom fields:
And they have to do with who can access which records via the API:
Interestingly, the fields above don’t seem to select from available user custom fields, but take any text input – so you’d have to enter the field names precisely read this doc carefully.
Is it the name? Based on the doc I shared above, I thought you need the ID
Oh, I missed that in the doc! 
The field accepted whatever I typed & I made a bad assumption.
Also may be a case where it’d be nice for the setting description to have a link to documentation.
Thanks a lot for the suggestion!
Originally, I was planning to use custom user fields because I wanted to write a small component that displays specific information I add for each user. So I hadn’t really considered the Discourse User Notes core plugin.
But it does sound like User Notes might be able to achieve something similar, and it could be a helpful approach. I really appreciate the recommendation — I’m currently looking into it!
@hugh some feedback for your team. The inputs for the public user custom fields and staff user custom fields site settings accept anything but only the ID works, which is confusing.
would be having a custom field lookup for those admin settings that works in a similar way to the one in the ‘add user to group through User Custom Field’ Automation: