- Shipped
- April 19, 2026 at 10:17 PM UTC
- Author
- Kamo
- Commit
- 4149b1b
The previous behavior deleted any existing app-config row whose ServiceType wasn't in the incoming payload. That turned partial payloads into silent data-loss: a UI that happened to know about only 15 of the 20 ServiceTypes would blow away the 5 rows it hadn't seen, effectively forcing those apps to NOT_AVAILABLE. In one reported case, disabling CRM on a master model also wiped AI_SUPPORT, SUPPORT, KNOWLEDGE_BASE, NOTES, POS, DOCS, MEET, and CALCULATOR configs. When the admin re-enabled CRM, only CRM came back because the deleted rows were gone for good. New semantics: rows present in the payload are upserted; rows absent from the payload are left alone. The canonical way to "turn off" an app is to send it with availability = NOT_AVAILABLE — its state, not its presence, is what matters.