Designing a Blueprint

Designing a Blueprint


Permission Required: Users with Manage Automation profile permission can access this feature.

--3 (includes default Blueprints)20 (includes default Blueprints)

Blueprint - A Scenario

A Blueprint in Zoho CRM is designed to help you execute a business process in a well-defined, systematic manner. With a Blueprint you can,

  • Define every stage in a process and associate the right people with each stage
  • Guide your teams through the execution of the process
  • Mandate and validate important information contextually
  • Automate routine actions

See also :Blueprint - An Overview

To learn how to design a Blueprint, let’s consider a scenario. Zylker Inc is a software company sells cloud applications. Their deal follow-up process consists of the following stages.
Let's see how this process can be designed in Zoho CRM using Blueprint.

Building Blocks of a Blueprint

A Blueprint is designed by creating a sequential order of these stages in a process. In CRM lingo, the primary building blocks of a Blueprint are - States and Transitions.


Each stage in a process is referred to as a "State" in Blueprint.

For example, a deal in CRM goes through different stages until Follow-up - Qualification, Negotiation and Discount approval. Each of these stages will be called a “State”.

States must be dragged and dropped in the Blueprint Editor to design the process flow.


A Transition is a link between two States in a process. It prescribes the conditions required for a record to move from one State to another. For example, the conditions and actions required for a record to move from Qualification to Negotiation are prescribed in the “Transition” block called "Negotiate".

We will look at these blocks in further detail below.

 Create a Blueprint

Designing a Blueprint

Building a process is largely a 3-step procedure.

  1. Enter Basic Info:
    Specify the module, layout and field for which the process should be created.
  2. Define the Process Flow:
    In the Blueprint Editor, define the process flow right from the Starting or the Default State (whichever applicable) through to the Exit State.
  3. Configure Transition Settings:
    Configure Before, During and After Transition settings between different States in the process as required.

Step 1 - Enter Basic Information

  1. Go to Setup > Automation > Blueprint.
  2. Click Create Blueprint.
  3. In the Create Blueprint popup, choose the module, layout and field for which the process is being created.

    In our scenario, since the process is Deal Follow-up, let us choose the Deals module, Standard layout and Stage field.
  4. Specify criteria for records to enter a process, if applicable. Example, Amount is >= 50000.
    If you don’t enter criteria, all records created in the layout will enter the process. Click Next.


  • Under Advanced Configuration, you can create a continuous Blueprint. A Continuous Blueprint is one that occurs without a pause - ideal for Sales Call Scripting.

Step 2 - Define the Process Flow in the Blueprint Editor

  1. In Blueprint Editor, drag and drop all the States (stages) that form a part of the process.
  2. Establish the process flow between the States by connecting the nodes in the State buttons.

    Note that the Start State is the equivalent of "None" value of the chosen picklist field. 
  3. Create Transitions by clicking on the + button between two States.
    (To delete a transition, simply Right Click on the transition line and click Remove Transition)

What does the above process flow mean?

This is a pictorial representation of the Deal Follow-up process followed in Zylker Inc. Deals entering this process will go through every stage in the order seen in the picture.

  • The white buttons represent States in the Blueprint (Deal Stages).
    • The green buttons represent Transitions (Conditions required to complete each stage).
    • Each Transition you configure is displayed as a button on the record's details page.
    • To complete a Transition, click on the Transition button and execute the actions mentioned in the ensuing popup window.
      Example, clicking on Qualify will throw up a popup window, which will guide you in executing this Transition.
    • On successful completion of the Transition, you will move to the next State in the Blueprint.
  • The blue button Deal Lost is called a Common Transition and will appear at all States of the Blueprint.
  • Click here to see more sample process flows from various sectors such as Education, Real Estate, Insurance.

Save a Blueprint as a Draft

It so happens that sometimes you are not ready to deploy your final Blueprint into CRM yet, and you need to put some more thought into the process flow. When you publish a Blueprint, you will begin having records entering it - so it's not a good idea to deploy it before it's ready. In this case, you can save a Blueprint as a DRAFT.

