My Tasks and Approvals: Working the Review Queue

There are two queues in Quartyl and they are not the same thing, so it is worth being precise before you go looking for the second one:

• My Tasks / Approvals is the sidebar entry. It opens the study list (/studies), tabbed by workflow state. It is not a separate service, not a personal to-do store, and not filtered by your role — it is the whole visible book of studies, split by stage.
• The dashboard approval queue is the role-filtered one. It is computed server-side when the dashboard loads, from your role and the states that wait on it.

Both are views of the same ten states. Neither is an inbox: nothing is assigned to you as a task row, and nothing has to be cleared for the workflow to be healthy.

My Tasks / Approvals: the state-tabbed list

The nav item sits in the Command Center group, beside Dashboard, and routes to the study list. The tab set is identical for every role — analyst, manager, partner, firm admin:

Tab	States behind it
All	everything your account can see
Draft	DRAFT
Processing	STUDY_INITIALIZED, PROCESSING
In Review	IN_REVIEW
Report Generated	REPORT_GENERATED
Document Generated	DOCUMENT_GENERATED
Signed Off	SIGNED_OFF
Rejected	REJECTED
Failed	FAILED

Alongside the tabs are the search and the filters the list carries — jurisdiction, PLI, conclusion, sort — and pagination. Archived studies are reachable through All.

What this means in practice: your queue is a tab choice. In Review is the manager’s page of the book; Document Generated is the partner’s; Draft and Rejected are the analyst’s.

The dashboard approval queue, by role

The dashboard does role-filter, over the studies your account can see. There are exactly three rules (app/services/dashboard/dashboard.py), and it is worth knowing them precisely because they are narrower than the list:

Your role	What the queue holds	Task it represents
Analyst	Studies at DRAFT (high urgency — data still needs uploading and screening) and at REJECTED (medium — sent back, review and re-submit)	Data intake and rework
Manager	Studies at IN_REVIEW (high urgency)	The review decision: approve, or send back with reasons
Partner, Firm Admin, Superadmin	Studies at DOCUMENT_GENERATED (medium urgency)	Sign-off

Each entry carries the study name, the entity, a description and an urgency badge, and links into the study.

Two honest gaps, so you are not surprised by them:

• FAILED studies are in neither queue. A re-run is not queued for you; it is the Failed tab on the list.
• REPORT_GENERATED is not queued either. The document step between the workbook and sign-off does not raise a task for anyone — a study will sit there quietly until someone opens the tab and generates the document, which is what creates DOCUMENT_GENERATED and puts the study on the partner’s queue.

The dashboard’s KPI cards count the same states — Draft, In Review, Document Generated, Archived — so the queue and the numbers are drawn from one set of rows, over the recent window the dashboard loads rather than all history.

What acting on an item moves

An item is a state, and acting on it is the transition:

From	Action	To
DRAFT	Submit with the data file attached	STUDY_INITIALIZED, then the pipeline takes it into PROCESSING
IN_REVIEW	Approve	records the report request; the study reaches REPORT_GENERATED when the workbook is actually stored
IN_REVIEW	Send back with justification notes (required)	REJECTED, and a best-effort email to the assigned analyst
REJECTED	Re-submit	IN_REVIEW — straight back to the reviewer, no re-run
FAILED	Re-run	PROCESSING
PROCESSING	Cancel with notes (analyst, firm admin, superadmin)	DRAFT
DOCUMENT_GENERATED	Sign off	SIGNED_OFF
SIGNED_OFF	Archive (partner or superadmin only)	ARCHIVED — the lock, and the end of the road

The queue scope follows the account: you see the studies your tenant and role can see, and the list never shows what you cannot open. The permission to act is checked per transition on the server, so an item in your queue can still refuse you if the state and role do not line up.

Notifications: what tells you work arrived

There is no in-app notification centre, no unread badge and no counter on the queue — the queue itself is pull-based, computed from study states each time you load it. What does exist is a short list of transactional emails. All of them are best-effort, all of them link back to the study, and none of them gate the workflow:

Event	Who is mailed	The catch
Analysis completes	The creator	Also the assigned manager, as the ready-for-review hand-off — skipped when no manager is assigned, or when the creator is that manager
Run fails	The assigned analyst, else the creator	Names the step and the error
Study sent back	The assigned analyst, else the creator	Carries the reviewer’s notes; skipped when the rejecter is the recipient
Report build finishes	The approver who requested it	Report-ready or report-failed

The gap that matters for a reviewer: a study with no assigned manager arrives in In Review silently. It is in the queue and on the In Review tab, and nobody is told. Assigning a manager at intake is what turns the hand-off into a push.

One more honest note. Your profile page exposes three email preference toggles — approved, assigned, status change — and they are saved to your account. In the current build no send path reads them: the four emails above fire on their own rules, not on your toggles. Treat the panel as preference storage, not as a switchboard.

Working the queue, in practice

• Start with the oldest item on your tab. The list sorts, and the oldest In Review study is the one whose range has been waiting longest to be stood behind.
• The reasons are the work, for a sent-back study. A Rejected study carries the reviewer’s justification on its transition entry; start there, not in the grid.
• A failed run is a re-run. The study and the job carry the error; the action is the re-submit back into Processing. If the re-run fails the same way, the data is the thing to look at.
• Do not leave studies at Report Generated. That state has no queue entry and no reminder — it is the invisible leg of the path, and nothing reaches sign-off until someone generates the document.

The state machine behind every item is in Study Lifecycle; the review and sign-off decisions are in Manager Review and Partner Sign-Off and Final Archiving; the workspace layout is in the workspace tour.

FAQ

Do drafts appear in my queue? On the dashboard, yes — for an analyst, Draft and Rejected are both queue entries. For other roles, no: the manager queue is In Review and the partner queue is Document Generated, and no role’s queue holds another role’s states.

Why is a study I created not in my queue? Because the dashboard queue is role-and-state filtered, not owner-filtered. Once the study is at In Review it is the manager’s item. The list — My Tasks / Approvals — is where the whole visible book is, in every state.

Is the queue different from the audit trail? Yes — the queue is the current waiting set computed from study states right now; the audit trail is the complete append-only history. Every queue action writes to the trail; the trail never becomes the queue.

Why is there no counter or badge on the sidebar item? Because that entry is a navigation link to the study list, not a live queue with its own endpoint. The counts the platform does publish are the dashboard KPI cards.