1. Overview 

Every business needs a well-defined process to ensure proper adherence to its operations. Without clear processes in place, businesses face various challenges and inefficiencies. When a business is digitized with an application, it becomes even more important to enforce the process as a workflow. Having a workflow ensures all the users strictly follow the established process, thereby maintaining quality and standards.

What is a blueprint? 

A blueprint is a visual plan of a business process flow. It helps in streamlining the process management in an organization by facilitating automation, validation, and collaboration among various stakeholders.

In Zoho Creator, blueprints can be used to create a process flow with multiple stages and actions. These actions, called transitions, move a record from one stage to another.  A record progresses through the stages according to the flow to complete the blueprint. Blueprints enable you to customize every detail of every process you design in your Creator application.

Let's assume a hiring process is defined through the blueprint. Once the candidate submits the job application, the blueprint gets triggered, and the record will enter the first stage: Application Received. The application is then evaluated to decide if it should be shortlisted for interviews. If eligible, the concerned user clicks the Shortlist button in the report. This change, known as the transition, moves the record to the next stage: Application Shortlisted.

In this example, both Application Received and Application Shortlisted are the stages, while Shortlist is the transition action that connects them. The image below shows the blueprint in the edit mode of the application.

Live mode behavior

In the live mode of the application, the Candidate report displays the blueprint status as Application Received once the job application is submitted by the candidate. It shows the Shortlist button, which is the transition that can be performed by the user to move to the next stage: Application Shortlisted.

As the blueprint progresses stage by stage, the blueprint will be completed when it reaches the last stage.   

1.1 Stages

Stages represent the different states or milestones of a business process. A stage indicates the current state of a record within the workflow. Think of stages as checkpoints where the record waits until the next action is taken.

Example:

• Application Received

• Application Shortlisted

• Candidate Selected

1.2 Transitions 

Transitions are the actions a user does to move a record from one stage to the next. These are typically buttons like 'Approve' or 'Reject'. Transitions help enforce that the process flows correctly and certain actions happen before moving forward.  

Example:

• Shortlist

• Confirm Selection

1.3 Types of transitions 

Other than the default transition, which happens between two stages, there are two other types of transitions.

• Common transition

• Parallel transition

Common transition

A transition that can be accessed from multiple stages of a blueprint is called a common transition. In the above candidate screening process, the option to reject a candidate must be available at any stage of the process. This can be achieved by using common transition. As shown in the below blueprint, the Reject transition is available from all the stages.

Parallel transition

When multiple transitions are required to move from one stage to another, then it is a parallel transition. Some business processes require multiple steps in order to move to the next stage. In the above candidate screening process, assume there will be multiple interviews like Technical interview, HR interview. Only when both interviews are cleared can the candidate move to the next stage: Interviews Cleared. As shown in the below blueprint, Passed Technical Interview and Passed HR Interview are parallel transitions. In other words, a record will only move to the next stage when all the transitions are performed in parallel transitions. Please note that the transitions can happen in any order.

Info:

A stage can have only one parallel transition per direction.

Similarly, a stage can have a maximum of two outgoing parallel transitions.

Note: A common transition cannot be a parallel transition and vice versa.

1.4 Configuring transitions in the blueprint 

A transition lets you define more configurations like who has access to the transition, what actions to be performed during the transition, and what happens after the transition. A transition configuration is divided into three parts:

• Before

• During

• After

Before

The Before part of the transition lets you define the transition owners and criteria.

• Transition owners are the users who can view and perform the transition. Each transition in a blueprint can have its own transition owners. A single transition can have one or more transition owners. You can choose individual users, permissions, and user fields as transition owners. It is not necessary for all transition owners to perform the transition; any one of the transition owners can perform the transition.

• Users - Users refers to the users in the account. They are the individuals who have been added to the application or to whom the application has been shared.

• Permissions - Selecting a permission enables all the users associated with the specific permission to view and perform the transition.

• Fields - Field refers to the Users field in your form of the current record. Selecting a specific user field as a transition owner dynamically assigns transition ownership based on the record's data. For each record, the user selected in that user field will have permission to perform the transition.

