Creating a Blueprint
Table of Contents...
A Blueprint in Zoho CRM is designed to help you execute a business process in a well-defined, systematic manner that is free from loopholes. 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.
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.
Building a process is largely a 3-step procedure.
- Enter Basic Info:
Specify the module, layout and field for which the process should be created.
- 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.
- Configure Transition Settings:
Configure Before, During and After Transition settings between different States in the process as required.
- Click Settings > Setup > Automation > Blueprint.
- Click Create Blueprint.
- 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.
- 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.
- In Blueprint Editor, drag and drop all the States (stages) that form a part of the process.
- 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.
- 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.
Now that the process flow has been established with States and Transitions, the final step is to define the 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.
- 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.
This section guides the Transition owners in completing a particular stage in a process by prompting them to enter specific fields, notes and other information contextually.
Insert message and fields
- Select the Make Notes as Mandatory checkbox to prompt users to add notes to the record, contextually.
- Add mandatory fields.
When you do this, the Transition cannot be completed without entering a value for the selected field(s).
Example, Closing Date and Discount.
- Validate the fields by defining validation criteria.
- Discount cannot be greater than 25%
- Closing date cannot exceed 30 days.
- Insert specific messages you wish to be displayed to sales reps as they execute the Transition.
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
- 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.
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 one common transition per process.
- Blueprint Limits:
You can create a maximum of 200 Blueprints per module. This limit is inclusive of layouts across a module.
A single Blueprint can have as much as 300 transitions. A common transition is counted only once, even if it is technically mapped from all States.
You can add a total of 50 fields and messages as mandatory in the During Transition section.
- 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 12 outcomes from a State. That is, one state can be connected to 12 different States through different transitions.
- If you modify* a Blueprint while there are still active records in the process, these changes will be applicable only to records created post the modification*. Records already within the process will follow the previous version of the Blueprint.
(*) 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. Those active records which have entered the Blueprint will still follow the process until they exit it.
- 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 to the chosen Transition owner(s) and those above them in the role hierarchy. A Transition owner can access records assigned to him/her from the My Jobs module.