# Custom fields

> The extra registration details of members (company, job title, city, ticket type, interests) - types, multiple choice with a minimum and maximum, required, the member list filter, workflow conditions, who sees and who edits them, what shows on the member page, the request to complete registration on the next visit and the variable in campaigns.

**Custom fields** are the details the community wants to keep about each member beyond name, email and phone: company, job title, city, date of birth, ticket type. The team creates the fields once; the values show up on each member's record, in the person's own profile and in email campaigns.

## What it's for

| Community | Fields |
|---|---|
| Association | *Company*, *Job title*, *Member number* |
| Event | *Ticket type* (choice), *City* |
| Tech community | *Interests* (multiple choice): Linux, Cloud, Security |
| School | *Class*, *Enrollment date* |
| Coworking | *Floor*, *Has a parking spot* (yes/no) |

## How it works

### The types

| Type | What for | Example |
|---|---|---|
| **Text** | Any short text | Company |
| **Number** | A number | Member number |
| **Date** | A date | Date of birth |
| **Choice** | One option from a list (at least two) | Ticket type: VIP, In person, Online |
| **Multiple choice** | Several options from a list, from 2 to 50, up to 80 characters each | Interests: Linux, Cloud, Security |
| **Yes/no** | A yes or no answer | Has a parking spot |
| **Email** | An email, stored in lowercase | The company's finance email |
| **Phone** | A phone number in international format; without the country code, the community's country applies. Useful for a business phone, besides the account's phone | Business phone |
| **Link** | An `http` or `https` address; without the prefix, it gets `https://` | Personal website, LinkedIn |

The type **can't change** once any member has a value filled in: *"The type cannot change once values are filled in."* The exception is **Choice**, which can become **Multiple choice** even with answers (*"There are answers already: the choice can only become a multiple choice."*): each answer becomes a list with the option the person had already picked. After that it can't go back to a single choice.

### Multiple choice

