A 311 escalation procedure must reject unknown category codes with a structured error before any escalation row is written. Where should that validation live?
Select an answer to reveal the explanation.
Short Explanation
You want the category check inside the stored procedure, so an unknown code gets a clear error before any escalation row is written. A client-side dropdown helps guide you, but it can’t stop codes submitted through other routes.
Full Explanation
A 311 escalation procedure must validate category codes at the server-side write boundary. Put the check inside the stored procedure, using an allowed-category table or explicit allow-list, and raise a structured error with a predictable number and message when a code is unknown. This prevents invalid codes from inserting escalation rows even when callers bypass the client, and gives you a consistent error to show the operator. A client-side dropdown with no server-side check can improve the user experience, but alternate APIs, scripts, or integrations can submit unlisted codes. A full-text catalog is designed to search document text; it does not enforce category membership or raise structured domain errors during a write. A vector index supports approximate nearest-neighbor search for semantic similarity, not exact allow-list validation before insertion. Exam caveat: when the data model allows, pair procedural validation with a declarative constraint such as a foreign key to the category table; the procedure can still provide the structured error experience and handle multi-step escalation logic. Practical check: call the procedure with an invalid category and confirm that no escalation row appears and the error number and message match the contract, then use a valid category and confirm that the row is inserted.