Clients, lists, and custom fields

Overview

The Clients area is your guest roster in Mallard Bay: one place to see who you know, segment them into lists for outreach and campaigns, and use custom client fields (called Custom Properties in the product) to tag, filter, and organize guests consistently. Client records connect naturally to bookings, quotes and booking invites, leads, and messaging, so work you do here shows up across sales and operations—not only on the Clients screen.

This article covers the dashboard at /clients, creating and editing lists at /clients/lists/new and /clients/lists/:id, and defining field types at /client-custom-properties.

Prerequisites

• Account access: The main Clients table and Client lists are each wrapped in a product paywall in the app. If a tab or button appears locked, your plan may not include that capability; the UI can still route you to an upgrade flow.
• Custom property definitions: Before you can build filter-based lists on custom data, you need at least one client custom property defined (see Custom field definitions).
• Optional—imports: To bulk-add people from a spreadsheet, you need a CSV with the required columns (see Import clients).

Clients hub (`/clients`)

Open the Clients page

Use your sidebar navigation to open Clients. The page has two tabs:

1. Clients — your full client roster (searchable table).
2. Client lists — saved segments and list management.

The active tab is reflected in the URL query string as ?tab=clients or ?tab=client-lists.

Client roster tab

Search — Use the table toolbar search to filter clients by text (backed by URL search parameters so results stay shareable/bookmarkable).

Date range — Optional filters limit the roster by a from and to date (aligned with calendar date controls in the app).

Primary action: Add client — Opens a form to create a new client (name, email, phone, and related fields from shared form config).

Companion actions (when you are on the roster tab) — Export downloads client data for the current search and date filters. Import clients opens a CSV import flow.

Row actions — Each row’s menu supports View details (opens the client profile), Create new lead (associates a lead with that client), and Message (opens send-message for that client).

Developer-only shortcut — In this codebase, a header shortcut labeled Custom Properties on the main Clients page is shown only for accounts flagged as developer users. Most users should use the path from a client profile (below) to reach /client-custom-properties.

Client profile (/clients/:id)

Open any client from the roster to see their profile. Layout differs slightly on mobile vs desktop, but the same information is available.

Typical sections include:

• Contact header — Name, avatar, date added; Edit updates core client fields.
• Custom Properties — Collapsible section listing values for each defined field; ⋯ menu supports Edit (inline editor) and Custom Properties (navigates to the field-definition page at /client-custom-properties).
• Notes — Internal notes for your team.
• Metrics, quotes, bookings, leads, communication — Connect this guest to pipeline and trip history (quotes/booking invites, bookings, inbound leads, and message activity).

Quick actions on the profile let you send a message, start a new quote, a new booking, or a new lead for this person—bridging CRM work into sales and scheduling.

Client lists (`/clients` → Client lists tab)

What lists are for

Client lists are saved segments—either built from rules (filter-based) or by manually selecting clients (selection-based). Lists can drive counting, review, and downstream workflows that reference a stable audience; in the codebase, list membership and filters are first-class data (ClientListType.FilterBased vs ClientListType.SelectionBased).

Create a list (/clients/lists/new)

Switch to the Client lists tab and use the header Add client list control:

• Build list with filters — Opens the filter-based creator (default when you do not pass a special query flag).
• Select people manually — Opens the selection-based creator (the URL includes a query parameter that selects this mode).

If Client lists are not enabled for the account, the button may show a lock but still navigates to the create route, where the standard paywall/upsell can appear.

Filter-based lists

You give the list a name and add one or more conditions. Each condition has:

• Property — Chosen from your outfitter-defined client custom properties (not free-text keys).
• Operator — Depends on property type (for example, numeric and date types expose comparisons such as equals, greater than, and less than; text and boolean types use equality-style operators in the UI).
• Value — Typed input appropriate to the property (with support for structured display when the property uses an alternate format in the product).

Saving creates or updates a filter-based list. Preview panes in the editor show who matches before you commit.

Selection-based lists

Name the list and pick specific clients from your roster (search/checklist-style UI). You can add or remove members on an existing manual list. A preview shows the current membership.

Open or edit a list (/clients/lists/:id)

Open a list from the Client lists table to view or edit it.

• System lists — Some lists are marked system-defined. The UI shows an informational banner: they are managed by the system and cannot be edited or deleted. You still get a read-oriented view (including preview of members where applicable). Exact list names and purposes are determined by the platform, not by this dashboard repo.

Archive lists

From the client lists index, bulk actions can archive selected lists. System-defined list IDs are excluded from archival in the UI so you cannot remove them by mistake.

Custom field definitions (`/client-custom-properties`)

Why this page exists

Custom Properties are the schemas for extra data you store on clients: labels, types, and descriptions. Values are set per client on the profile (or via flows that write client data). Filter-based client lists use these same definitions as the dropdown of filterable fields.

Create a property

Open /client-custom-properties (from a client’s Custom Properties section ⋯ → Custom Properties, or the developers’ shortcut on /clients if visible).

Use Add Property and complete the form:

• Property label — What your team sees.
• Property type — Such as text, number, boolean, or date (the form defaults new fields to Text in code).
• Description — Required in the create form; use it to remind staff how to use the field consistently.

The product shows a clear rule in the UI: definitions cannot be edited after creation. To “change” a field, archive the existing definition and create a new one (wording is surfaced as an in-app banner).

Manage and archive definitions

The table supports search and filters (for example by entity type and property type, driven by URL query parameters). You can archive definitions you no longer want; archiving is the supported way to retire a field without rewriting history in place—exact behavior of archived fields on old client records is enforced server-side and is not fully described in this frontend repository.

Set values on a client

On /clients/:id, use Edit under Custom Properties to set or update values for the active definitions. Success is confirmed with a standard “updated” message in the app.

Import clients (CSV)

Import clients expects CSV headers to include at least first_name, last_name, and email. Optional columns supported in the importer include phone_number (normalized when possible) and note.

Rows that fail validation or creation are reported per row; the modal may stay open while there are failures so you can address them.

Common pitfalls

• Lists won’t filter on data you never defined — Filter conditions only offer custom properties you created for clients. Build the field first, fill values on clients, then build the list.
• Mixing up “everyone” vs a saved list — The searchable Clients tab is the full roster; Client lists are saved segments with their own URLs and membership rules.
• Trying to edit system lists — They are read-only by design; rely on your own filter- or selection-based lists for bespoke segments.
• Expecting to rename or tweak a custom property in place — Plan on archive + recreate when the definition must change.
• Finding the field-definition page — If you do not see Custom Properties in the main Clients header, open any client profile → Custom Properties section → ⋯ → Custom Properties.

Related workflows (from the product surface)

• Quotes, bookings, and leads — Client profiles expose quotes/booking invites, bookings, and leads, and quick actions jump into those flows with the client pre-associated where applicable.
• Messaging — The roster and profile support send message entry points for one-to-one communication using your templates and channels setup.
• Message templates — Template preview logic in the app can pull sample client records (among other entity types) when rendering previews, so consistent client data improves realistic previews.
• Leads — Leads remain distinct from clients in Mallard Bay; you can attach lead workflows to an existing client from the roster actions or profile.

What this repository does not specify

• Pricing and entitlements — Which subscription tiers unlock Clients vs Client lists is determined outside this codebase; only the presence of paywall gates is visible here.
• Names and business rules of system-defined lists — These come from the backend; the dashboard only identifies them as system lists and blocks edit/delete.
• Server-side effects of archiving custom properties — Archival impact on historical values, reporting, and automations is not documented in the frontend source reviewed for this article.