The person ticks the options in checkboxes. Under **How many a person can pick**, optionally set the **Minimum** and **Maximum** (from 1 to 50; the minimum can't be above the maximum or the number of options). With **Required**, the minimum is 1. The form explains the rule (*"Pick 1 to 3."*) and refuses what falls outside it (*"Interests: pick at most 3."*). In the field list, *min. 1* and *max. 3* show up.

On the profile and the record, the ticked options show as tags, in the order of the field's options.

### Renaming and removing options

This applies to **Choice** and **Multiple choice**:

- **Renaming** an option changes the name for everyone who picked it; the answer stays the same.
- **Removing** an option takes it out of the profile, the record, the filters, the workflow conditions and the campaign variables. The answer is kept: if the option comes back, whoever had picked it has it again.

### Required

A **Required** field must be filled in by everyone. Whoever lacks the value (an older member, an imported one or a new one) sees, on their **next visit** to the community, the **Complete your registration** window (*"{community name} asks for this information before you go on."*) and only goes on after filling it in and clicking **Save and continue**. Anyone who prefers can **Sign out**.

The [spreadsheet import](/membros/importar-membros) never blocks a row for an empty required field; the person completes it on their first visit.

### Text format

In a **Text** field, the **Validation regular expression** is optional: *"The whole value must match the expression; leave empty to accept any text."* For example, `[A-Z]{3}-\d{4}` accepts *ABC-1234* and refuses *abc1234*.

The **Hint message** (*"Use the format ABC-1234"*) shows under the field and when the value doesn't match. An invalid expression, one that is too long (over 200 characters) or a dangerous one (that could hang validation, such as those that look back in the text or look ahead) is refused when saving the field, with the reason under the expression.

In the list, the field shows **with validation**.

### On sign-up

**Ask on sign-up** puts the field on the form people fill in to join the community. A **Required** field is always asked on sign-up (*"A required field is always asked on sign-up."*); for the others, you choose. In the list, the field shows **asked on sign-up**.

People signing up fill in these fields (a **Multiple choice** shows as checkboxes) along with their name, email and password, in the list's order, and sign-up only finishes with the required ones filled in and in the right format. Existing members still see **Complete your registration** on their next visit, as above. See [Sign-up and access](/membros/cadastro-e-entrada).

### How values are shown

Values are always plain text. A **Link** only becomes clickable when it starts with `http` or `https`, and opens in a new tab. A **Phone** is shown formatted in the country's style.

### Who sees and who edits

| Who | Sees | Edits the values |
|---|:-:|:-:|
| Owner, admin and moderator | Everyone's | Everyone's |
| Finance | Everyone's | Only their own |
| The member themself | Their own | Their own |
| Another member | The ones the community shows on the [member page](#on-the-member-page), per each person's choice | — |

Creating, editing, reordering and deleting **fields** belongs to the owner and admins. Moderators and finance see the tab read-only: *"You can see the fields, but only owner and admin create, edit or delete them."*

### On the member page

Each field has the **On the member page** option: *"Whether other members see this field on the profile. The team always sees it."*

| Option | What happens |
|---|---|
| **Automatic** | Memberfy decides from the field's type and name (below). The screen shows the result: *"Right now automatic means: …"* |
| **Never on the profile** | Nobody but the person and the team sees the field, not even through the API |
| **The person chooses** | Shows to members; each person can set the field to **Private** in the **Privacy** tab of **Edit profile** |
| **Always on the profile** | Shows to members and the person can't hide it (*"Always visible (the community's choice)"*) |

**The Automatic rule.** A regular field becomes **The person chooses**, starting at **Members**. A field that asks for sensitive personal data becomes **Never on the profile**: those of type **Phone**, **E-mail** and **Date**, and those whose name (in Portuguese, English, Spanish, Italian or German, with or without accents) asks for health, address, documents and professional registrations (ID numbers, passport, medical or bar registration…), sex or gender, marital status, parentage, bank details or Pix key, birth, religion, race or ethnicity, orientation, biometrics, password, nationality, criminal records or emergency contact. Abbreviations count too (*Tel.*, *Cel.*, *Mat.*, *Doc.*…). City, state and country aren't on that list: the country has its own section on the page.

- That **Never on the profile** is stored on the field when it's created or edited. **Renaming a field never opens it**: it stays **Never on the profile** until the owner or admin picks another option.
- **Renaming a field to a sensitive name, or changing it to a sensitive type, puts it back to Never on the profile**, even if the team had picked another option before.
- Choosing **Automatic** on a field that is **Never on the profile** doesn't open it. To show it, choose **The person chooses** or **Always on the profile**.
- **A signup field never goes Public**: not on the public page, not with **Always on the profile**. It's at most **Members**, and within the community's **Signup fields** limit (see [For the team: member pages](/membros/seu-perfil#for-the-team-member-pages)).
- In the field list, each one shows the result next to its type: *off the profile*, *on the profile, the person chooses* or *always on the profile*.

Changing this option belongs to the owner and admin; moderators can't.

> [!TIP]
> The screen itself reminds you: *"Do not ask for sensitive data (health, religion, documents) unless needed."*

### Where the values show up

- **Member record** (team): in **Administration › Members**, when editing the person, the **Additional information** section, with **Save information**. For someone who joined through an import, it also shows *"Origin: spreadsheet import on …"*.
- **My Account** (the member themself): the **Additional information** card, *"Fields the community asks for at registration."*
- **Member list:** each **Choice** and **Multiple choice** field becomes a filter (below).
- **Email campaigns:** each field becomes a variable (below).

### Filtering the member list

In **Administration › Members**, each **Choice** or **Multiple choice** field with options gets a filter with its name, below the search. Tick one or more options:

- on a **Multiple choice**, the list shows who picked **any** of them (*"Interests contains any of: Linux, Cloud"*);
- on a **Choice**, who chose **one** of them (*"Ticket type is one of: VIP, In person"*).

Filters on different fields add up (only people who match all of them show), and they also add up with role, tags, groups and dates. The tag's **×** removes the filter. The search also finds people by the name of a ticked option. The list can't be sorted by a multiple-choice field.

### In campaigns

Each field becomes the variable `{{field_<key>}}`, where the key is the field's name without accents, in lowercase and with `_` in place of spaces: the *Company* field becomes `{{field_company}}`, *Ticket type* becomes `{{field_ticket_type}}`. `{{campo_<key>}}` also works. The key is born with the field and doesn't change, even if the name changes later.

In the editor, **Insert variable** shows the fields in the **Community fields** group, with the right name. The value is formatted for whoever receives it: dates in the person's language, yes/no translated, a choice by its option, a multiple choice with the ticked options separated by commas, in the field's order (`{{field_interests}}` comes out *"Linux, Cloud"*). For people without a value, use the fallback text: `{{field_company|your company}}`. See [Per-recipient variables](/notificacoes/campanhas-de-email#per-recipient-variables).

### Deleting a field

The field disappears from the tab, the record, the profile and the campaign variables. Values already filled in **are kept**. A campaign that still uses the variable of a deleted field is refused on save or send.

## Step by step

*Role: owner or admin.*

1. **Administration › Members**, **Form** section, **New field** button.
2. **Field name** (e.g. *Company*) and **Type**. For a **Choice** or **Multiple choice**, write the **Options** (**Add option** for another one). For a **Multiple choice**, optionally the **Minimum** and **Maximum**.
3. For a **Text**, optionally the **Validation regular expression** and the **Hint message**.
4. Tick **Required** if everyone must fill it in, or just **Ask on sign-up** to ask newcomers.
5. In **On the member page**, leave **Automatic** or choose **Never on the profile**, **The person chooses** or **Always on the profile**.
6. **Save**. Use **Move up** and **Move down** to change the order in which fields show on sign-up, the record and the profile.

To fill in someone's value: **Administration › Members**, edit the person and use **Additional information**.

## Examples

**An association asking for the company.** The admin creates *Company* (Text, required). On their next visit, each member sees **Complete your registration** and fills it in. The conference campaign opens with *"{{first_name}}, has {{field_company|your company}} booked its seat yet?"*.

**A tech community sorting by interest.** The admin creates *Interests* (Multiple choice, with Linux, Cloud and Security, maximum 3, asked on sign-up). In the member list, they filter *Interests* by *Cloud* and see who picked it. A workflow with the *A profile field changes* trigger and the condition *Interests contains any of Cloud* adds the *Cloud track* tag.

**An event importing the ticket type.** In the [import](/membros/importar-membros), the *Ticket type* column goes to **+ New custom field**; Memberfy suggests **Choice**, because the values repeat. Afterwards, the team sees on each person's record whether they are VIP, In person or Online.

## Common errors and how to fix them

| Message | What to do |
|---|---|
| *Give the field a name.* | Fill in the **Field name** |
| *A choice needs at least two options.* | Add another option |
| *A multiple choice has at most 50 options.* | Merge or remove options |
| *The minimum cannot be above the maximum.* | Adjust the **Minimum** and **Maximum** |
| *Interests: pick at least 2.* | The person ticked fewer than the field's minimum |
| *Fill in {field}.* | The field is required and can't be left empty |
| *Read-only: owner, admin and moderator edit these values.* | Finance only sees other people's values |
| The type can't be changed | There are values filled in already; create a new field (a **Choice** can still become **Multiple choice**) |
| The field's hint message, while filling it in | The value doesn't match the field's expression; follow the format in the message |
| The expression is refused on save | It is invalid, too long or uses features that could hang validation (looking back in the text, looking ahead); simplify it |

## Frequently asked questions

**Does a member see other people's fields?**
Only the ones the community shows on the member page, and only if the person didn't set them to **Private**. See [On the member page](#on-the-member-page). The team sees everyone's.

**How do I see who picked an option?**
In the member list, with the field's filter. See [Filtering the member list](#filtering-the-member-list).

**Can I filter a campaign's audience by a field?**
Yes. Under **Choose the audience** (or **Exclude**), one condition per choice field: select, multiple choice or yes/no, up to 10 per campaign. See [Campaigns › The audience](/notificacoes/campanhas-de-email#the-audience).

## Through the assistant

`list_member_fields`, `create_member_field` and `update_member_field` (with the `email`, `phone`, `url` and `multi_select` types, `min_selections`, `max_selections`, `pattern`, `pattern_message` and `ask_on_signup`, and `profile_visibility`: `NEVER`, `MEMBER_CHOOSES`, `ALWAYS` or `null` for automatic), `reorder_member_fields`, `delete_member_field` (asks for confirmation) and `update_member_field_values` (on a multiple choice, the list of options). `list_members` filters with `field_filter`. See [Tools · Members](/mcp/ferramentas-membros#custom-fields).

## In the API

`GET` and `POST /api/member-fields` (with `type` `EMAIL`, `PHONE`, `URL` or `MULTI_SELECT`, `minSelections`, `maxSelections`, `pattern`, `patternMessage` and `askOnSignup`), `PATCH` and `DELETE /api/member-fields/{id}`, `PUT /api/member-fields/order` and `PUT /api/members/{id}/fields` (on a multiple choice, the value is the list of the options' `value`). The member list filters with `GET /api/members?fieldFilter[<key>]=a,b`. The values come in `fields` from `GET /api/members/{id}`, only for the team and the member themself; the ones the page shows other members come in `profileFields`. The page option is `profileVisibility` (`NEVER`, `MEMBER_CHOOSES`, `ALWAYS`; `null` back to automatic) in `POST` and `PATCH /api/member-fields`, and the responses carry `profileVisibility` and `profileVisibilityAutomatic`. On sign-up, `GET /api/member-fields/signup` (public, with the `X-CommunityId`) lists the fields the form asks for, and `POST /api/auth/register` receives the values in `fields`; in a community with a required field, signing up without it returns `422` on that field. See [Member Fields](/api/referencia/member-fields) in the API reference.

## Related

- [Import members from a spreadsheet](/membros/importar-membros)
- [Manage members](/membros/gerenciar-membros)
- [E-mail campaigns](/notificacoes/campanhas-de-email)