Projects and approvals

Projects organize work and its financial attribution. Approval workflows determine who must review a record before a controlled action proceeds. Their configuration and day-to-day use are different responsibilities.

Project structure

Open Projects. The reviewed project controller uses projects:read for inspection and projects:manage for changes. Maintain the project identity, type, manager, status, and work breakdown structure as supported by the screen.

A WBS breaks work into elements so costs can be assigned more precisely than the project as a whole. The postable-reference operation identifies eligible leaf elements on projects that take cost. Do not assume every heading in the tree can receive postings.

Before restructuring a project, review existing document assignments and the effect on future coding. Adding a project reference to a document is not the same as posting that document.

Supporting documents

Attach relevant authorized project evidence using the supported attachment flow. The reviewed project upload controller declares a 25 × 1024 × 1024 byte limit. This differs from other upload areas; use the constraint for the specific screen, not a single assumed system-wide upload size.

Configure approvals

The Workflow screen at /workflow is a configuration surface associated with settings management. Define the intended condition, route, responsible roles/people, and stage restrictions, then test representative allowed and blocked cases with demonstration records.

The Tray at /tray brings work requiring attention into an operating view. Inspect the document, amount, history, attachments, and reason for the request before deciding.

Understand the seven approval actions

Action	Meaning in the reviewed approval model
Approve	Record an approval decision
Reject	Record a rejection
Hold	Pause the request; it remains open and continues to block the document
Rework	Return for correction through the supported resubmission path
Reassign	Hand responsibility to a specified person or role through a replacement request
Ask	Address a question to a person without changing the decision state
Watch	Include a person without changing the decision state

Pending and on-hold requests remain open in the reviewed logic. Ask and Watch do not approve the document. Reassign, Ask, and Watch require a target; only Reassign can target a role in this model.

Act on a request

Open the underlying document, read the context, and choose the action matching the situation. Use a clear note that lets the requester understand the decision or missing information. Recheck the resulting state and responsible person.

Batch actions are limited to supported decisions such as Approve, Reject, Hold, and Rework. Inspect every selected request before using a bulk action; the convenience of a batch selection does not establish that all records deserve the same decision.

Verify completion

An approved request and a posted business document are separate facts. Confirm the next supported stage and resulting transaction. If responsibility changes, verify that the replacement request exists and the new person can see it.