Intake and Triage

Work does not only start in FlightDesk. A Slack command, a synced Notion board or your own script can file it, and FlightDesk keeps track of who asked and whether a person has accepted it yet.

Filing Work From Outside

upsert_task_by_source (MCP) / userUpsertTaskBySource (GraphQL) creates or updates the task bound to an external item, identified by sourceSystem plus sourceRef:

{
  "projectId": "…",
  "sourceSystem": "slack-tech",
  "sourceRef": "<the source's own id>",
  "sourceUrl": "https://acme.slack.com/archives/C…/p…",
  "title": "The donate button is broken",
  "description": "…",
  "tags": ["staff-request"],
  "requester": { "name": "Ada Lovelace", "email": "ada@acme.org", "slackUserId": "U01ADA" }
}

It is idempotent: the same source item never creates a second task. The same call can set the task's initiatives, its target release, and its blockers (from the source's own "Blocked by" relation) — a reference to a task that does not exist yet comes back as unresolved rather than failing the call.

The full integration contract — every field, every matching rule, the exact request and response shapes — is written up for the two consumers that build against it, in the FlightDesk repository at docs/2026-09-28-requesters-and-status-report.md. Ask your FlightDesk administrator for it if you are wiring up a new intake source; what follows is the part a user needs.

Requesters

A requester is the person who asked for a task. Usually not a FlightDesk user, so it is stored as a contact of the organization rather than an account: a name, and optionally an email and a Slack member id.

A task has zero or one requester, and the same person asking twice is one contact. FlightDesk matches on Slack id first, then on email (case-insensitively), and only creates a new contact if neither matches. A name on its own always creates — names are not identifiers. A contact that is found is renamed to whatever name came with the latest request and gains any identifier it was missing, but its existing identifiers are never overwritten. Contacts never cross organizations.

The task page shows Requested by with Edit and Clear. Requesters can also be set through create_task / update_task and their GraphQL equivalents.

New Request Triage

A task created by upsert_task_by_source lands in Backlog with an open new request flag: "New request from <name or source>: <title>". Nobody is assigned as developer. It is routed to the project's triager — the triager role in question routing, else the organization owner, else an admin — who gets it on their Needs attention board and one work-waiting email.

An update to a task that already exists never raises the flag again.

The triager has four moves:

• Start planning — the task goes to Plan (subject to planRequired and any blockers)
• Keep in backlog — it stays, and the flag clears
• Ask the requester — records a question
• Archive — it goes away

Any human phase change, an archive, or an explicit clear will clear the flag with a note on the timeline. An agent cannot clear it, and an agent moving the task leaves it open — the point of the flag is that a person has looked.

Turn it off per project with Project Settings → Orchestration → Incoming requests ("New requests from intake sources wait for triage", on by default). Off, no flag is raised and no email is sent.

The Client Status Report

task_status_report (MCP) / userTaskStatusReport (GraphQL) returns a plain-language status for a slice of an organization's work — for a staff status page, or to answer "what is happening with the things we asked for".

Select the work by sourceSystems or tags (the two are OR-ed), narrow it with projectIds, and page it with limit (up to 200) and offset. includeDone defaults to true; doneSince limits shipped work to what went live since a given instant.

Each row carries the title, project and subproject, a status of NEW, IN_PROGRESS, NEEDS_FEEDBACK or LIVE with a human label, when it went live, its due date and estimate, its target and shipped releases, the requester's name only, the source system and URL, and a link to the task.

Nothing internal is included: no flag or question text, no agent or assignee names, no requester email. Archived tasks and archived projects never appear. A request that is still waiting for triage shows as New — the triage flag is FlightDesk's own business, not the requester's.