How do you run five different kinds of customer request through one help desk?

01The business problem

A manufacturer sells through a network of independent distributors. Those distributors need things from the manufacturer constantly, and the requests are not all the same shape:

• A purchase order to be processed against agreed pricing
• A quote request for a list of parts, with quantities and a need-by date
• A new-product request — something not in the catalogue, which needs engineering feasibility and sign-off from six internal departments before a price can be given
• A material certification request for a specific production lot, to satisfy an end customer's compliance file
• A general question or complaint that fits none of the above

Before the project, all five arrived as email and phone calls to shared mailboxes. Nothing had a reference number, nobody could answer "where is my request?" without asking a person, and there was no way to see how long anything had taken.

What the business asked for was one help desk, with:

• a single queue and a single reference-number series, so any request can be quoted in an email;
• one status lifecycle everyone understands, from new through to solved;
• distributor self-service — submitters see their own requests and nobody else's;
• a conversation thread per request, with a strict split between what the distributor sees and what stays internal;
• an audit trail of who changed what, when;
• and, for new-product requests only, a formal multi-department approval.

The tension is entirely in the combination. Uniformity is wanted for the queue. Divergence is required in the content: a certification request needs a lot number and a heat number, and has no use for a delivery date; a quote request needs a repeating set of part lines, which a general question never has.

02Why the obvious approach fails

There are two first instincts, and both are wrong in a way that costs a rebuild.

Instinct one: one entity plus a "Request Type" dropdown

This is the reflex, because a dropdown is the cheapest thing to create. It fails on a specific, structural point: a dropdown value cannot select a form.

Coevera binds one editable form layout to each CustomEntityType. There is no mechanism for a custom field's value to swap the layout. So with a dropdown you get exactly one form for all five types, carrying the union of every type's fields — in this build that is 42 fields, of which roughly a dozen apply to any given request. Distributors are asked for a lot number on a purchase order. The form cannot be made to make sense.

Two further consequences, less obvious but just as damaging:

• Mutability. typeId is set at creation and is immutable — the platform enforces it, no guard automation required. A dropdown is editable by anyone with field access, so a purchase order can silently become a certification request halfway through its life, invalidating every report built on it.
• Redundancy. Every record would then carry two answers to the same question — its real typeId (which exists whether you use it or not) and your dropdown — with nothing keeping them in agreement.

Instinct two: five separate custom entities

The opposite reflex: if the five types are genuinely different, model them separately. This produces clean forms, and loses everything the business actually asked for:

• Five reference-number sequences instead of one shared series
• No single queue. "Show me everything open for this distributor" becomes five list views a human has to mentally merge
• Five field pools to keep in step. Status, severity, submitter, SLA target and a dozen more are common to all types; now they exist five times and drift
• No in-place conversion. A general question that turns out to be a new-product request cannot become one — it has to be retyped into a different entity, losing its history and its reference number
• Every report is a five-way union, and every new type makes it a six-way union

03Data model

One custom entity, Case, with five CustomEntityType records beneath it. Two supporting custom entities, and three extensions to built-in entities.

The case entity and its sub-types

All 42 custom fields are created once, against the parent entity. The five sub-types share that single field pool; each one's form definition selects the subset relevant to it. This is the property that makes the whole pattern pay off — 13 fields are common to all five types and are defined and maintained exactly once.

Everywhere a per-type distinction is needed — form selection, automation triggers, saved views, API filters — the type is addressed by typeId or type.name directly. No wrapper, no custom field, no synchronisation logic.

Supporting entities

The Note entity is the pattern applied a second time, at smaller scale: rather than a custom "is internal" boolean, visibility is carried by typeId. Two sub-types, no flag to get wrong, and automation filters on the type directly. Author and timestamp come from the native owner and created fields — no custom fields needed for either.

Built-in entities, extended

04Field-level configuration

42 custom fields on Case, distributed as 13 common plus a per-type tail:

Field naming follows the platform's own convention — custom fields are prefixed cf_, dropdown and lookup fields carry an _id suffix because they resolve to option or record UUIDs rather than literals, and lookup fields are named for the relationship they express. Field names in this blueprint are anonymised; the shapes, types and relationships are as built.

Per-role field permissions

Three roles, and the visibility split is enforced at field level rather than by hiding things in the UI: None, Read, or Full per field per role.

05Automation & logic

Nine automation processes, all space-scoped. The organising rule: one process per concern, filtered by typeId. Because all five sub-types share one entity, each process is defined once and a filter node early in the graph narrows it to the types it applies to — rather than five near-identical copies.

