Every helpdesk promises fast response times. The hard part isn’t writing that promise down. It’s enforcing it automatically, per tenant, without hard-coding any one organisation’s rules into the application.
When we built the Ticket Management System (TMS) module on One Platform, the brief was simple to state and difficult to deliver. Every tenant needed its own SLA tiers, its own escalation path and its own idea of “urgent”, all running on the same codebase as ten other modules. You can see the module itself in our multi-tenant helpdesk case study.
The problem with hard-coded SLAs
The obvious first approach is to define fixed tiers, such as Urgent, High and Normal, with fixed response windows, and ship it. That works for exactly one tenant. The second tenant wants four tiers. The third wants escalation to skip a level for one department. Hard-coding any of that means a fork, and forks are how “one platform” quietly becomes six platforms nobody wants to maintain.
What we made configurable per tenant
- Auto-assignment strategy: round robin, load-balanced or skill-based, set per department
- SLA tiers and breach thresholds, monitored continuously and escalated automatically
- Tenant branding across the portal and every notification email
Where the logic actually lives
What made this manageable was keeping SLA rules as tenant-scoped configuration, not application logic. A dedicated monitoring service checks open tickets against each tenant’s thresholds. When a breach is close, the notification layer, already wired for email and REST providers, fires the escalation. The ticketing service never needs to know whose rules it is enforcing.
The moment SLA rules stopped being “if” statements and became rows in a settings table, onboarding a new tenant stopped being an engineering task.
Platform engineering, Cloudsoftera
Escalation, not just alerts
Breaches go to a manager automatically, not to a log line someone might notice later.
The same security layer, no exceptions
Every SLA rule still respects the role and tenant boundaries enforced upstream by the shared sign-in service.
What this means for new tenants
A new client onboarding onto TMS today doesn’t wait for a development sprint to get their SLA structure right. Their rules, branding and routing are set through configuration screens, on the same unchanged codebase that serves every other tenant.
No comments yet. Start the discussion.