Work Requests

Work requests are one of Darwin’s most important newer workflow capabilities.

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?

What a Work Request Can Link To

A work request may be connected to:

a client
a project
an estimation
a requester
an assignee

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

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

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

A work request explains why work is moving.

A task tells a specific person to act.

Do not treat them as the same thing. A task may point to a work request, but the work request is the governed record of the intent, context, comments, files, and outcome.

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