Note :

Transition owners must have access to the records to perform the transitions.

• Transition criteria lets you set a rule when to display the transition button based on the field values of the record. You can also set logic between criteria using OR and AND expressions. For 'AND', every criteria must be true, and for 'OR', only one of the criteria must be true. For example, when the candidate's Age is less than 30 and Email is not null, the transition button must appear.

• Tooltip message - You can set a message that appears when hovering over the transition button.

• Require confirmation - You can choose whether to ask confirmation before performing the transition. This shows a pop-up after clicking the transition button and prevents accidental transitions.

Transition button

The transition button will be made visible to the transition owners when the transition criteria are satisfied.

During

The During part of the transition lets you define what actions to be performed when the transition owner carries out the transition. It allows you to do any one of the following:

• View and update fields of the same record - This shows a pop-up displaying the selected fields from the current record and asks the transition owner to enter the data when the transition is performed.
  Updating the fields will trigger on-edit workflows associated with the form by default. You can however choose to skip the execution of on-edit workflows while updating the fields.

• Open another form and add a new record to it - This option allows you to choose another form to be shown during the transition. This enables you to add a new record to any other form. Additionally, you can also pass values from the current form to the other one that is selected. The passed values will be prefilled and can be edited if needed before form submission.

After 

The After part of the transition lets you define what actions must occur after the transition has happened. The following options are available:

• Notifications - The below notifications can be triggered after the transition occurred.

• Send email - Triggers an email

• Send SMS - Triggers an SMS message

• Send notification - Triggers a notification inside the live mode of the application

• Show success message - Displays a message after the transition occurred.

• Redirect to a URL - After the transition happened, you can redirect to a website, form, report, or a page.

• Data access - Allows you to perform data operations on forms.

• Add record - Allows to add a record in any form of the application

• Update record - Allows to update a record in any form of the application

• Delete record - Allows to delete a record in any form of the application

• Integration - Allows to add a record to the below services:

• QuickBooks

• SalesForce

• Zoho CRM

• Zoho Recruit

• Deluge script - Executes the Deluge script after the transition happens.

With these configurations, you can extend blueprint capabilities from simple updates to complex integrations.

2. See how it works

  

3. Use case  

Patient Management App

A healthcare provider offers diagnostic lab testing services where the sample is collected from the patients and the report is delivered to them. Currently, the flow of booking the lab tests to delivering the reports is handled manually. This leads to delays, miscommunication, and more operational challenges.

To solve this, the provider implemented Blueprints in Zoho Creator and defined a structured process and automated every step. The blueprint is associated with each lab test record in the Lab Test form, clearly defining the lifecycle of a lab test record from start to end. The blueprint had different stages like Booked, Sample Collected, Sample Received, Report Added, and Report Ready. Transitions like Confirm Sample Collection, Received Sample, Added Report, and Verified Report were added between these stages.

Blueprint functionalities

• Each transition is assigned to different roles (like sample collection staff, lab technicians, or doctors) by configuring transition owners. For example, the transition Verified Report can only be triggered by the doctors who check the reports. This ensures that only the right users could perform the relevant actions.

• When the lab technician performs the Added Report transition, the Test Report form is opened to enter the test result values directly.

• After the doctor verifies the report and marks the last stage, Report Ready, an automated email is triggered to the customer attaching the lab report results. This eliminates manual follow-ups and timely communication.

The complete workflow has been streamlined, reducing manual efforts and increasing efficiency.

Employee Reimbursement Process

Let's consider a payroll reimbursement process in an organization. An employee raises a reimbursement request by submitting a form. The payroll team reviews the claim and approves or rejects it. When the payroll team reviews it, they may need to update certain fields, such as claim status, approved amount, comments, or rejected reason, during the transition. This can be achieved by the Update Fields option in During transition, where selected fields from the current form can be shown as a pop-up form when a transition is performed.

After the claim has been reviewed, it will be forwarded to the finance team to transfer the approved amount. This is achieved by setting transition permission only to the Finance team. When this transition happens, they can add a new record in another form called Bank Transfers by passing the values from the current form, such as the Employee ID, email, and approved amount. This can be achieved by the Open Form option in the During transition, where a different form can be shown during the transition and values can be passed to it from the current form.

