- Transition Owners
Specify agents responsible for executing a Transition.
Example, Record Owner. When you choose Record Owner, only the Ticket Owner will be able to view the Transition. You can also specify other agents using the drop-down menu.
Note: If transition owner is not assigned, then any agent from the particular department can initiate the transition. That is, all the agents (in that department) will have access to the ticket by default. - Transition Owner from a Different Department
Select a department whose agents can also perform transitions. The tickets are automatically shared with the department you choose here. Also, select the permission level you'd like to assign the agents. You can choose from - Full Access, Read Only Access and Restricted Access. - Criteria
Define the conditions that dictate precisely when this Transition should be available for the tickets. You can skip the criteria section if you want the Transition to be visible on all tickets.
During Transition
The During condition checks for specific actions or field updates to be completed before allowing a transition to occur. For example, you can prompt your agents to enter specific fields, leave comments, attach files, subject, and other information contextually. Let's look at the details that you can mandate in the During Transition:
Mandate and Validate Fields
Prompt your agents to enter information required as part of your process by mandating fields at the appropriate stages. You can also validate fields to ensure that your agents enter acceptable values.
To mandate and validate fields
- In the During Transition tab, click Add Operations > Fields.
- Select the field to be mandated from the drop-down menu.
Repeat the steps to add more fields. - Click Validation on the field you selected.
- In the Validation Rule Popup window, define the primary condition to validate the rule.
- Enter the alert message that should be displayed for tickets that don't meet the condition.
- Click Done.
Mandate Ticket Actions
Apart from fields, you can mandate certain ticket actions that must be performed by your agents to get through each stage of a process.
To mandate ticket actions:
- In the During Transition tab, click Add Operations > Actions.
- Select the actions to be mandated from the drop-down menu.
You can mandate the completion of the following actions: - Reply All
- Comment
- Attach file(s)
- Submit for Approval
- Resolution
- Share Ticket
- Drag and drop the actions in the order they should be completed in a Blueprint.
Notes:
- Only if a ticket has a public reply, data from the recent public comment will be fetched upon clicking "reply all".
- If the reply all action is mandatory, agents or admins must send a reply during transition. However, if it's not mandatory, they can skip sending a reply by selecting the Skip this reply option. Whether to make "Reply All" mandatory or not depends on the situation. In scenarios such as regular system maintenance where users don't need updates, admins might skip the "Reply All" to avoid unnecessary messages. But in urgent situations, like a widespread service problem, making "Reply All" mandatory is crucial. It ensures everyone gets important updates and knows what to do.
Enter a Message to Transition Owners
Provide clear instructions to the transition owners so that they could execute a Blueprint process efficiently. You can include messages which refer to specific situations or general guidelines that should help them prepare for the next transition.
To enter a message
- In the During Transition tab, click Add Operations > Message.
- Enter a message in the text box.
The box will accept a maximum of 255 characters.
Add Extensions
In the "During" blueprint transition state, users can select extensions as one of the operations. Adding extensions improves the support ticket process by choosing specific widgets that match the unique needs of the blueprint process. Blueprint-integrated extensions have multiple uses, including field updates, external service updates, step sequences, form data retrieval, and form data submission.
Consider a scenario where a customer support team aims to improve scheduling using a widget during a blueprint transition. In this case, the team can add the Zoho Calendar extension while configuring the "during blueprint transition state". This enables support agents to efficiently schedule follow-up calls and manage appointments as part of the blueprint transition.
Note:
- Users can add two extensions in a blueprint transition.
- Only the extensions that are set up with a Blueprint location will appear in the pop-up.
- Currently, Zoho Sprints and Zoho Calendar extensions can be added as Blueprint widgets.
To add an extension in during transition
- In the During Transition tab, click Add Operations > Extensions.
- Select and associate the desired Extensions.
- Click Save & Complete Blueprint.
To perform the transition using extensions
- Navigate to the ticket detail page.
- In the extension transition bar, click the desired transition state.
- Perform the necessary actions within the extension and click Complete Transition.
Send IM replies
Blueprint transitions can be applied for IM-channel tickets. If an admin adds a "reply all" operation during the "During transition" state in a blueprint, the IM editor will appear for those IM-related tickets. This means that agents can utilize the IM interface to respond to customers, attach files, include images, and use canned responses while executing the blueprint transition.
To illustrate, imagine a scenario where a customer submits an issue via instant messaging in Zoho Desk. The ticket enters a blueprint-controlled workflow, and during a specific transition stage, the agent needs to reply to the customer. With the IM-reply editor accessible during the transition, the agent can reply directly through the IM editor without completing the entire transition process. This streamlined approach allows the agent to address the customer's issue immediately, without the need to navigate away or complete the entire workflow first.
Agents can complete the transition without replying even if the reply all action is marked as mandatory. After Transition
The After condition executes certain automated actions on completing a transition. Actions that can be automated in the After Transition section are:
- Send Email Alerts
- Make a Field Update
- Assign Tasks
- Trigger Custom Functions (exclusive for Enterprise edition)
To set up automated actions
- In the After Transition tab, do the following:
- Click New corresponding to an action to create one and then associate with this transition.
- Click Existing corresponding to an action to select an existing action to be associated with this transition.
These instant actions are triggered immediately when the transition is completed.
Common Transition
At times, you may want to execute a transition from all states in a Blueprint. For example, in a return approval process; you typically know if you have to approve or reject a return after the ticket goes through several states. So Return Rejected is a transition that is available only towards the end of the process. But what if a customer rescinds the return request at the initial stage itself. In such a case, you must be able to execute the Return Rejected transition right then - rather than go through all the intermediary states. In this case, you can mark it as a Common Transition so that you can execute it from any state.
To mark a transition as common
- Click the Transition that you wish to execute from all states on the Blueprint Editor. Example, Return Rejected.
- Toggle the Common Transition option to ON.
The common transition appears green on the Blueprint Editor.
Strict Mode
A Blueprint requires agents to execute their transitions from within the ticket's transition bar. For example, if you've prompted your agents to enter a comment in the During Transition setting, they should click the respective Transition button and leave their comment. That said, agents may stray into performing a Blueprint mandated action outside of the transition bar resulting in the transition not being executed and the ticket stagnating in the same state. This is where Strict Mode comes handy.
The Strict Mode, when enabled, will hide key features from the ticket interface, thereby restricting agents to only executing actions on the transition bar. Here is a list of such features:
- Replying, forwarding, and leaving a comment
- Editing a ticket or its fields individually
- Asking approvals under the Approval sub-tab
- Uploading attachments under the Attachment sub-tab
- Adding resolutions under the Resolution sub-tab
There are a few configurations within the strict mode that allow you to restrict all or some of the above actions:
- Restrict All - The default configuration, restricts agents and teams from performing actions outside the transition window.
- Restrict Specified - Allows you to select actions and fields you want to restrict to
the transition window.
- Restrict All Except Specified - Lets you to exempt certain actions and fields from the strict mode.
To enable strict mode for a Blueprint:
- Select the Blueprint for which you want to enable strict mode.
You will land on the Blueprint Editor page. - Select the Blueprint Info tab at the top of the page.
- Toggle on the Strict Mode option under Advanced Configuration.
- Click Save Blueprint.
Dynamic Transition Owner
Enables you to assign transition owners dynamically from within tickets. For example when an assigned transition owner is unavailable and you want to immediately move the ticket to the next state, you can assign the transition dynamically to another agent from the same or different department and get the job done quickly.
Note - The ownership of a transition can be changed only by administrators and owners of that transition.
To enable dynamic transition owner assignment for a blueprint
Open the blueprint for which you want to enable dynamic transition owner assignment.
Navigate to the blueprint info tab and scroll down to advanced configuration.
Under advanced configuration, toggle on Dynamic Transition Owner Assignment.
To assign transition owners dynamically
Open the ticket that has the desired transition.
In the transition bar, click on the () icon to view the blueprint flowchart.
Hover on the desired transition, this will show the transition owner drop-down.
In the transition owner drop-down, click on assign transition.
This opens the dynamic transition window, here you can assign the ticket to agents from the parent department or from a different department.
Defining SLA Policies for States
Now that you have put a support process in place, you must ensure that it gets completed on time. SLAs help you do exactly that.
Service Level Agreement (SLA) help you determine how much time is required to complete a Blueprint process. It also provides visibility when things don’t work out as defined. If, for example, you want tickets in a "Pending Approval" state to have an approval time that is less than or equal to 30 minutes, you would set an SLA target of 30 minutes. You can also tie this SLA target to your Business or Calendar hours. When a ticket breaches this time, it can be escalated to the customer support manager or the ticket owner. Similarly, you can define SLA targets for each state of a Blueprint.
To add SLA for a state:
- Click the State for which you wish to define the SLA on the Blueprint Editor. Example, Pending Approval.
- Toggle the State-level SLA option to ON.
- Set the SLA time for which the ticket can be in the Pending Approval State.
You can enter hours, minutes, or days. - Now, specify the escalation procedure when the ticket breaches the set SLA time.
- Click Add Level 1 Escalation and do the following:
- Select when and at what time frame should the users be notified.
You can choose to be notified before, on, or after the SLA time. - Specify who should be notified from the drop-down menu.
- Select the Escalation Email Template.
The chosen template will be sent as an email when an escalation occurs. - Click Done.
- Repeat the steps to add Level 2 Escalation.
Points to remember
- Blueprints are triggered in the order in which they are listed on the Blueprint page. You can reorder your list of Blueprints to designate the order they're fired in.
- When a ticket is created or updated, it runs through all of your assignment rules, workflow rules, SLAs, and Round Robin rules in that order before we run that ticket through the Blueprint system.
- Different agents can own different transitions in a process. If an agent does not have access to a ticket but is made a Transition owner, then the agent will be able to execute the Transition but not edit the record.
- You can add up to 16 transition connections (I/O points) from a State.
- Only the specified transition owners can perform a transition on a ticket. Other agents including administrators can only view the process flowchart from the current state.
- When you save a Blueprint, it moves to your production instance immediately, i.e., you will begin having tickets entering it.
- Sometimes, agents may not have the permission to edit records or fields or reply to a ticket; however if they are the transition owner then they will be able to edit the fields, update values and even reply to the ticket if those actions are part of the Blueprint transition.
Editing a Blueprint
You can edit Blueprints to change their transition blocks or modify their process flow. However, please keep in mind that you cannot delete the Transitions and States when there are active tickets in the Blueprint process.
- Click the Setup icon ( ) in the top menu.
- Click Blueprints under the Automation menu.
- On the Blueprints page, click the name of the Blueprint you want to edit.
- Make the required changes and then click Save Blueprint.
Notes:
- Any change made to the Transition blocks in a Blueprint is effective immediately, regardless of new tickets or existing tickets in the process.
- Modifying the Before Transition settings in a Blueprint only affects new tickets that enter the process.
Saving Blueprint as Draft
You can save a blueprint as draft to revisit and edit the flow later as per requirement. While creating the blueprint, you will get an option to save it as draft or to save as draft and leave.
Revoking Tickets
If you find that a ticket is no longer necessary to advance through a Blueprint process, you can easily disconnect it from the Blueprint. This disassociation can be done either for individual tickets (from within a specific ticket) or for all tickets simultaneously (through the Blueprint settings).
To revoke blueprint from a ticket
- Open a ticket that you want to be revoked from a Blueprint.
- Click the More Actions icon (...) in the upper-right corner of the page.
- Click Revoke Blueprint from the drop menu.
- The Blueprint association is removed from the ticket.
Note: Users with Revoke Blueprint option enabled under Ticket permission can revoke a blueprint from a ticket.
To revoke tickets from blueprint
- Click the Setup icon ( ) in the top menu.
- Click Blueprints under the Automation menu.
- On the Blueprints page, hover your mouse over the Blueprint whose tickets you want to revoke.
- Click the More Actions icon (...) corresponding to it and then click Revoke Tickets.
- Click Continue to confirm your action.
- The Blueprint association is removed from all applied tickets.
Notes:
- Users with Helpdesk Automation option enabled under Administrative permission can revoke tickets from blueprint.
- All revoke actions will be recorded in the history of the ticket.
Deactivating and Deleting Blueprints
If you decide that you no longer need a Blueprint, you can either deactivate it or delete it. Deactivating a Blueprint means that further tickets do not enter the process. Deactivated Blueprints are listed on the Blueprints page, and can be reactivated later.
To deactivate a Blueprint:
- Click the Setup icon ( ) in the top menu.
- Click Blueprints under the Automation menu.
- On the Blueprints page, toggle the Deactivate option corresponding to the Blueprint to OFF.
- Click Deactivate again to confirm your action.
The Blueprint is deactivated.
If you decide to get rid of a Blueprint permanently, you can delete it from Zoho Desk. Keep in mind, that you cannot delete a Blueprint while there are active records in the process.
To delete a Blueprint
- Click the Setup icon ( ) in the top menu.
- Click Blueprints under the Automation menu.
- On the Blueprints page, hover your mouse over the Blueprint you want to delete.
- Click the More Actions icon ( ) corresponding to it and then click Delete.
- Click Delete again to confirm your action.