Site form requires fields the API and DB do not

[bdunncompany]

What I noticed

The "Add Site" / "Edit Site" modal validates ten fields as required client-side:

• Site name
• Timezone
• Address line 1
• City
• State/Region
• Postal code
• Country
• Contact name
• Contact email (must be valid)
• Contact phone (min 7 chars)

But the rest of the stack only requires name from the user. The DB has name and timezone as NOT NULL, but timezone has a server-side default of 'UTC'. The API zod requires orgId and name, but orgId is set by the parent component from the selected org, not by user input. Net effect: from the form-user's perspective, only name is actually needed.

Database (apps/api/src/db/schema/orgs.ts):

export const sites = pgTable('sites', {
  id: uuid('id').primaryKey().defaultRandom(),
  orgId: uuid('org_id').notNull().references(() => organizations.id),
  name: varchar('name', { length: 255 }).notNull(),
  address: jsonb('address'),                            // nullable
  timezone: varchar('timezone', { length: 50 }).notNull().default('UTC'),
  contact: jsonb('contact'),                            // nullable
  ...
});

API zod (apps/api/src/routes/orgs.ts):

const siteBaseSchema = z.object({
  orgId: z.string().uuid(),
  name: z.string().min(1),
  address: z.any().optional(),
  timezone: z.string().optional(),
  contact: z.any().optional(),
  settings: z.any().optional()
});
const createSiteSchema = siteBaseSchema.extend({ timezone: z.string().default('UTC') });

So the API accepts { orgId, name } and the DB happily stores it (timezone defaults to UTC server-side). The form is the only layer that demands the rest.

Why this matters

This bites at the site layer specifically — not the organization layer. Organizations usually have an address you can put on a contract; sites underneath them often don't.

• It's normal for an MSP to manage sites where the physical address is genuinely unknown — a remote employee's home office, a satellite location nobody from the MSP has ever visited, a cloud-only workload, a co-working space the customer rotates through. The site needs to exist so devices can enroll under it; the address may never get filled in.
• For new customer onboarding, the metadata often isn't known on day one even when there is a real address. The site needs to exist immediately; the rest trickles in.
• The contactPhone: z.string().min(7, ...) floor isn't really a phone-format check — it just refuses any empty value. Plenty of sites have no phone contact and the form should let them say so.

The form essentially refuses to create a site for any of those cases, even though the rest of the system has no problem with it.

Proposed change

Relax the frontend siteSchema in apps/web/src/components/settings/SiteForm.tsx so it only enforces what the API actually requires:

const siteSchema = z.object({
  name: z.string().min(1, 'Site name is required'),
  timezone: z.string().optional(),
  addressLine1: z.string().optional(),
  addressLine2: z.string().optional(),
  city: z.string().optional(),
  state: z.string().optional(),
  postalCode: z.string().optional(),
  country: z.string().optional(),
  contactName: z.string().optional(),
  // Email is optional, but if supplied it must be valid.
  contactEmail: z.string()
    .optional()
    .refine((v) => !v || /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(v), 'Enter a valid email address'),
  contactPhone: z.string().optional()
});

Two-line behavior change:

• Required: Site name only.
• Email field: validates format only when non-empty. Empty is fine.
• Everything else: optional.

Default on the timezone field stays 'UTC' so users don't have to change it; the API's .default('UTC') makes that even safer.

Happy to open a PR if there's interest. Tiny diff, no API or DB change required.

[ToddHebebrand]

Green light — PR welcome. The form is over-validating and the use cases you listed (cloud-only sites, remote employee home offices, day-one onboarding) are all real.

Couple of small preferences on the relaxed schema:

• name: required, as proposed.
• timezone: optional in the zod, but if the user touches the picker at all, validate it against a real IANA list so we don't store garbage. Server default to 'UTC' if omitted is correct.
• Contact email: if present, validate format. If absent, allow it.
• Contact phone: drop the min(7) entirely. If a user enters something, store it as-is — we don't format-validate phones anywhere else.
• Address fields: all optional, as proposed.

Worth a small note in the modal's empty state ("Address and contact are optional — you can fill these in later") so users don't think the form is broken.

[ToddHebebrand]

Shipped in #708 (merged f2d9cd3f, 2026-05-17). Form now mirrors API contract: only name required, address/contact fields optional, min(7) phone floor removed, email format-validated only when present. Closing as completed — thanks @bdunncompany.