Resident Submission
Residents submit tickets via the mobile app, web portal, or through staff on their behalf.
Assignment & Routing
Tickets are routed to the right employee or team, with optional auto-assignment rules.
Status Tracking
Six lifecycle statuses keep everyone informed from open to closed.
Feedback & Quality
Residents rate completed work; managers score quality control.
Ticket Lifecycle
Ticket Created
A ticket enters the system with status
new_or_reopened. It can be created by a resident through the mobile app (MOBILE_APP_RESIDENT), by staff via the web app (WEB_APP), by phone call (CALL), email (EMAIL), or imported from an external CRM (CRM_IMPORT).Processing
A manager or dispatcher assigns an executor and moves the ticket to
processing. The ticket gains an assignee (accountable person) and an executor (person doing the work).Deferred (optional)
If work cannot start immediately, the ticket moves to
deferred. By default it stays deferred for 30 days (DEFAULT_DEFERRED_DAYS), after which it returns to new_or_reopened.Completed
The executor marks the ticket
completed. Residents receive a push notification and can leave feedback.Tickets can also be
canceled (declined) at any point. The canceled and closed statuses are terminal — no further transitions are allowed.Ticket Statuses
Condo defines six status types indomains/ticket/constants.js:
| Status | Type Constant | Description |
|---|---|---|
| Open / Reopened | new_or_reopened | Newly created or returned after completion |
| In Progress | processing | Actively being worked on |
| Deferred | deferred | Postponed, with an optional deferredUntil date |
| Completed | completed | Work finished, awaiting feedback |
| Canceled | canceled | Declined without resolution |
| Closed | closed | Fully resolved and archived |
processing, deferred, or canceled — but not directly to closed.
Classifiers
Every ticket is categorized using a three-level classifier hierarchy stored in the required fieldsplaceClassifier, categoryClassifier, and problemClassifier.
- Place classifier — Where the issue is (e.g., entrance, apartment, roof)
- Category classifier — What type of work is needed (e.g., plumbing, electrical)
- Problem classifier — Specific problem description
PredictTicketClassificationService can suggest classifiers automatically based on the ticket’s details text.
Creating a Ticket
Required fields when creating a ticket (REQUIRED_TICKET_FIELDS):
clientName— Resident’s display nameclientPhone— Normalized E.164 phone numberclientEmail— Normalized email addressunitName/unitType— Apartment or premises identifier
Assignment
Assignee
The staff member responsible for the ticket outcome. Receives notifications when assigned.
Executor
The person physically performing the work. Can differ from the assignee.
TicketAutoAssignment rules to automatically assign tickets based on property, classifier, or other criteria.
Bulk updates are supported for executor and assignee fields via TicketMultipleUpdateService.
Deadlines
Each ticket has adeadline field. The default deadline duration is 8 days (DEFAULT_TICKET_DEADLINE_DURATION = 'P8D'), and organizations can configure separate deadlines for paid, emergency, and warranty tickets:
defaultDeadlineDurationpaidDeadlineDurationemergencyDeadlineDurationwarrantyDeadlineDuration
isCompletedAfterDeadline = true for reporting.
Comments & Attachments
Tickets support two comment types defined inCOMMENT_TYPES:
organization— Visible to staff onlyresident— Visible to the resident
MAX_COMMENT_LENGTH). Files can be attached via TicketFile (on the ticket itself) and TicketCommentFile (on individual comments).
Resident Feedback
Once a ticket is completed, residents can rate the work usingfeedbackValue:
| Value | Meaning |
|---|---|
good | Satisfied |
bad | Unsatisfied |
returned | Requesting rework |
feedbackAdditionalOptions such as highQuality, lowQuality, quickly, or slowly, along with a free-text feedbackComment.
Quality Control
Managers can independently score completed work usingqualityControlValue (good or bad) with the same set of additional options. Quality control fields are only writable by staff, not residents.
Incidents
For large-scale issues affecting multiple properties, Condo provides anIncident model. Incidents can be linked to multiple properties via IncidentProperty and associated with classifiers via IncidentClassifierIncident.
Ticket Sources
Thesource field records how a ticket entered the system:
All ticket source types
All ticket source types
| Source | Constant |
|---|---|
| Mobile App (Resident) | MOBILE_APP_RESIDENT |
| Mobile App (Staff) | MOBILE_APP_STAFF |
| Web App | WEB_APP |
| Web App (Resident) | WEB_APP_RESIDENT |
| Phone Call | CALL |
EMAIL | |
| Site | ORGANIZATION_SITE |
| Messenger | MESSENGER |
| Social Network | SOCIAL_NETWORK |
| Remote System | REMOTE_SYSTEM |
| CRM Import | CRM_IMPORT |
| In-Person Visit | VISIT |
Export & Reporting
Tickets can be exported to Excel viaTicketExportTask. Document generation (e.g., PDF act of completion) is available through TicketDocumentGenerationTask. Saved filter presets can be stored as TicketFilterTemplate records.
Notifications
Condo automatically sends push notifications at key lifecycle events:TICKET_CREATED— When a new ticket is submittedTICKET_ASSIGNEE_CONNECTED— When an assignee is setTICKET_EXECUTOR_CONNECTED— When an executor is setTICKET_STATUS_IN_PROGRESS— When work beginsTICKET_STATUS_COMPLETED— When work is finishedTICKET_STATUS_DECLINED/TICKET_STATUS_RETURNED— On decline or returnTICKET_COMMENT_ADDED— When a new resident-facing comment is posted