You can play around with your States and Transitions in the DRAFT version, and once you are satisfied with the final process flow, you can PUBLISH your draft. Note that the draft version is not a testing environment, rather a canvas of sorts, for you to test your process flow. You cannot test the execution of a Blueprint with the draft version - for now, it's only meant for you to play around with the process flow. 

At a given point in time, you can have one "Published" version and one "Draft" version of a Blueprint.

  • Published version: If a Blueprint is published, it means that it is live in your CRM setup. Records meeting the Blueprint criteria will begin following this version of the process flow.
  • Draft version: If a Blueprint is saved as a draft, it means that it is not yet deployed in the live CRM setup, but available for you to experiment, without affecting any existing records.

The moment you edit a Blueprint, you can either publish the changes directly or save the latest version as a draft. You can toggle between the Draft and Published versions in the Blueprint Editor.

Points to note

  • When you publish your latest changes from the Draft version, if there are existing records already associated with the previous version of the Blueprint, you will be prompted to decide how you want to deal with those records. You can choose between the following options:
    • Exit Blueprint, that is, take those records out of the process in their last known State.
    • Move all the existing records to the latest version you are about to publish.
    This will ensure that all records in a particular module follow a uniform process flow at a given point in time.
  • On editing a Blueprint flow, if you have deleted one or more States, when you republish it, you will again be prompted to either move any existing records to the latest version of the Blueprint or move them out of the process. If you choose to move them to the current version, you will be prompted to re-map the deleted States with the ones available in the modified Blueprint flow.
  • If you have deleted a Blueprint and you have had active records in it, you will be prompted to move the records out of the process.
  • In the Blueprints list view page, an asterisk (*) denotes a published Blueprint that also has a draft version associated with it.
  • A Blueprint that hasn't been published at all, & only in drafts, can be identified from its Empty Status (--).
    (The Status of a Blueprint conveys whether the process is actived or deactivated.)
    In the following screeshot, "Deals follow-up*" is a published Blueprint, that also has a draft version.
    "Leads Qualification" is a Blueprint only in the Drafts mode.
  • If you wish to discard changes made in the Draft version, simply switch to the Published version and click Save as Draft. Now the published version will overwrite your changes in the Draft version and you can start editing again.
  • The Draft version of a Blueprint is available to all users with access to the Blueprint, i.e, users with the Manage Automation permission in their profiles.

Now that the process flow has been created using States and Transitions, the final step is to define further Transition settings.

Step 3 - Configure Transition Settings

“Transition” refers to the change of state in a process. It is the connecting link between two States, where the conditions for the change are clearly defined. A Transition is made up of three parts - Before, During and After.

For example, let's look at the Transition between the States - Qualified and Negotiation Done. Let's name this "Negotiate". In Zylker's example, following are some guidelines to be observed while configuring the Transition settings in this scenario.

  • In order to complete the Negotiation Transition, a sales rep in Zylker must enter the Discount percentage and the Closing Date.
  • As per Zylker's policy, discount for a product cannot be greater than 25%.
  • As soon as the Negotiate transition is executed, an email notification must be automated to the sales rep's manager informing him/her about the deal submission.

Let's see how we can accommodate all of these points in the Blueprint.

Before Transition

  • Specify people responsible to execute a Transition.
    Example, Record Owner. When you choose Record Owner, only the Record Owner (and those above the record owner in the role hierarchy) will be able to view the Transition.
  • Define criteria that dictates exactly when this Transition should be available for the records in a process. 
    Example criteria: "Product Demo is Completed".
    In this case, the Transition will be shown to records only when the Product Demo field is updated to Completed
    If you have no such conditions, you can skip the criteria section. In such a case, the Transition will be visible on all records right away. 

During Transition

This section guides the Transition owners in completing a particular stage in a process by prompting them to enter specific fields, notes, attachments and other information contextually. For example, in the deal follow-up process, sales reps may be required to enter the discount percent, notes and attach a few sales documents according to the organization's policy. In such a case, all these details can be mandated in the During Transition section of the Negotiation Transition.

Following are the details that you can mandate in the During Transition section:

Mandate and validate fields across modules

