> ## Documentation Index
> Fetch the complete documentation index at: https://docs.menaia.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Estimate lifecycle & statuses (reference)

> Every estimate status, the transitions between them, what each one triggers, and which fields lock when.

This page is the complete reference for an estimate's lifecycle: every status it can be in, how it moves between statuses, what each move triggers, and which fields lock when.

## Status reference

An estimate is always in exactly one of six statuses.

| Status | Meaning |
| - | - |
| In Progress | The default working state. This is the only state in which an estimate's pricing and scope can be edited. |
| Sold | The estimate has been won. Selling it creates the job and work order and records the sold dates. The estimate then becomes read-only and protected — only management-level roles can move it out of Sold. |
| Released | A non-sold, non-editable holding state. It still counts toward a user's "open estimate" allowance alongside In Progress. |
| Lost | The estimate was not won. Moving an estimate to Lost cancels the related job (if there is one). |
| Secondary Estimate | An alternate estimate for the same client or project. It behaves like any other status — there is no special creation step or side effect attached to it. It has the lowest priority when one estimate has to be picked to represent a project. |
| Deleted | A soft-deleted estimate. It is hidden from lists and lookups. Estimates are deleted through the delete action, not by picking a status from the dropdown. |

Deleted is not a status you can choose from the status dropdown — deletion always goes through the delete action.

There is no "Completed" status. (A "Completed, Paid in Full" status existed in the past and was retired.)

**Which estimate represents a project.** When a single project has several non-deleted estimates, one is chosen to represent it, in this priority order (highest first):

1. Sold
2. Released
3. In Progress
4. Lost
5. Secondary Estimate

## Transition table

The table below shows the allowed moves between statuses, the condition for each, and who can perform it (by role). Some status changes are made automatically by the system when another part of the product changes — those automatic cascades are not subject to the role checks below.

| From | To | Condition / who can do it |
| - | - | - |
| (new estimate) | In Progress | The default when an estimate is created. Subject to the per-user open-estimate cap. |
| (new estimate) | Sold | An estimate may be created already Sold; this records both sold dates at creation. |
| In Progress | Sold | Anyone allowed to set Sold. Creates the job and work order. Blocked if another estimate in the same project is already Sold. |
| In Progress | Released / Lost / Secondary Estimate / Deleted | Anyone allowed to set that target status. Ops Manager is specifically not allowed to set these. |
| Released | Sold | Anyone allowed to set Sold. Because the estimate was previously released, the existing job (if any) is reactivated. Blocked if another estimate in the same project is already Sold. |
| Sold | any other status | Requires management-level permissions: Sales Admin, Ops Manager, or Admin. |
| Sold | Lost | As above, plus an extra rule: blocked if the related job is already Closed. On success the related job is cancelled. |
| Sold | In Progress (to re-edit) | Management-level permissions only. If the proposal is signed, the user must confirm the reopen in **Start a change order?** and enter required **Change order notes**; re-editing then removes the signature. |
| any (except Sold) | Deleted | Through the delete action only. Blocked if the estimate is Sold, or if its proposal is signed. |
| Sold | Sold (re-sale) | When the estimate was previously In Progress or Released and a job already exists, re-selling reactivates and re-syncs that job. |

## Rules

### Only In Progress is editable

An estimate's pricing and scope can be edited only while it is In Progress. In every other status (except Deleted) those fields are read-only — the user must move the estimate back to In Progress first. Crew notes are the one exception (see below).

If someone tries to edit an estimate that is no longer In Progress, the edit is rejected with a "this estimate is read-only" error. Anyone with permission to edit estimates can make edits while In Progress (Sales Member and above), provided they have access to the relevant branch.

### Status changes go through a dedicated action

Status cannot be changed through the ordinary "edit estimate" action. It can only be changed through the dedicated status-change action, which enforces the per-role rules below. This means having permission to edit an estimate's contents does not, by itself, let someone change its status.

### Who can set which status

Each role is limited to the statuses it is allowed to set:

* **Sales Member** — may set In Progress, Released, Sold, Lost, Secondary Estimate, or Deleted.
* **Ops Manager** — may only set In Progress through the status change. Ops Manager is specifically not allowed to set Released, Sold, Lost, Secondary Estimate, or Deleted.
* **Sales Admin, Admin** — full access to all statuses, with no per-status restriction.

Attempting to set a status the role is not allowed to set is rejected.

### Leaving Sold requires management-level permissions

Once an estimate is Sold, moving it to any other status requires management-level permissions: Sales Admin, Ops Manager, or Admin. A Sales Member can mark an estimate Sold but cannot later move it out of Sold.

### Sold to Lost is blocked when the job is Closed

An estimate cannot move from Sold to Lost if its related job is already Closed. The move is rejected. (This is an extra business rule on top of the management-level permission requirement.)

### Selling an estimate creates the job and work order

The first time an estimate becomes Sold and no job yet exists for it, the system automatically:

* creates a work order, drawing on the crew notes, property, client, and the estimate's saved pricing and scope;
* fills in the work order's work areas and line items from the estimate;
* creates a job, set to "Requires Crew Lead", scheduled for the current date and linked to the estimate, branch, work order, and project.

This happens automatically as a result of the sale — anyone allowed to set Sold triggers it.

### Marking an unsigned estimate Sold asks for confirmation

When someone marks an estimate Sold and its proposal has not been signed by the customer, the status menu doesn't commit the change immediately — it first opens a **Mark as Sold without a signature?** dialog, because Sold sits next to Lost in the menu and a misclick would otherwise commit a sale. Selling without a signature is still allowed (the customer may have accepted another way, such as a signed paper contract); the change is only applied once the user confirms with **Mark as Sold**. Cancelling leaves the status unchanged. If the proposal is already signed, Sold is applied right away with no prompt. This confirmation is a safeguard on the action only — it does not change any of the sale's side effects or permission rules.

### Only one estimate per project can be Sold

A project can hold several estimates, but only one can be Sold at a time — the winner. Once one estimate in a project is Sold, no *other* estimate in that same project can be marked Sold. The Sold option is greyed out in the status menu, and attempting the change anyway is rejected with a message naming the estimate that already won ("This project already has a sold estimate…"). This applies however the sale is triggered — a team member setting the status, or a customer signing that estimate's proposal. To sell a different estimate, move the current winner out of Sold first.

The rule excludes the estimate itself, so re-selling the current winner (for example, for a change order) still works. It also closes the proposal path for the project's other estimates: while one estimate is Sold, the others can no longer have their proposals sent.

### Re-selling reactivates the existing job

If a job already exists for the estimate and the estimate was previously In Progress or Released, re-selling it reactivates the existing job rather than creating a new one: unless the job is already Closed or still brand-new ("Requires Crew Lead"), it is moved back to "Plans In Progress", and any non-draft job plan is reset to Draft. In all cases the work order is re-synced from the estimate. Closed jobs are left untouched.

### Marking an estimate Lost cancels the related job

When an estimate moves to Lost (and was not already Lost), its related job — if there is one — is cancelled, unless that job is already Cancelled or Closed.

### Automatic status changes skip the role checks

Some status changes are driven by other parts of the product rather than by a person (for example, cancelling a job can flip its estimate to Lost). These automatic cascades bypass the role and per-status permission checks, but every other side effect — recording dates and creating or updating related records — still runs.

### When the status last changed is recorded automatically

Every time an estimate's status changes, the system records when the status last changed. On creation, this is set to the creation time. This value is maintained by the system and cannot be set directly.

### The first sold date is recorded once and can't be changed

The date an estimate was first sold is recorded the first time it becomes Sold (or at creation, if it is created already Sold). It never changes afterward — not even if the estimate is later re-sold. It captures the original sale date for sales reporting and is permanent.

### The effective sold date defaults to the first sold date and can be adjusted by management-level roles

The effective sold date is the date used for sales reporting. It starts out equal to the first sold date. It can later be adjusted, but only by Admin, Ops Manager, or Sales Admin, and only while the estimate is Sold. Adjusting it on an estimate that is not Sold is rejected.

### Crew notes stay editable in any status except Deleted

Crew notes are an annotation, not part of pricing or scope, so they can be updated in any status except Deleted — even when the estimate is otherwise read-only (such as Sold). This is the one exception to the "only In Progress is editable" rule. Crew notes are limited to 5,000 characters.

Crew notes can be edited by Sales Member, Client Coordinator, Crew Leader, Ops Manager, Sales Admin, and Admin. Note that Crew Leader can edit crew notes even though they cannot otherwise edit estimates.

### Each estimate keeps an immutable snapshot of its pricing

When an estimate is created, the system saves a snapshot of the pricing and configuration it was built from — financing terms, payment methods, branding, and reviews. The snapshot doesn't include tax: the estimate keeps its own saved copy of the applied tax rate instead (see [Sales tax](/reference/billing/sales-tax#the-saved-copy-of-the-rate)). The snapshot is what the work order's line items are built from when the estimate is sold.

### Rebuilding the snapshot requires management-level permissions

Saving edits and rebuilding the snapshot from the current catalog at the same time requires management-level permissions (Sales Admin, Ops Manager, or Admin). The save and the rebuild happen independently — if the rebuild fails after the save succeeds, the edits are kept and the previous snapshot stays in place, and the failure is reported.

### Estimates are soft-deleted; signed or Sold estimates can't be deleted

Deleting an estimate is a soft delete — the estimate is hidden from lists and project lookups, and its proposal is preserved in case it needs to be restored. Deletion is blocked if the estimate's proposal is signed, and blocked if the estimate is Sold. Deletion is available to management-level roles.

### Re-editing a signed estimate reopens it for a change order

If an estimate's proposal is signed and someone wants to move it back to In Progress (the only status that requires removing the signature), the system opens a **Start a change order?** dialog instead of making the change, and requires **Change order notes**. The notes are mandatory — empty or blank notes are rejected — and are visible to your client. **Start change order** stays disabled until you enter them. Starting the change order also requires management-level permissions. Once started, the signature is cleared and the status changes together as a single step; the signed proposal is preserved as a read-only earlier version, and the proposal's earlier sent, opened, and expiry state is reset so the next send starts fresh. Moving a signed estimate to other read-only statuses (Lost, Released, Secondary Estimate) keeps the signature as audit evidence and does not require a note.

### Signing or selling saves a read-only proposal version

Where version history is turned on, the estimate's proposal is saved as a new numbered, read-only version each time the customer signs it, and each time the estimate becomes Sold while its proposal is unsigned (shown as "Marked sold"). A sale that follows a signature doesn't save a second version. Saved versions never change: a change order edits the next version, which is saved in turn when it's signed or sold. If a proposal signed before version history existed is reopened for a change order, its current state is saved as Version 1 first. Each version after the first stores a summary of what changed since the previous one. Photos and videos used by a saved version are kept even if they're deleted from the project's media. See [Version history and change details](/guides/proposals/client-response#version-history-and-change-details).

### Selling an estimate can award badges

When an estimate moves from a non-sold status to Sold, the system evaluates whether any sales badges have been earned. This happens automatically after the sale.

### Cap on open estimates

When a new In Progress estimate is created, if the branch sets a maximum number of open estimates, creation is rejected once the user already has that many open. "Open" is counted as In Progress plus Released estimates for that user and branch. This applies to everyone creating estimates, regardless of role.

### Estimate history is tracked on update

Every time an estimate is changed, the edit is recorded so there is an audit trail of what changed and who changed it. (Routine bookkeeping fields aren't tracked.)

### Secondary Estimate has no special behavior

Secondary Estimate is simply a status value. It follows the same per-role rules and the same project-priority ordering (lowest) as any other status. There is no dedicated "create a secondary estimate" flow and no special side effect tied to it. Anyone whose allowed statuses include Secondary Estimate can set it (Sales Member, and Sales Admin / Admin); Ops Manager cannot.

### Baseline access

Underneath the per-status rules above, baseline access to estimates is scoped to the user's organization and gated by role: reading is available to organization members; creating and updating are available to crew-management-level roles; deleting is available to management-level roles. The per-status rules on this page apply on top of this baseline.

## Notes on edge cases

* **Sold to Lost / Closed-job check.** The "job is already Closed" check that blocks a Sold-to-Lost move is applied on the normal flow. It is worth being aware that it depends on the job information being available at the time of the check.
* **Effective sold date permissions.** Editing the effective sold date requires management-level permissions: Admin, Ops Manager, or Sales Admin. The same role set governs both whether the field is editable and whether the save is accepted.
* **No fixed transition graph.** There is no single fixed map of "legal" transitions. Allowed moves are the combined result of the per-role allowed-status rules plus the special "leaving Sold needs management-level permissions" rule plus the per-transition side effects. A move is allowed as long as the actor is permitted to set the target status — there is no restriction based on the starting status except the special Sold rule.