Pick an option on each card and press Done; your answer goes straight
back to the session. The raiser's pick is marked. "I'm not sure" and "Take it to the engineering bridge" are real answers.
1
In plain terms. Should an emergency call on a shared company line ring the company's on-call list even when we can't match the caller to one specific building?
The full question, as raised
voice-postcall-intake.ts's startEmergencyChainWithoutWorkOrder bails out (logError only, no alert) whenever conversation.propertyId is absent -- the company-wide-line case (no building pinned) -- even though lineOrganizationId is available at the call site and resolveEmergencyHandoff/emergencyAlertChainOnCallPeople already support an org-level (propertyId: null) on-call lookup. b91532222 just ruled the sender-number question for 'building has no line of its own' (reuse the new sign-in number, never a customer line). Should the company-wide-line + unresolved-caller emergency case be wired to ring the org-level on-call list using that same last-resort sender, or is logging-only the intended behavior here?
Why, and what was tried
The session raising this recommends: Yes, ring the on-call list The org-level on-call lookup and the last-resort sender number both already exist from today's related work -- the only reason this case goes silent is nobody connected them, and a resident's flooding/no-heat report deserves a page even without a building match Tried first, unsuccessfully: Traced today's new Sentry alert to this exact code path, confirmed conversation.propertyId is genuinely absent for company-wide-line calls, confirmed the org-level emergency-routing resolver already works without a property, and found a same-day related ruling (b91532222) on the sender-number question for buildings with no line of their own -- but found no open decision covering ringing with NO resolved building at all, and a driver (b723b025) is actively working this same emergency-routing area today so I raised rather than shipping a fix that might collide with it