What Blueprints Are
Visual state machine for any module. Records move through defined stages; each transition has conditions (when allowed), validators (required fields), actions (what fires), and during/after triggers (when actions run). Process enforcement without writing code, with a strict audit trail of who moved what when. The Blueprint Editor is drag-drop with a constrained vocabulary — States (boxes), Transitions (arrows), and Action Sets (attached to transitions).
When to Use
Deal progression where stage advancement requires specific data (Discovery → Qualification needs MEDDIC fields, Qualification → Proposal needs a Quote attached). Case escalation in Desk where tier-1 → tier-2 needs reproduction steps. Onboarding sequences where a customer can’t move from “Account Created” to “Active” without a kickoff call logged. Any record with a defined lifecycle and gate conditions benefits. Don’t use Blueprint for simple linear flows that could be a status field with required-on-save validation.
Transitions
Click to advance stage — only available when conditions are met. The “Common Transitions” feature lets you define a single transition (e.g. “Cancel”) that’s available from multiple states without redefining it per state. Required fields block advancement and surface inline on the transition modal. Custom messages on the transition button explain what’s needed (“Add Quote to advance to Proposal”). Each transition can have a different button label (“Mark Won” vs “Mark Lost” both transition out of Negotiation).
Common Actions
Send email notification (via template), update fields on the current record, update fields on related records, call webhook, invoke Deluge custom function, assign task to a user/role/owner, add tag, send to approval. Every transition is an orchestration point. The during-transition vs after-transition distinction matters: during runs synchronously and can block the transition on failure; after runs asynchronously and won’t.
// Custom function called from a Blueprint transition
deal_id = input.deal_id;
deal = zoho.crm.getRecordById("Deals", deal_id);
// Generate a quote document via Zoho Sign
sign_response = invokeurl
[
url: "https://sign.zoho.com/api/v1/templates/" + quote_template_id + "/createdocument"
type: POST
parameters: {"templates": {"actions": [{"recipient_email": deal.get("Contact_Name").get("email"), "action_type": "SIGN"}]}}.toString()
headers: {"Authorization": "Zoho-oauthtoken " + token}
];
zoho.crm.updateRecord("Deals", deal_id, {"Sign_Document_Id": sign_response.get("requests").get("request_id")});Governance
One Blueprint per lifecycle. Don’t overlap two Blueprints on the same module — order of evaluation is not guaranteed and behavior is unpredictable. Test transitions in a sandbox before production deployment, especially when changing required fields or transition conditions. Changes to Blueprints affect in-flight records — a record currently in “Discovery” may suddenly fail validation when you add a required field to that state. Plan the migration: either backfill the field on existing records or use a transitional state.
Common Failure Modes
Over-modeling: 12 states for a 3-stage actual process makes Blueprint a hindrance. Start simple. Stuck records: a record sits in “Awaiting Approval” for 30 days because the approver left the company — add SLA-style escalation transitions. Permission mismatch: only certain roles can transition certain states; surface this clearly in transition button availability rather than letting users hit “permission denied”.
What Changed in 2026
Blueprint now supports parallel branches (a single state can transition to multiple downstream states with both fired) and async waiting states (a state that auto-transitions when an external webhook arrives). Both require careful governance — parallel branches can rejoin in unexpected order.
What to do this week
Pick your highest-volume module with stage-gate dependencies, sketch the state machine on paper, and implement a 3-state Blueprint as a pilot before expanding.
