Add multi-select required info field type

Objective

• Add a multi-select type for required info fields on the work so teams can store several chosen values in one field instead of splitting across multiple single-select fields or ad-hoc text.
• Settings product track and SE request—treat as a first-class type alongside existing field kinds in company configuration and job forms.

Background

• Single-select and text-style custom fields are a poor fit when the business concept is “pick all that apply.”
• Decision needed which custom field system this extends—Attik-native job fields, settings-driven definitions, and/or Spectora-linked fields. The required service info system already models several input kinds in settings UI (attik-frontend/src/app/tools/settings/required-service-info/) and stores values on the job; worklists and sync also reference “custom field” conditions (attik-backend syncCustomFields usage from worklist routes), so requirements may span more than one surface.
• Decision needed on storage shape: array of strings, ordered vs. unordered, and max selections; and on export and search (worklist filters) semantics when values are multi-valued.

Scope

Frontend — settings / workorder entry

• Trace where field type is configured for custom / required info in attik-frontend/src/app/tools/settings/required-service-info/ (list items, type pickers) and add multi-select as a first-class type with an options list similar to select.
• On the workorder, rendering likely parallels RequiredInfoResolver patterns (attik-frontend/src/components/scheduling/RequiredInfoResolver.tsx) for select—decision needed whether workorder and internal quote paths share the same control.
• Client / portal visibility: decision needed if multi-select displays on client-facing pages when a field is exposed there.

Backend / API

• Extend validation and PATCH payloads for inspection/job payloads to carry an array of selected values; align with any Mongo schema for embedded field values. Follow existing patterns for requiredInfoValues or the relevant custom field bag—locate the exact model in attik-backend for the field type being extended before hardening (no guesswork on collection name; search for the feature flag / module used for “custom field” in settings).
• If Spectora-mirrored custom fields are in scope, coordinate with syncCustomFields and any Spectora template typing—decision needed on whether v1 is Attik-only types.

Reports / worklists

• If worklists or data exports can filter on these fields, extend filter builders in data export and worklist conditions to handle any-of / contains semantics for multi-value fields—decision needed.

References

• attik-frontend/src/app/tools/settings/required-service-info/RequiredInfoListItem.tsx — how field types and options are edited
• attik-frontend/src/components/scheduling/RequiredInfoResolver.tsx — existing select and other types on job forms
• attik-backend/src/routes/worklist.ts / util/functions/spectora/syncCustomFields.ts — when custom field sync and filters are involved (follow imports)

---

Transcript context

The Monday kickoff clarified why this is larger than a simple new field type. Chris called out that if multi-select is added here, the team also needs to update conditional logic, conditional resolvers, and email/template rendering so multi-value fields are handled consistently rather than left half-supported.