Test a guided stage transition and its required inputs

The contract this flow keeps

The refusal is the feature. It has to fire, and it has to say which inputs are missing.

• The starting stage - Qualification, with the next stage named so the path is unambiguous.
• The transition is refused - naming both missing inputs rather than failing generically.
• The inputs are supplied - a confirmed budget and a decision maker.
• The stage advances - with the captured values recorded and a log entry naming the transition.

Asserting that the refusal names both missing fields is what makes it usable. A transition that says it cannot proceed without saying what it needs sends the rep to an administrator instead of to the form.

The objective in plain English

The captured values are asserted on the record after the transition, which proves the inputs were stored rather than merely used to satisfy the gate.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/zoho-clone-app/blueprint?reset=true
max_steps: 45
tags: [zoho-crm, crm, workflow]
---

# Zohoe CRM 32.3: Blueprint stage transition

Catalog objective: move a record through a blueprint transition with required inputs.
Key assertion: the transition completes and the stage advances.

## Verify the starting stage
With lead "L1 - Mira Shah" selected, verify "Current stage" reads "Qualification" and "Next stage" reads "Needs analysis".

## Verify the transition is refused without its inputs
Click "Move to Needs analysis" and verify a red banner reads "This transition needs: Confirmed budget, Decision maker name."

## Supply the required inputs
Type "48000" into "Confirmed budget" and "Ravi Menon" into "Decision maker name", then click "Move to Needs analysis".

## Verify the stage advanced
Verify a green banner reads "Moved to Needs analysis.", "Current stage" now reads "Needs analysis", the "Captured so far" card shows "budget" of "48000" and "authority" of "Ravi Menon", and the record log contains "Blueprint: Qualification -> Needs analysis".

The log entry naming the stage change is asserted too, since a guided process without an audit trail cannot answer who moved a deal and on what basis.

Assertion by assertion

A starting stage, a refusal, the inputs and the advance.

Values captured at a transition are the evidence behind a forecast. Asserting that they persisted is what makes the stage change meaningful rather than cosmetic.

Putting it in CI

kane-cli testmd run tests/zoho-crm/blueprint-transition_test.md

Add a partial-input attempt, since supplying one of two required fields should still be refused and should name only the one still missing.

Guided processes are configuration rather than code, which makes them easy to change and easy to break. Running Kane CLI in CI covers catching that, and the Kane CLI introduction covers getting started.