Support
Overview
Waldur exposes a "Support" interface so consumers and providers can raise tickets without leaving the portal. Tickets can live entirely inside Waldur or be brokered to an external service desk (Jira Service Management, Zammad, SMAX). The ticket lifecycle is the same regardless of backend — what changes is where the canonical record lives.
Topology
Key concepts
| Concept | One-liner |
|---|---|
| Issue | A single ticket, with a type (incident, request, change, ...). |
| Comment | A reply on an issue, by the reporter or staff. |
| Attachment | A file attached to an issue or comment. |
| Backend | The system of record — built-in, Jira, Zammad, or SMAX. |
| Mapping | How Waldur issue types and statuses translate to the backend's. |
Backends at a glance
| Backend | When to use | Where data lives |
|---|---|---|
| Built-in | Small deployments; no existing service desk. | Waldur DB. |
| Jira SM | Existing Atlassian estate; rich SLA tooling. | Jira. |
| Zammad | Open-source preference; multi-channel support. | Zammad. |
| SMAX | Enterprise ITSM integration. | SMAX. |
Setup lives in admin-guide / service-desk and the integrations/service-desk area for SMAX specifics.
Lifecycle
- User opens Support in the portal and creates an issue.
- Waldur posts the issue to the configured backend; the backend assigns an ID and returns it.
- Comments and status changes sync bidirectionally on the configured cadence.
- When the backend marks the issue resolved, Waldur reflects it in the portal.
A status mismatch usually means the type/status mapping is out of date — see the per-backend configuration page.
Related concepts
- Platform — who can see which tickets (role-scoped).
- Marketplace — "support" can also be an offering type, with each order opening a ticket.