4. Navigation guide

Prerequisite: A form is needed before creating a blueprint as blueprints are associated to a form and runs for every record in a form.

Go to the Edit mode of the application and click Workflow on the menu bar. Under the Blueprints tab, you can create blueprints.

5. More about blueprints 

5.1 Multiple blueprints 

A form can have multiple blueprints, which will be executed sequentially in the order of their precedence - that is, they will be triggered one after the other in the order they are listed in the Blueprint listing page. You can change the order by dragging and placing them in the required order.

5.2 Blueprint fields 

Blueprint fields are the system fields that store the details of the current blueprint for every record. These fields can be used as columns in reports, or as filtering criteria to create reports or as criteria in workflows. These fields will be hidden in the form and cannot be modified by Deluge or UI actions.

Below are the blueprint fields:

• Blueprint.Name - Stores the name of the blueprint the record is currently associated with.

• Blueprint.Current_Stage - Stores the current stage of the record within the blueprint. When a record exits a blueprint, it will have the exited stage as the current stage value.

• Blueprint.Status - Indicates the current state of the record in the blueprint. It can have any one of the following statuses:

• Active -The record is currently in progress within a blueprint.

• Completed - denotes the record has successfully completed the blueprint by passing through its stages.
  Note: Once a record is marked as Completed, it cannot re-enter the same blueprint. If new stages and transitions are added to the blueprint, it will not be applied to the records marked as Completed.

• Suspended - The record was forcefully exited from the blueprint. This can happen in the below cases:

• When a blueprint is disabled 

• When a stage is deleted in the blueprint

• When a stage is modified as the end stage
  In all the above scenarios, all records that were active in the blueprint will be marked as Suspended.

5.3 Deluge tasks 

Blueprint fields are available in Deluge, allowing you to access details like blueprint name, current stage, and status directly in your scripts.  You can also use Deluge tasks such as changeStage and executeTransition to move records between stages or trigger transitions. For more details, refer to the Deluge blueprint help page.

Note: To support additional blueprint variables, a few changes are made to its format in Deluge. These updates to Blueprint attributes are being rolled out to users in a phased manner.

 

What has changed?
Earlier, the current blueprint stage was accessed using	input.Blueprint_stages
After the update, this variable is automatically replaced with	input.Blueprint.Current_Stage
New attributes added
input.Blueprint.Name	returns the name of the current blueprint the record is in.
input.Blueprint.Status	returns the status of the blueprint
Important note for .DS file imports If you import a .DS file that contains input.Blueprint_stages, the following error will occur. Field 'Blueprint_Stage' does not exist in form To avoid this, update all instance of Blueprint_stages to Blueprint.Current_Stage before importing the old .DS file. Refer to the Blueprint Attributes help document to learn more.

5.4 Association of a record with a blueprint 

A record is associated with a blueprint in the following cases:

• When a record is added or edited manually through a UI action, it will be associated with the blueprint after the On Success workflow (if applicable) is completed.

• When a record is added or edited through Deluge, it will be associated with the blueprint after the current execution is completed or after the end of the event.

• In both the above cases, a record will only be associated with the blueprint if it is not already associated with any blueprint at that time.

If a record is associated with a blueprint, a strip will appear in the record’s detail view across all relevant reports. This strip displays the current stage of the record and the next available transitions. It will be visible based on the transition owner and the defined criteria.

 6. Points to note     

• Blueprint also works for the records added through portal.

• A record can go through a blueprint only once; it will not enter the same blueprint again. Allowing it to re-enter the same blueprint could result in repeated assignments to the same blueprint, so re-entry is restricted to ensure the record progresses to the subsequent blueprints.

• You can get insights about your blueprints with statistical charts using Blueprint analytics.  

• Existing records are not automatically associated with a blueprint when it is created. However, if those records are updated through UI or Deluge, they can be associated with the blueprint (provided they meet criteria defined during creation).

 7. Blueprint limits 

8. Related topics 

• Creating blueprints

• Blueprint quickstart guide