Creating and configuring custom user fields

[Discourse]

This guide explains how to create and configure custom user fields in Discourse, including how to add them to the signup form, user profiles, and user directory.

Required user level: Administrator

Custom user fields allow you to collect additional information from your users beyond the standard profile fields. These fields can be displayed on user cards, user summary pages, and even retrieved using the Data Explorer plugin. This guide will walk you through the process of creating and configuring custom user fields.

Adding a user field

1. Go to Admin > Community > User Fields (discourse.example.com/admin/config/user-fields).

2. If you haven’t created any user fields yet, you’ll see this screen:
   

   

3. Click the “Add user field” button to add a new field.
   

   

Choosing a field type

The field type determines the input field users will see on the signup form. Choose based on the kind of information you’re collecting:

Text field

• Use for questions with many possible answers (e.g., “What company do you work for?”)
• Displays as an HTML text input
  
  

Confirmation

• Use for yes/no questions (e.g., “Would you like to sign up for our newsletter?”)
• Displays as an HTML checkbox
  
  

Dropdown

• Use for questions with a set number of possible answers (e.g., “What is your gender?”)
• Displays as an HTML select input
  
  

To add options for a dropdown field:

1. Click on the option input
2. Type an answer and click “Create”
3. Repeat for additional options
   
   

The completed options should look similar to this:

Setting the field name and description

• Field Name: Appears before the input on the signup form and user profile
• Field Description: Appears after the input to help users complete the field

Both the field name and description are required to save a field.

Here’s how custom fields appear on the signup form:

Configuring user field options

Field Requirements

• Optional - Optional fields may be left empty by users
• For all users - When a field is required by all users, every account, including logged on users will be forced to fill it. This is very useful for cases such as a terms-of-service (ToS) requirement.
• On signup - All new account will be required to fill the field.

Additionally, at the bottom of the creation form, you’ll find these options:

• Editable after signup: Allows users to update the field from their profile page
• Required at signup: Makes the field mandatory during account creation
• Show on public profile: Displays the field value on the user’s summary page
• Show on user card: Shows the field value on the user card
• Searchable: Enables searching for users based on this field’s value in the user directory

Show on public profile

When enabled, the field value will be shown on the user’s profile page:

Show on user card

When enabled, the field value will be displayed on the user card:

Searchable

When enabled, you can search for users based on their custom field values:

Saving and editing fields

1. Click “Save” to add the field to your site’s list of user fields
2. To edit a field, click the “Edit” button next to it in the list
3. To delete a field, click the “Delete” button

Adding custom fields to the user directory

1. Go to the user directory
2. Click the wrench icon:

3. Check the custom user fields you want to display
4. Click “Save”

The selected custom fields will now appear in the user directory table:

Last edited by @fzngagan 2025-07-17T09:12:38Z

Last checked by @hugh 2024-08-27T04:45:20Z

Check document

Perform check on document:

[bloomexperiment (Tracey)]

I think two images are missing under these headings:

• Adding a User Field
• Show on user card

Not sure if it’s related to Missing images at Meta.discourse.org – will post there too.

[JammyDodger]

I can see those images? (also in an anon window)

[Moin]

I cannot see theose

@simon

like this:

@simon

Show on user card

Select this option to show the field on the user card. The value of the field will be displayed next to the Field Name.

Searchable

But the second one works in my quote.

Edit

[bloomexperiment (Tracey)]

Interestingly I can see the second picture in the quote, but not in the original post^^

[JammyDodger]

Hmm. That’s interesting. I think there is a fix coming for the Missing images at Meta.discourse.org issue, so hopefully it will be resolved by that.

[Hifihedgehog]

Is there a setting I have to modify to specify the maximum length of a custom user field? Right now, in this “Test” field that I created as a test user field, I cannot enter even a single character on my user profile (or even “Test”, as shown).

[Vaping_Community]

I would love a field type: link / URL is that possible?

[maiki]

As URLs are text, the text field technically works, @Vaping_Community. However, you may be asking for additional details such as value validation or similar.

You might search or create a feature topic with what you have in mind.

[MachineScholar]

Are there any plans to allow multiline/composer for custom user fields?

Is it possible to have a multi-line/longer text field in the signup form?

Sorry I don’t have a current installation to see for myself. I am planning to create a community that requires approval from a moderator to join. I’d like to have a custom field in the signup form where people can write a short note about themselves. Is this currently possible? If not please consider this as a feature request. Thank you!

[langstonb (Brittany Langston)]

Note that if you want to embed a link into one of the custom user fields, you need to use HTML syntax!
<a href="url">link text</a>

For example, to acknowledge community guidelines / policies:

[rey.riel (Rey)]

Am I able to tie in a custom claim from my Auth0 SSO to a custom field? Currently the user enters field information in auth0, then has to enter it a second time when signing up. I’d like the value to be mapped over if possible

[dax (Daniela)]

It’s possible, yes:

spec/requests/session_controller_spec.rb

Within your SSO endpoint, you have the capability to map the claim to the payload, e.g.:

const ssoPayload = {
  nonce: nonce,
  email: user.email,
  external_id: user.sub,
  username: user.nickname,
  name: user.name,
  add_groups: a_custom_group,
  'custom.user_field_1': user['https://yourdomain.com/company_id'],
  'custom.user_field_2':  [etc...]

[rey.riel (Rey)]

Thanks @dax

Is there a way to verify the field name in the db? For example, we have a first name field, I tried custom.firstname, custom.first_name and custom.firstName, none of which resulted in the fields being populated in the sign up screen.

I’ve checked the error logs to confirm the token fields are coming in as shown above.

[rey.riel (Rey)]

digging more into the code here, is this only for a Discourse Connect SSO? We’re using the Auth0 plugin

[dax (Daniela)]

@rey.riel

we have a first name field, I tried custom.firstname, custom.first_name and custom.firstName

The syntax needs to be custom.user_field_x, where x is the numeric field ID shown in /admin/config/user-fields/{x}/edit.

@rey.riel

We’re using the Auth0 plugin

That mapping feature is not available in the Auth0 plugin directly.

That said, there are still options to achieve what you’re describing:

• creating a theme component. You can add a small front-end script that automatically syncs a Discourse custom user field with a value already stored in Auth0. For example, when a user logs in and the field is empty, the script can call a secure endpoint (a small cloud function) that fetches the field value from Auth0 and updates the Discourse profile via API.
• using automation tools. You could also use external automation services like Zapier or Make to perform that sync outside of Discourse. The advantage is that you don’t have to write/maintain code but only pay for the third-party service
• custom development. We can extend the Auth0 plugin itself to natively support mapping custom claims into user fields on login, or build a custom plugin that works in pair with the Auth0 plugin.

A clear drawback of the theme component approach is that you’d need to write and maintain custom code yourself, while also being careful from a security standpoint to avoid introducing potential bugs or vulnerabilities. Honestly, it’s not a solution I’d recommend for a production site like yours.

If I were in your position, I’d lean more toward the second option, using third-party tools, or consider submitting a feature request or custom work request (depending on our project managers’ evaluation) to enhance the Auth0 plugin itself.

If you’re interested in exploring the last option, we can continue the discussion privately.