Blueprint Essentials (What You’ll Build)
- Blueprint ties to a picklist: Most commonly the Deals → Stage field (Blueprints require a picklist field).
- States + transitions: Drag stage values into a flow and define how users move between them.
- Before / During / After: Control who can click, what they must enter, and what automates after the move.
- Common transitions: Add “Closed Lost” (and optionally “Closed Won”) so users can exit from any stage.
- Avoid the spiderweb: Keep v1 linear; over-branching creates a confusing process nobody follows.
A Zoho CRM Blueprint is designed to enforce a step-by-step process inside a module like Deals. Instead of letting users freely change the Stage picklist, you define transitions that require the right fields and actions at the right time, and optionally run automation after each step.
Reality check: Blueprints are powerful because they are restrictive. If your sales process is flexible (skipping steps is normal), consider using Workflow Rules on Stage changes instead of locking the pipeline down.
Part 1: Create a New Blueprint in Zoho CRM
Where do I find Blueprints in Zoho CRM?
- Click the Setup gear icon.
- Go to Process Management → Blueprint.
- Review existing Blueprints (new CRMs often include default ones).
- Click Create Blueprint.
What settings do I choose when creating a Blueprint?
- Name: Example: “Deal Process”
- Module: Deals
- Layout: Select your target layout
- Field: Choose the picklist that controls the process (commonly Stage)
How do I limit which deals enter the Blueprint?
You can apply entry criteria so only certain records enter the Blueprint. Example:
- Deal Type = New Business (and exclude renewals or expansions if they follow a different process)
Part 2: Design the Process Flow (States and Transitions)
What is a “state” in a Zoho Blueprint?
A State is a picklist value from the selected field (e.g., Stage values like Qualification, Needs Analysis, Closed Won).
How do I add states to the Blueprint canvas?
- Use the states list on the right side of the Blueprint builder.
- Drag relevant stages onto the flowchart.
- Connect states to define the allowed movement path.
How should I name transitions so users understand them?
Use action-based transition names (verbs) so the button makes sense to the rep. Example:
- Transition name: “Start Discovery” (instead of “Needs Analysis”)
Tip: You don’t need to include every single stage in a Blueprint. Many teams only blueprint the “strict” portion of the pipeline (often the later stages).
Part 3: Configure Each Transition (Before, During, After)
Before: Who is allowed to click this transition?
The Before section determines whether the transition appears for a user and record.
- Owners: Often defaults to Record Owner
- Manager-only step: Restrict execution to a role/team when approvals are needed
- Allow anyone: Remove “Record Owner” so all users can execute the transition
Before: When should this transition be visible (criteria)?
Use criteria to branch based on record data, such as Industry or Deal Type. Avoid using Stage as criteria because the start state already implies it.
During: What does the user have to do during the transition?
The During section is the guided checklist of what the user must enter or create.
- Fields: Add key fields like Budget, Service Type, and Completion Date
- Mandatory vs optional: Include fields without making them required if you want to encourage data without blocking progress
- Messages: Add instructions users see while executing the transition
- Associated items: Require a Task (and preferably require a Due Date)
- Checklists: Blueprint-only checklist items (these are not CRM tasks)
Note on widgets & kiosks: These are advanced options and are usually reserved for special cases. Most implementations rely on fields, messages, tasks, and checklists.
After: What should Zoho CRM automate after the transition completes?
The After section runs automation similar to workflow actions.
- Field Update: Example: stamp a date field (e.g., “Proposal Date”) to Today + 45 days
- Email Notifications: Notify internal users or related contacts using email templates
- Task/Meeting automation: Create required follow-ups automatically when they should happen every time
During Task vs After Task (Why It Matters)
This is a common design decision in Blueprint implementations:
- During task: The user creates a task during the transition (more flexible; task details vary)
- After task: Zoho creates a standardized task after the transition (more consistent; always happens)
Part 4: Add Common Transitions for Closed Lost (and Closed Won)
What is a “Common Transition” in a Zoho Blueprint?
A Common Transition is visible from every state in the Blueprint. It’s ideal for outcomes like Closed Lost because deals can be lost at any point.
Best practice: include Closed Lost as a common transition
- Create a “Lost Deal” transition
- Make it a Common Transition so it is always available
- Optionally require a Loss Reason field during the transition
Optional: color-code your transitions
- Closed Lost: Red
- Closed Won: Green
- Normal steps: Blue (or your internal standard)
Part 5: Test the Blueprint on a Deal Record
What happens when a Deal enters a Blueprint?
- The Stage field becomes locked (users can’t manually change it)
- Users must use the Blueprint transition button (e.g., “Start Discovery”)
- Missing required fields will block completion (but drafts may be allowed)
Can I save a transition as a draft?
Yes—drafts are useful when a rep has partial information and doesn’t want to lose what they entered, but can’t complete every required item yet.
Do Blueprint transitions show up in Work Queue?
Yes. If your team uses Work Queue, Blueprint jobs can appear under the Blueprint tab, which helps users work “top-to-bottom” through required steps.
Blueprint fit warning: If reps need to skip steps (e.g., jumping from Qualification directly to Decision Makers), you must add that transition—or they’ll be locked out.
Publishing Changes Safely (Don’t Nuke Your Blueprint)
What’s the risky republish option?
When you republish a Blueprint, Zoho presents options for handling records already inside the Blueprint. One option can cause records to exit the Blueprint permanently.
- Safer option: Move records to the current version
- Danger option: Exit records from the Blueprint (avoid unless intentional)
Admin caution: If you accidentally force all records out of a Blueprint, getting them back into the correct stage can be painful—especially with a large pipeline.
Blueprint Design Reference Table
| Blueprint Component | Purpose | Example | Best Practice |
|---|---|---|---|
| State | Represents a picklist value | Stage = Qualification | Only include states you truly need to control |
| Transition | Moves a record from one state to another | “Start Discovery” → Needs Analysis | Name transitions with verbs so users understand the action |
| Before | Controls visibility and permissions | Only Record Owner can execute | Use criteria sparingly to avoid hidden paths |
| During | Guides user inputs and actions | Require Budget + create a Task | Keep it lean; too many requirements slows adoption |
| After | Automates post-transition actions | Field update + email alert | Automate the “always needed” steps here |
| Common Transition | Always available from any state | Closed Lost | Ideal for outcomes that can happen at any point |
Frequently Asked Questions
Why does Zoho CRM require a picklist field for Blueprints?
Blueprints are designed around “states,” which are the selectable values of a picklist field (like Deal Stage). That picklist becomes the backbone of the flowchart.
What’s the difference between Before, During, and After in a Blueprint transition?
Before controls visibility (owners/criteria). During collects required fields and user actions. After runs automation like field updates, tasks, meetings, or emails.
What is a Common Transition, and when should I use it?
A Common Transition is visible from every stage in the Blueprint. It’s commonly used for Closed Lost (and sometimes Closed Won) so the team can exit the process from anywhere.
Why do Blueprints sometimes fail in real sales teams?
Most failures come from overengineering: too many branches, too many mandatory steps, and a process that doesn’t match how sales actually works. Keep v1 simple and linear.
Should I use a Blueprint or workflow rules for my deal stages?
Use a Blueprint when you need to lock down the process and mandate steps. Use workflow rules when the process is flexible but you still want automation triggered by stage changes.
Want Help Designing a Blueprint That Your Team Will Actually Use?
Blueprints can be a game-changer when they match your real process (and don’t turn into a spiderweb). If you want help mapping stages, transitions, and automation cleanly, Zenatta can help.
Book a CRM Strategy Session