Work Requests
A request records what work the company needs and who should handle it.
They turn informal requests, change discussions, clarification loops, review needs, and approval requests into structured, traceable workflow objects.
In the request-to-baseline workflow, work requests are the intent layer.
They answer:
What needs to happen, and why?
Find Requests in the Hub
Section titled “Find Requests in the Hub”Open Operations → Work Requests. Saved views are Inbox, All, My requests, Assigned, Pending approval, Blocked, Learning, and Completed.
Inbox includes open requests assigned to you, plus your own Draft or Waiting for Information requests, because those need your action. The hub opens there when it has work for you, otherwise All. Pending approval contains open approval-type work requests, not pending actual-cost entries.
Search and filters run across the server’s records, not only the current page. Filter by status, priority, assignee, project, or due date; type, client, and Include closed requests are under More filters. Closed requests are hidden by default. Links preserve the view, filters, sort, and page, and Back restores them after opening a request.
Switch to Board to see Draft, Submitted, Under review, In progress, Waiting for info, and Approved columns. When closed work is included, Completed, Rejected, and Cancelled share the Closed column but keep their individual status tags. The board displays up to 200 requests and warns when more match; use the paged table for the full set. Board drag-and-drop and bulk actions are not available.
Act on a Request
Section titled “Act on a Request”Complete the Submission Requirements
Section titled “Complete the Submission Requirements”Save a draft and complete its context before submitting. Check the requirements for its type:
| Type | Required to submit |
|---|---|
| Request for work | Client or intake description, plus work description |
| Change | Project, a defined category, and requested outcome or description |
| Price refresh | Project, Market category, and requested outcome or description |
| Alternate | Project and requested outcome |
| Clarification | Project or estimate and description |
| Approval | Project or estimate and assignee |
Categories are Design, Scope, Market, Logic, Decision, Documentation, Other, and Learning; None leaves the category unset. Learning needs its source finding and the evidence requirements.
Open the request’s detail page to use the workflow panel and its allowed transitions. Approved can move to In progress or Completed; Rejected, Completed, and Cancelled are terminal. Hold / Resume sets or clears blocking. Entering Waiting for information records the reason; leaving it clears blocking. Terminal requests cannot be edited or reassigned.
Use the Comments, Files, and Activity tabs to keep clarification and evidence with the request. A client-linked Request for Work without a project creates its project when it moves to In progress. Eligible change, price-refresh, alternate, or approval requests can create an estimate revision from their detail page.
The Learning saved view points to the Cost Control learning queue. A learning request needs a resolution outcome and note before completion. AI-drafted proposals also enter this normal workflow as drafts after human confirmation; see Darwin AI Assistant.
What a Work Request Can Link To
Section titled “What a Work Request Can Link To”A work request may be connected to:
- a client
- a project
- an estimation
- a requester
- an assignee
- a parent request and related child requests
- a variance finding and source line for Learning
What a Work Request Can Contain
Section titled “What a Work Request Can Contain”- title and description
- type and category
- priority
- due date
- comments
- attachments
- activity history
- status transitions
Why Work Requests Matter
Section titled “Why Work Requests Matter”They help teams manage:
- requests for estimation work
- clarification questions
- estimation revisions
- blocked work
- price review
- approval-related follow-up
- coordination between people and functions
- documented decision history
Typical Lifecycle
Section titled “Typical Lifecycle”- A request is created.
- Missing information is clarified through comments, files, or activity.
- It is assigned to the person responsible for the next action.
- It moves through controlled status changes.
- It may create a project, estimation revision, price review, or approval path.
Work Requests vs Tasks
Section titled “Work Requests vs Tasks”A work request explains why work is moving.
A task tells a specific person to act.
A task points to work that needs attention. The work request keeps its purpose, context, comments, files, and outcome together.
Best Practices
Section titled “Best Practices”- create a request when a change needs ownership and traceability
- attach files and comments directly to the request
- link the request to the relevant project or estimation
- use request history to explain downstream revisions
- keep approval requests separate from the final approval decision