[Decision] ADR-0142 D3: inject the queue column on every ownership: 'user' object (the default, so every business object today) or only where an object opts in (Salesforce "Allow queues") #26359

Ruled: 6429748166 · letter A · 2026-10-26T23:28Z

Filing gate: ② a decision only the maintainer can make. Filed by the director seat (session_01KrKXQVvgYk2AJ4VkqMobyb, ledger objectstack#12708) after the maintainer asked, on 2026-10-26 in the director summon chat, 「帮我评估26337，是不是大部分业务对象都要加个字段？」 and 「salesforce也是这么设计的吗？」, then 「立决策卡」. ⛔ Not a claim. Reader: the lane that carries PR #26337 (#25769) — the ruling changes what that PR injects, or confirms it. Dedupe: REST list of the 124 newest open + closed issues, grep queue.*(column|inject|opt-in|allow queues|per-object) → 0 (control queue → 8); objectstack-ai/hotcrm#2395 and PR #26337 are the carrier, not duplicates. New.

维护者速读

ADR-0142 D3（已接受）规定：queue 列由 applySystemFields 注入到所有 ownership: 'user' 的对象上，与 owner_id 同一批。ownership 省略即为 user（object.zod.ts 的枚举默认），实测本仓 app-crm 6 个、app-showcase 19 个对象文件没有一个显式声明 ownership，sys_ 命名空间按既有规则跳过。所以 PR #26337 落地后，每一个业务对象都会多一列 queue（文本列，存队列机器名，系统列、可写、非 lookup）。这是 ServiceNow 的形状（assignment_group 在每张任务表上）。Salesforce 不是：它的 OwnerId 可以指向 User 或 Queue（多态 owner），而且队列按对象开关——队列只对「Allow queues」里勾选的对象（Lead、Case、Custom Object 等）可用，Account/Contact/Opportunity 不能进队列。本卡只裁一件事：列是「默认全注入」还是「对象显式打开才注入」。不裁 owner 多态（ADR Alternatives 2 已否，维护者接受合并问题 1 时已裁）。

One-sentence problem

After PR #26337 every business object in every app gets a queue column whether or not that object will ever sit in a queue; the alternative is an explicit per-object switch, which is one more permanent key and one more way for a queue to silently not apply.

Governing text

• ADR-0142 D3 (docs/adr/0142-ownership-queue-membership-claim-and-assignment-rules.md): "applySystemFields injects queue … on exactly the objects it injects owner_id on (ownership: 'user'), and withholds it under the other three tiers." An eligible object declaring its own queue field is refused at registration (merge question 15).
• ADR-0142 D1: "A queue is a named, organization-scoped set of people that records of any ownership: 'user' object can sit in." Queues are not bound to objects; assignment rules (D5) are declared per object.
• ADR-0142 Alternatives 2 (owner points at the queue, Salesforce) and 3 (queue-item join, Dataverse): both rejected; merge question 1 restates the cost and was accepted by the maintainer when the ADR merged. This card does not reopen placement.
• packages/spec/src/data/object.zod.ts ownership: z.enum(['user', 'business_unit', 'org', 'none']) — user is the default; the description says user "injects reassignable owner_id plus owning_business_unit_id".
• ADR-0117 D1: the precedent — owning_business_unit_id is injected by the same ownership axis, default tier included, with no per-object opt-in. ADR-0078 forbids an inert column; ADR-0049 enforce-or-remove applies to any new switch.

Premises (re-check before ruling)

• P1 — no object in the two example apps declares ownership, so all default to user and would receive queue:
  for d in examples/app-crm examples/app-showcase; do find $d -name '*.object.*' -not -path '*/node_modules/*' -not -path '*/dist/*' | wc -l; done → 6, 19; grep -rl '^\s*ownership:' --include='*.object.*' examples → 0. packages/platform-objects (52 files) are sys_ and skip injection by the existing rule.
• P2 — D3 ties queue to the user tier, not to a queue or rule declaration: grep -n "on exactly the objects it injects" docs/adr/0142-*.md → 1 line.
• P3 — PR feat!: ownership queues and assignment rules (ADR-0142 phase 2) #26337 (draft, +6351/−396, 183 files, "Part of spec+server: an ownership queue primitive (queue entity, membership, claim) and declarative assignment rules, so an app routes ownerless records without app-level round-robin (maintainer ruling D6 = A) hotcrm#2395") implements D3 as written: read its applySystemFields change before ruling; if the PR already narrows injection, this card's option A is already not what is on the branch.

Options × real cost × effort

Business meaning

• A = ServiceNow: every task table has an assignment group field; routing is a property of the platform's work model, not of each table.
• B = Salesforce: "Allow queues" is a per-object setting; most objects cannot be queued, and that is a deliberate product choice an admin makes once per object.
• C = a column that appears when a package that routes the object is installed — closest to Dataverse's "enable queues for this table" but derived rather than declared.

Four axes (business standpoint)

os-decision-facets

• ① 项目长远合理性：两年后平台的工作模型里，队列和责任人是同一轴上的两个落位（坐在队列里 / 由某人负责），任何有责任人的对象都应能进队列——这是 A。B 把「能否进队列」做成对象级特例，契约多一个永久键、注入规则多一条分支；C 把列的存在交给安装顺序，是最大的特例增生。参照：ServiceNow 任务表全带 assignment_group；Salesforce 的按对象开关是其多态 owner 时代的产物，而本仓已否定多态 owner（Alternatives 2）。
• ② 实际业务拉动：今天撞上的是 HotCRM 的 case/lead 分流（#25769 的拉动方）；没有任何客户要求「某对象不得进队列」。B/C 的拉动为零，是对列数的观感担忧。
• ③ 防 AI 犯错：A 下出错只有一种形态——对象自己声明了 queue 字段，注册时响亮拒绝（D3 已定）。B 下 AI 写了分配规则却忘了开开关，若不加注册拒绝就是静默不生效；加了拒绝则多一条门。C 下错误形态是「换个安装顺序列就没了」，最难排查。
• ④ 创业阶段不扩散：A 不新增任何声明键；B 新增一个必须永久维护、文档、校验、生成基线的键（ADR-0049 enforce-or-remove 立刻适用）；C 新增 objects: 列表与注册序依赖。新增门禁默认否。

Prior rulings read: queue, ownership, owner_id, Allow queues → 8 hits (none on per-object opt-in); ADR-0142 D1/D3 + merge question 1 accepted; thread: objectstack-ai/hotcrm#2395, PR #26337.

Recommendation + confidence gap

A. ① alone picks A: the two-year platform shape is "any owned object can sit in a queue", and the maintainer already accepted D3 and merge question 1. B is not taken because its only gain is fewer empty columns, paid for with a permanent key and a new silent-failure face. C is not taken because it makes a system column's existence depend on install order.
Self-check: 只看①选 A；②③④ 是否翻转：否。
Gap: the seat has not measured what the empty queue column costs in Studio field lists and CSV exports (one extra system column alongside owner_id, created_by, owning_business_unit_id); if the maintainer's concern is that visible clutter rather than the schema, the remedy is a presentation rule for system columns, not an injection switch, and would be a separate card.

After the ruling

• A: no code change. The lane carrying PR feat!: ownership queues and assignment rules (ADR-0142 phase 2) #26337 adds one line to ADR-0142 "Open items" citing this ruling (Ruling-ref:) and lands it inside that PR (the ADR is Tier H; the PR is already a governed draft and lands by maintainer approval). Card closes completed on the PR's merge.
• B: the lane opens an ADR-0142 amendment PR (Tier H) naming the key, the registration refusal for rules/queues on non-opted objects, and the example-app opt-ins; PR feat!: ownership queues and assignment rules (ADR-0142 phase 2) #26337 is revised after the amendment merges. This card stays pm:queue as the amendment's carrier.
• C: as B, plus a registration-ordering design in the amendment; the seat recommends against it and would ask for a second reading before any code.

Size: A: XS · B: M · C: L. Clause-②: no. Metadata-protocol: A none · B/C yes (new authorable key or list on object).

Related

objectstack-ai/hotcrm#2395 (parent, pm:dispatched); PR #26337 (draft implementing ADR-0142); ADR-0142 D1/D3/D5, Alternatives 2–3, merge question 1; ADR-0117 D1 (owning_business_unit_id injection, same axis); ADR-0078 (no inert column); ADR-0049 (enforce-or-remove).