You can guide your sales reps to enter information required as part of your process by mandating fields at the appropriate stages. These could be fields from the primary Blueprint module or related modules. For example, in the Negotiation stage of the Deal follow-up process, you can mandate the following fields:

  • Deal Discount
  • Related Account Name
  • Annual Revenue of the Account
  • Contact person's title and phone

To mandate fields of the Blueprint module and related modules

  1. In the During Transition tab, click Add.
  2. Choose the required module from the drop-down list.
  3. Select the field to be mandated.
    Repeat this action for the number of fields required.
  4. Validate fields to ensure that your sales teams enter acceptable values.
    • Discount cannot be greater than 25%
    • Closing date cannot exceed 30 days.

Include checklists

Checklists are nothing but To-do items to help your sales teams keep a clear track of the number of tasks and items they must complete in order to get through each stage of a process. This helps you better streamline every tiny step that you take towards executing a stage so that you never miss what’s important at the moment.

Checklist will be part of your During Transition, which, when configured by the manager or the process architect, will be shown to the eligible transition owners.

For example, in our Deal follow-up process, the following items could be part of a Negotiation Transition Checklist.

  • Finalize discount percent
  • Attach Negotiation documents as mandated
  • Check competitor's discounts

To mandate checklists

  1. In the During Transition tab, click Add.
  2. Select Checklist.
  3. Add a title for the checklist and the list of To-do items.

This will be displayed to the selected Transition owners. Only when the Transition owner "checks off" these items from the list, will he/she be able to proceed to the next State in the Blueprint. This gives you a solid, clear picture of progress of each stage.

Mandate the Creation of Associated Items

Apart from fields and checklists, you can mandate the creation of items associated to the Blueprint module as listed below:

  • Tasks
  • Events
  • Calls
  • Quotes
  • Sales Orders
  • Cases

For example, once the discount has been approved and the deal is in the Contract stage, you may want the sales reps to associate the Quote and schedule a call with the customer to proceed with the legal requirements. So here, you can mandate Task creation and PO association.

This will be contextual and guide the sales teams in breaking down a possibly overwhelming process into smaller pieces and doable action items.

To mandate the creation of associated items

  1. In the During Transition tab, click Add.
  2. Select Associated Items.
  3. Choose from the Associated Items dropdown list: Tasks and Quote.

Add a message to Transition owners

There's nothing like clear instructions to sales teams to make sure they execute a process efficiently. Include messages to sales teams at each stage, so that every Transition owner knows what's expected of him/her.

To add a message to the Transition owners

  1. In the During Transition tab, click Add.
  2. Select Message.
  3. Write a suitable message in the text box.

Make notes mandatory

You may want to know additional details about various aspects of a process, such as why a sales rep entered a particular discount, why a particular task is pending and so on. These additional details could be added as notes - and these notes could also be mandated in the During Transition stage of a process.

To make notes mandatory

  1. In the During Transition tab, select the Make Notes as Mandatory checkbox.

    So here, while executing the Qualify transition, the transition owner will be required to enter details of the customer requirements as notes, as outlined in the message.

Make attachments mandatory

Any process, be it sales, insurance, manufacturing or real estate - any business process for that matter brings with it the need for several documents. Sales contracts, Service Level Agreements, Legal Documents and so on are required at different stages of a process. You can mandate them at the required stage in a Blueprint.

To make attachments mandatory

  1. In the During Transition tab, select the Make Attachment as Mandatory checkbox.

    So here, while executing the Negotiate transition, the transition owner will be required to attach the documents as mandated in the checklist.
You can reorder the items to be displayed in the popup window by using the UP and DOWN arrows. You can also make use of merge fields to display data from CRM on the screen.

After Transition

Define actions to be automated at the completion of the Transition. Actions that can be automated in the After Transition section are:

  • Send Email Notification
  • Assign Tasks
  • Make a Field Update
  • Trigger Webhooks
  • Trigger Custom Functions

In Zylker's example, an email notification must be automated to the Sales Manager regarding a deal submitted for discount approval. So, choose Email Alerts and associate the required email template.

In a similar manner, you can build conditions for each Transition until the end of the process. To see how this Blueprint is executed, click here.

Configure SLAs for States