Two patterns worth lifting

The one-shot guard. To capture "whoever first accepted this" without re-stamping on every later update, filter on the target field being empty and set it to the acting user. The condition makes the write idempotent — no separate "has this run?" flag.

Ownership stays put. The distributor who submitted the case remains the record owner for its whole life; the internal analyst is captured in a separate lookup field. The instinct is to reassign ownership to the analyst on acceptance — but ownership is what drives the distributor's access to their own record. Reassigning it would remove the submitter's visibility of their own request.

06Limits & trade-offs

Approval processes cannot target a custom entity

Only one of the five types — new-product requests — needs formal sign-off, from six departments. The pattern that works is a proxy on Quote:

1. A new-product-request case is created.
2. A process spawns a linked Quote under a dedicated quote type reserved for approvals.
3. The approval process runs on that Quote, natively, with the standard approval UI and audit trail.
4. The Quote carries a lookup back to the case; the platform maintains the reverse link automatically.
5. On decision, a second process writes the outcome back to the case status.
6. The Quote can be archived afterwards.

Why Quote and not Opportunity, given both can host an approval:

• Semantic fit. A new-product request is a pricing decision — "can we make this, and at what price?". Quote models that. Opportunity-as-deal is the wrong framing.
• No pipeline pollution. Opportunity proxies would appear in the deal pipeline and contaminate forecasting and revenue reports. A Quote sits in its own quote type, out of the way.
• The price is captured natively. The Quote's line items are the proposed price — so no custom price field on the case is needed at all.
• Built-in expiry. Quote has a native expiration date, useful for time-boxing an approval request.

Two rollup fields on the case surface the proxy's state — approval status and rejection reason — derived from the linked Quote rather than stored. No write-back logic needed for those; the platform refreshes them when the Quote changes.

Built-in notes could not express two-tier visibility

The requirement is a single thread where some entries are visible to the distributor and some are strictly internal. The built-in note functionality has no visibility dimension, so the thread became a custom entity with two sub-types. A cost worth being explicit about: the case therefore has both built-in notes and a custom note thread, and the built-in one has to be kept off the forms to avoid two competing places to write.

Free-text fields cannot drive distribution lists

The notify-contacts field began as a text area for typing email addresses. It was replaced with a multi-select lookup to Contact, because automation cannot reliably parse addresses out of free text to build a recipient list. If a field's value needs to be acted on rather than only read, it has to be a typed reference.

Other constraints hit in this build

• A field must be on the form to work. Calculated fields and AI-populated fields that are absent from a record's form layout silently do nothing — they do not compute and they do not error. Form membership is functional, not cosmetic.
• Sequences cannot reset annually. The native sequence counter increments on creation and has no yearly reset. A year can be composed into the number as a prefix, but the counter itself runs continuously.
• Space-scoped processes need session-authenticated credentials. Personal-access API credentials are rejected when writing space processes, even though they can read them.

Known gaps in this build

Reported rather than omitted:

• The approval write-back handles the approved branch only. A rejected proxy leaves the case in its working state with no automatic propagation — a parallel filter is needed for the rejected outcome.
• The audit-note process fires on every case update rather than only on status changes; it needs a changed-fields condition to stop being noisy.
• SLA target dates are set manually. Deriving them from severity was designed and deliberately deferred.

07Verification

Sub-type designs fail quietly — a form that renders, a process that reports success, and a discriminator wired to the wrong thing. What was actually checked:

• Field inventory read back per entity. Every field re-read from the API after creation and reconciled against the spec by API name, not by label. Three fields had come out with names differing from the spec, and one had silently not been created at all — neither visible from the UI.
• Sub-type count and identity. Confirmed five sub-types exist under the case entity and no orphan sixth — the auto-default trap from §3 shows up exactly here.
• Discriminator immutability. Attempted to change typeId on an existing record and confirmed the platform refuses.
• Per-role field access, tested as each role. Not read from the configuration — logged in and confirmed the fields that should be invisible to a distributor are actually absent.
• Each process confirmed enabled, and its node graph read back. Two processes were enabled but stopped at placeholder nodes — they reported success and did nothing. This is the check that found the approval write-back gap.
• One end-to-end pass per sub-type in the UI: create, advance through the lifecycle, confirm notes and emails land, confirm the distributor view shows only what it should.

What would signal a regression: cases appearing with an empty or wrong sub-type; the assigned-analyst field changing after first acceptance; notes reaching a distributor that were written as internal; new-product requests with no linked approval proxy.