Support requests
Reuse a project as an internal support queue, with assigned request tasks and investigation comments.
Organize an internal queueLink to section
Start with a Product support project. Each task represents one request; its comments hold investigation notes. This is a manual internal workflow over the existing model, with no new schema or provider.
| Your vocabulary | Existing model | Example |
|---|---|---|
| Queue | Project | Product support |
| Request | Task title and description | CSV export misses the last column |
| Agent and target date | Responsible membership and task due date | A teammate and a chosen calendar target |
| Investigation | Task comments | Reproduced with a synthetic CSV; fix ready for review. |
Try the workflowLink to section
Open the queueLink to section
Create the Product support project and describe its scope. Keep the queue project active while the team is handling requests.
Record a requestLink to section
Create the example task with expected/observed behavior and safe reproduction steps. Assign an active teammate and choose a target date.
Investigate and resolveLink to section
Move TODO to IN_PROGRESS, add an internal comment, then reload. Record
the resolution and mark the task DONE. Return it to IN_PROGRESS if work
resumes; no enforced ticket-transition state machine is added.
Keep queue and request states separateLink to section
Closing one task does not close the queue project. Archiving the project blocks task/comment changes for every request in it until restored.
Internal notes and calendar targets
Comments are visible to workspace members and are not replies to customers. A task due date does not send reminders, measure response time or enforce an SLA. Email ingestion, customer replies and a customer portal are extensions.
Adapt the presentationLink to section
The shipped docs/recipes/support-requests.md includes source entry points and
an assistant prompt. Reuse the task view, validated fields and workspace service.
Add localized queue/request labels in that view without changing the shared
status codes. The assignee is a workspace membership, not a requester identity
or a permission that hides the ticket from other members.
Check before adoptingLink to section
- MEMBER can create, assign, edit and comment on requests, and remove its own notes.
- OWNER/ADMIN can delete tasks and moderate other members' comments; MEMBER cannot.
- Foreign record IDs and revoked memberships are rejected.
- Resolution and reopening preserve the discussion; archiving blocks work changes.
Priority, customer references, attachments, waiting-for-customer states and mailbox automation need explicit domain fields or integrations. Define them before presenting the adaptation as a complete help desk.