When you put a process in place in your organization, you need to ensure that it also gets done on time. SLAs help you do exactly that.

"SLA" stands for Service Level Agreeement - and is usually understood in the context of a service provider and customer. This term in Blueprint stands for an agreement of sorts between teams within an organization to communicate the maximum time a sales rep/team can keep a particular record in a said state. For example, if a deal is the "Qualification" stage for too long, the sales manager or the record owner must be notified of this. But how long is too long? If it does stay in a State for too long, who should be notified and what should be done about it?

These details can be configured as part of the Blueprint via SLAs. When you configure an SLA, CRM watches the records and how long each record is in a particular state. If it exceeds the time limit mentioned, the system will send alerts as configured to the users mentioned in the SLA settings. This helps you be transparent with the progress of a process across your organization and get things done on time.

To configure SLA for a State

  1. In your Blueprint Editor, click the State for which you wish to configure the SLA. Example, Qualified.
  2. Set the maximum time limit for which the deal can be in the Qualified State. Example, 3 Days.
  3. When the deal exceeds the SLA time limit, specify who should be notified and when.
    Example, escalate on the 3rd day to the record owner.
  4. In addition to this escalation notification, you can set an additional alert to be sent before or after the SLA time limit.

    For example, notify the record owner about the SLA time limit 2 hours before the limit expires. This will help you take prompt action before it's too late.

Common Transition

A Common Transition is a Transition that can be executed from all States in a process.

For example, in a Deal follow-up process, you typically know if you have won or lost a deal after the record goes through several stages such as qualification, negotiation, discount approval and so on. So Deal Lost is a Transition that is available only towards the end of the process. But assume that a customer shows no interest and you want to drop a deal at the Qualification stage itself. In such a case, you must be able to execute the Deal Lost Transition right then - rather than go through all the intermediary stages.

To make this possible, you must make Deal Lost a Common Transition by selecting the checkbox as seen in the following image. Once you do, you will see the Deal Lost Transition on all States. Currently, you can have 25 common transitions per process.

Sample Process Flows

In the following slide deck, you will find sample process flows for business from various sectors such as Education, Real Estate, Insurance, Banking and Finance. These are generic process flows meant to give you the perspective you need to start designing your own Blueprints. You can tweak the States, Tranistions and flow based on your unique needs. Start browsing the gallery now!

Points to remember

  • Blueprint Limits:
    No:of Blueprints allowed per Edition
    (inclusive of default Blueprints)
    No: of Transitions per Blueprint--10100300
    No: of Common Transitions per Blueprint--2525
    No: of fields that can be prompted in the During Transition section--41050
  • Blueprints will be executed in the order in which they are listed in the Blueprint page. You may reorder the processes if required.
  • When you have all automation features configured in Zoho CRM, the order in which they get executed are: Assignment rules, workflow rules, approval process, Blueprint and finally case escalation rules.
  • Different users can own different Transitions in a process. If a user does not have access to a record but is made a Transition owner, then the user will be able to execute the Transition but not edit the record.
  • There can be up to 20 outcomes from a State. That is, one state can be connected to 20 different States through different transitions.
  • If you modify* a Blueprint while there are still active records in the process, you will be prompted to either move those records to the latest version of the Blueprint or exit them out of the process altogether. 
    (*) Modification here refers to:
    • A change in the process flow
    • Deactivation of a Blueprint
    • Deletion of a Blueprint 
      Note that modification does not refer to changes made to the Transitions. Any change made to the Transition blocks in a Blueprint is effective immediately, regardless of new records or existing records in the process.
  • You cannot delete a Blueprint while there are active records in the process. However, you can deactivate it so that further records do not enter the process. 
  • Blueprint overrides the field access rights set for a user. For example, if a user has Read-only access to the Amount field, but is responsible to execute a Transition that mandates the Amount field, he/she will be able to update the amount while executing the Blueprint Transition. At all other times, the user will continue to have Read-only access to the field.
  • A Transition will be visible only to the chosen Transition owner(s) and users on the Administrator profile. A Transition owner can access records assigned to him/her from the My Jobs module.  

Share this post : FacebookTwitter

Still can't find what you're looking for?

Write to us: