Skip to main content

CRM Stage Validation

Purpose​

CRM Stage Validation adds configurable checks to transitions between native CRM stages. A policy can require customer details, a next activity, attachments, or other evidence before a record enters its target stage. Warnings identify incomplete evidence; blocking requirements stop the transition unless an authorized manager has approved a valid exception.

This guide follows the Odoo 19.0 source. The described workflow and practice case have not been runtime-tested during this documentation review.

Before you start​

Install the addon package for your exact Odoo major. The 19.0 package requires CRM (crm), with no mandatory Enterprise dependency or other paid Corvus addon. The 15.0 package additionally declares base_sparse_field. Optional quotation checks need the native Sales integration and linked quotations; document-category checks need applicable document metadata. Do not select those checks merely because they appear in the list.

Decide which source-to-target stage moves need controls, what evidence satisfies each check, and which failures should block sales work. A policy is required for a transition to be controlled.

Access and roles​

Sales users can read policies and requirements and open readiness checks for their accessible CRM records. Sales Managers maintain policies, approve exceptions, and access override records, transition analysis, and CSV exports. Policies can be shared or company-specific; record rules restrict access to allowed companies and shared configuration.

An override approver must differ from the selected requester. Audit logs and override evidence are immutable through normal record editing. The addon does not replace the underlying CRM permissions.

Setup and menu​

Open CRM → Configuration → Stage Readiness Policies. Define a name, optional company and team, lead/opportunity scope, source stage if applicable, and required target stage. Source and target must differ. Additional scope includes priority range, revenue range, and a user group.

The resolver chooses the most specific matching policy, then lower sequence and record order. Overlapping policies are not automatically combined into one checklist. Test Policy opens candidate records to help review the scope.

Add requirements with a severity, failure message, and useful remediation hint. Providers include customer/contact details, expected revenue or closing date, probability, tags, source/campaign, internal note, safe custom field, completed activity type, overdue activity checks, future next activity, attachment count/category, and optional quotation evidence. Configure the provider-specific threshold or field. Custom fields must belong to CRM and satisfy the supported-field validation.

Workflow​

  1. Open a lead or opportunity and select Check Readiness. The check selects the first applicable controlled target ordered by target-stage sequence and policy sequence. Read the displayed source stage, target stage, and policy before acting.
  2. Review each result, its evidence, and remediation hint. Blocked means at least one blocking requirement failed. Needs Attention means missing warning requirements remain. The percentage measures satisfied checklist items.
  3. Close the check, add the missing information, complete the required work, or schedule an appropriate next activity. Run Check Readiness again to refresh the result.
  4. When eligible, select Move to Target Stage or make the intended native CRM stage change. The server reevaluates the transition. Stage dragging or an import does not grant an exception to the configured gate. A native Won action is also checked when it changes into a controlled stage.
  5. For a justified exception, a Sales Manager opens the check, selects the requester, enters a reason of at least five characters, and chooses a duration from 1 to 168 hours. Approve Time-Limited Override records the exception; it does not itself move the opportunity. Make the intended move afterward.
  6. Use CRM → Sales → Blocked Opportunities and Missing Next Step to organize follow-up. Managers can use Expiring Overrides, Stage Readiness Analysis, Readiness Overrides, Frequent Readiness Failures, and Readiness Failure CSV for oversight.

Practice scenario​

In an authorized test database, create “Harbor Works — maintenance renewal.” Configure a policy from Discovery to Proposal with blocking checks for a customer and a future next activity. Leave the next activity empty, run Check Readiness, and inspect the expected failure explanation. Schedule a future call, check again, then move to Proposal. Review the transition evidence as a manager. This scenario is source-derived; it is an exercise to validate against your installed package.

Troubleshooting and limitations​

“No readiness policy applies from the current stage” means the button could not find a matching next target. Check company, team, lead type, stage, and other scope filters. Transitions without a matching policy remain uncontrolled. If evidence exists but is inaccessible to the current user, the result records that it cannot be evaluated as accessible evidence; additional permissions may need administrative review.

An override is tied to the lead, policy, stage pair, expiry, and evidence revision. Material CRM changes, activity changes, attachment changes, or policy changes can invalidate it. A successful exception is consumed by the transition. A blocked write raises an error; use the explicit Check Readiness action when you need a persisted check record for analysis.

The catalogue lists 15.0–20.0. Older branches contain their own view and access adaptations. The primary workflow here is 19.0. On 20.0, this addon shares readiness method/field names with CRM Lead Qualification; have the combined installation checked before deploying both. The targeted branch comparison does not establish combined or all-version runtime behavior.