---
title: "User information"
description: "Review site validation-field controls and their selection and write boundaries."
canonical: https://docs.ordering.co/docs/products/dashboard/settings/user-information/
---

# User information

Use **User Information** to control the **Required** and **State** settings for customer, address, and credit-card validation fields. These are site-specific settings: the fields and switch positions you see can differ between sites.

> **Availability**
>
> **User Information** is available to Dashboard administrators from **Settings**. The sites shown depend on the project configuration and enabled apps. The interface can show all returned sites or only the website and relevant enabled app sites.

## Open User Information

1. In the Dashboard sidebar, select **Settings**.
2. Select **User Information**.

The direct Dashboard path is `/all-settings?category=user_information`.

![User Information settings showing site-specific customer field sections](https://docs.ordering.co/img/docs/dashboard/settings/user-information-overview.jpg)

## Data and component boundaries

The current source composes three field controllers:

- **Cart and Customer Details** filters validation fields whose `validate` value is `checkout`.
- **Address fields** filters the `address` group and removes several customer-identity rows from that section.
- **Card fields** filters the `card` group.

Select a site in a section to open its **Settings** table. Each available field has two switches:

| Control      | What it does                                                 |
| ------------ | ------------------------------------------------------------ |
| **Required** | Maps to the site-specific validation-field `required` value. |
| **State**    | Maps to the site-specific validation-field `enabled` value.  |

The table only controls these switches. Field labels, input types, and the fields that appear are defined by your project's validation-field configuration. Do not assume that another site's fields or switch positions are the defaults for yours.

> **Email**
>
> When Email appears in **Cart and Customer Details**, its **Required** and **State** switches are unavailable in this screen.

## Immediate-write boundary

> **Selecting can write; switches write individually**
>
> There is no page-level staging step. The source issues an authenticated update when a **Required** or **State** switch changes. It can also issue create requests for missing site-field records after a site is selected.

## Important: selecting a site can create settings

Each of the checkout, address, and card controllers compares its base validation-field list with existing site records. After site selection, a controller can submit all of that section's missing records concurrently with `Promise.all`, using `enabled: true`; Email also receives `required: true` only in a section where Email participates. Merely opening an unconfigured site can therefore cross multiple write boundaries. This guide did not select a site or run any request.

## Field groups and screen examples

The historical screen examples describe the same three configuration areas: **Cart and Customer Details**, **Address Fields**, and **Card Fields**, and present them as controls for the data fields collected across Website, Kiosk, Apps, and Dashboard. The current source determines the available sites and fields from project configuration and returned application state. Do not expect every example field or site to appear in your project, and do not infer a downstream user-journey outcome from a configured switch.

![User Information configuration categories for a selected platform](https://docs.ordering.co/img/help-center-import/6ae9edc0ff79a78cca00eabc.png)

### Cart and Customer Details

The historical example groups fields as:

- **Personal Info:** Name, Middle Name, Last Name, Second Lastname, Email, and Birthdate.
- **Contact Info:** Mobile Phone.
- **Checkout Options:** Coupon, Driver Tip, and Comments.

The source describes Coupon as a discount-code field, Driver Tip as a gratuity field for delivery orders, and Comments as a text area for order instructions. These labels identify the example fields; they do not verify a particular checkout result.

![Cart and Customer Details panel showing personal information fields](https://docs.ordering.co/img/help-center-import/8c24c2c5cc5200d283271a6d.png) ![Cart and Customer Details panel showing checkout option fields](https://docs.ordering.co/img/help-center-import/c9339b2040bbe3b2d4dfe85c.png)

### Address Fields

The historical example includes **Internal Number**, **Zipcode**, and **Address Notes**, and presents them as location details for delivery. Use the fields returned for the selected site as the source of truth for the available address configuration; the source does not prove a delivery outcome.

![Address fields panel showing Internal Number, Zipcode, and Address Notes controls](https://docs.ordering.co/img/help-center-import/7b63f40038b757cb757d1fe9.png)

### Card Fields

The historical example includes **Cardholder Name** and **Zipcode validation**, and ties their use to payment-processor requirements. The set of fields can depend on the selected site and its validation-field configuration; verify the applicable configuration rather than inferring a payment-flow result.

![Card fields panel showing Cardholder Name and Zipcode validation controls](https://docs.ordering.co/img/help-center-import/7047cae4e06582f2a374e8b1.png)

## Change a setting carefully

1. Select the applicable site in the relevant field group.
2. Use **State** (called **Status** in the historical example) to change the `enabled` value for an available field.
3. Use **Required** to change the `required` value for an available field.
4. Confirm the observable editor state, then validate the intended flow with an authorized test if a downstream result matters.

The historical visual guide used the following table. Its result descriptions are source descriptions, not evidence that a setting was persisted, published, or changed a customer-facing flow.

| Action             | Visual indicator       | Result described by the historical source   |
| ------------------ | ---------------------- | ------------------------------------------- |
| **Enable Field**   | Blue Switch            | The field is visible to the customer.       |
| **Make Mandatory** | Blue Switch (Required) | The customer cannot skip this field.        |
| **Disable Field**  | Grey Switch            | The field is completely hidden from the UI. |

![User Information settings table with State and Required switches](https://docs.ordering.co/img/help-center-import/e35a8d1a4f0177ce8a7e3bb2.png)

> **Different site lists**
>
> The historical source notes that a Website list in **Cart and Customer Details** can be shorter than other lists, and suggests comparing **Business App** or **App Franchises** settings. Treat the fields returned for each site as authoritative; this guide does not establish shared defaults or cross-surface behavior.

Keep registration configuration focused. Mark fields as **Required** only when they are necessary for an operational or legal requirement, such as a birthdate where an alcohol policy requires it. Validate the result in the intended checkout flow rather than assuming a particular conversion outcome.

The fields can describe customer, address, and card requirements. Treat these values as personal information.

For internal or technical metadata on an individual product, use [Configure product custom fields](https://docs.ordering.co/docs/products/dashboard/stores/create-edit-product/custom-fields/). That guide is separate from site validation-field controls.

---

**Related guides:** [Platform settings](https://docs.ordering.co/docs/products/dashboard/settings/platform-settings/) · [Available order types](https://docs.ordering.co/docs/products/dashboard/settings/available-order-types/) · [Checkout by order type](https://docs.ordering.co/docs/products/dashboard/settings/checkout-by-order-type/)