Problem life cycle allows admins to design a problem resolution process with built-in guidance for help desk technicians. Through a simple drag and drop process, the SDAdmin can create a visual process builder and define the resolution process. You can create, discuss, and rework the process drafts before publishing the life cycle.
Define life cycles for processes specific to your organization and associate them with problem templates. For example, you can define a life cycle for slow internet bandwidth in your organization.
A life cycle ensures efficient process adherence; you can establish a directional flow, minimize the scope for human errors, and provide privileged (role-based) access to status transitions.
Using the Problem Life Cycle feature, you can provide adequate guidance to the technician to resolve the assigned problems. When a life cycle is configured to a problem template, only the next possible transitions and the allowed status/es will be available for the technician to choose from.
In the absence of a life cycle, as shown in Fig. 1, the technician can choose any status, which could lead to deviation of the resolution process.
On the other hand, using the life cycle, admins can control the status/es (Fig. 2 and 3) that a technician can choose from, ensuring status accuracy and correct customer communication. Moreover, admins can also configure the next possible transitions for each status. This will provide the much-needed guidance for the technician and you can ensure process adherence and reduce any scope for process violation.
To know more about configuring the life cycle, you can sequentially go through this document or click the appropriate sections from the following links:
Problem Life Cycle Terminology
Configuring Problem Life Cycle
LifeCycle Status Modifications
Before you configure the problem life cycle, familiarize yourself with the following terms:
Status is the actual state of the incoming problem. For example, all logged-in problems are in the Open status while all problems that are waiting for updates will be in the On-Hold status. The life cycle includes Stop-Timer status/es as well.
You can configure these statuses under Admin >> Customization >> Helpdesk >> Status.
Transition refers to the actual movement of the problem from one state to another. A transition is further divided into Before, During, and After. Under each phase, you can configure various settings to control the status movement of the problem and also configure specific settings such as provide privileged access, customize notifications, mandate fields, and execute rules on the fulfillment of specified criteria.
You can also configure various actions under each transition. For example, you can update fields, send notifications, add a task, trigger webhook, and abort a process execution. These are transition actions.
Start/End Block: These are representative of the initial or the final phase of the problem. They are not status/es; they can be connected to active statuses such as Open/Assigned or Completed/Closed. While creating a problem, only the status/es connected to the Start block will be shown in the New Problem form to the user.
Before: This refers to the phase before a transition occurs and the problem can move into a status. This phase has two configuration settings, scope, and criteria. Under scope, you can restrict the transition access to specific organization roles, technician roles, and technician groups. You can also provide the transition access to the assigned technician and the group members. For example, if only the assigned technician can move the problem into the In-Progress status, you can select $Problem Owner under Groups. Under such a configuration, you'll make the transition visible only to a specific role or to the technicians in the specified support group. Under Criteria, you define the conditions for the problem to move into the status. The criteria define whether the transition will be shown to the technician. For example, you can define the Group criteria as Hardware. That is, only if the Group of the problem is Hardware, the next transition, say Assigned is shown in the Problem Details page to the technician. You can add only a single criterion, under which you can define multiple conditions by using AND, OR operators. (refer Fig.)
During: This refers to the phase when the problem is moving into a specific status. These configurations have two parts, mandatory fields and rule set. While the problem is about to move into the status, you can mandate certain fields. For example, you can mandate the technician field for all problems to move into the Assigned status. That is, the user must fill out the mandatory fields for the problem to move into the next status. Rules can be configured to update fields or to abort the particular process execution on the fulfillment of certain criteria. For example, you can set a high priority for problems with high impact, when the problem moves into the Assigned status. (refer Fig.)
After: This refers to the phase when the problem has moved to a status. Here you configure rules to check for criteria and accordingly define custom actions, such as sending notifications, adding tasks, and triggering webhook. (refer Fig.)
You can configure notifications for technicians and stakeholders. Notification templates can be configured and sent to users, such as, technicians and organization roles. You can append the problem fields by using $. For example, when a problem with high impact is assigned to a technician, a unique problem assignment notification can be configured to be sent.
A webhook enables you to call an external URL or API to integrate ServiceDesk Plus Cloud with any third-party application. For example, you can configure a webhook to create a change if no solution is found for the problem.
You can add tasks to a problem after the problem moves into a specific status, say Assigned.
Common transition allows you to connect multiple statuses to one status without duplicating the transition configurations. In other terms, when two or more statuses converge into a single status through the same transition, you can mark the transition common. For example, problems might need reopening from any Completed status, such as Resolved, Fixed, and Closed. You can configure this by marking a common transition, say Reopen, between the completed statuses and the Reopen status.
Go to Setup >> Automation >> Life Cycles >> Problem Life Cycle.
Click New Life Cycle, provide a name and description for the life cycle, associate the relevant templates, and click Next as shown below:
An empty canvas will be displayed. Use the Zoom buttons on the left to increase or decrease the size of the canvas. You can retain the default size by clicking 
icon. You can also move the life cycle around the canvas by using the hand tool cursor.
To add a status to the life cycle, drag it from the right panel. As you drop the status on the canvas, Start and End blocks are displayed with the new status connected to the Start block. To connect two status/es by a transition, hover over a status, click the plus sign and drag it up to the next status. Click the button that appears on the connector to provide the transition name and description that will be displayed on the Problem Details page.
The problem life cycle begins at the Start block and completes at the End block. While creating a problem, only status/es connected to the Start block are displayed to the user. Similarly, the problem flow is closed only when the problem reaches a status connected to the End block. Ensure that the default statuses configured in the associated templates are connected to the Start node in the life cycle. For example, if the status in the associated template is Open, make sure that the status you connect to the Start node in the life cycle is also Open.
Let us configure a sample life cycle for slow internet bandwidth problem in your organization. This life cycle can be associated with problem templates already configured for slow internet bandwidth.
The resolution process for this problem will contain the following statuses: Open, Workaround Sent, Assigned, In Progress, Asset Provisioning/PO Raised (if the asset is not available already), and Closed/Rejected/Cancelled. Note that the status movement of the problem may not necessarily be linear. For example, an open problem can be canceled or even rejected. Similarly, a closed problem can also be reopened. The processes that happen between status/es are configured under a transition.
All transitions, except the Open status transition, will contain three phases to be configured: Before, During, and After. Note that it is not mandatory to configure all the transitions or their phases. You can choose to configure just one transition or just one phase of a transition to suit your requirements. However, to automate the status movement through the transition you must configure the transitions for every status within the life cycle. In the absence of transition configurations, the problem will remain in the same status.
The following screenshot displays the life cycle for slow internet bandwidth problem:
For the sample life cycle, let's look at the configurations set up for the Analyze Root Cause transition. First, you can make the transition visible only to the problem's Group Head. In that case, under Before > Scope > Organization Roles, select Group Head of Problem. For the problem to move into this status, you can mandate Root Cause and Symptoms fields.
Then, when the problem moves into the Root Cause Analyzed status, you can mandate Group and Technician for the problem resolution. This might appear as a pop-up to the technician working on the problem. Also, you can configure a rule to set the priority as high if the problem has high impact.
Finally, when the problem has moved into the Analyzed Root Cause status, you can execute rules on the fulfillment of certain criteria. For example, you can add tasks to the problem. Also, if the problem has high impact, you can send a notification to the technicians, including services affected or any other important information.
Let's consider another transition to include the webhook configuration. Under the After phase of the Reopen status, you can configure a webhook to reopen the corresponding change.
The sample life cycle has a common transition called Reopen that allows technicians to reopen the problem from various statuses such as Closed and Cancelled.
After you configure all the transition settings across all statuses, you can save the life cycle as a draft to work on it at a later point time, or publish it right away. Note that life cycle configurations will be saved only when the Save as Draft button is clicked. To publish the life cycle, click Publish on the lower half of the page.
In the following cases, life cycle configurations can stop problem processing:
1. No transitions are configured for the current status to move to the target status.
2. Before conditions (scope and criteria) are not met.
3. When an abort process is configured.
For a linear view of the life cycle, select Linear View from the drop-down on the upper half of the page. The linear view provides the list of all transitions and their configurations. The Map view provides a graphical representation of the life cycle. Under both views, you can view the details of only one transition configuration at a time. You cannot modify the life cycle configurations in the linear view.
The following screenshots capture the linear and map views of the life cycle to associate with the Slow Internet Bandwidth Problem (discussed above).
.png?Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9kemY4dnF2MjRlcWhnLmNsb3VkZnJvbnQubmV0L3VzZXJmaWxlcy84NjYvMjUxNC9ja2ZpbmRlci9pbWFnZXMvcGIxMCgyKS5wbmciLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE3NjYyNzkxODd9fX1dfQ__&Signature=G2zTxh2FAx1TF1CmGmpUd3wt8YwVcblcp-KSJHCwOCMKPFdgkS6hwKQlD5UD-rnshFInOrznePCPThT8P5XvlNTM9NsFCDdVwZM2AjF1unGd1jvpl4WTgcXhjkoYb5OCR8ZXtKgMsCbTMv4hIDpjRuJP2wqyhZRzQ0CyjuxYDPRLZW0jtQcvLR1JnrGx7XwWXY2NvfT76TW3lbYM4wKclFBfCxEAUDEm6VeFfAlP-9Vs1G9g-vJBb4y-bEMU3rMBiUmjAERd3KrmajxnprATl8VeE7EtG49l5BGl2votrFKQshv30asnk~ZUkf~7tBVITAxlsvI~0jD7pjGbs1dzpA__&Key-Pair-Id=K2TK3EG287XSFC)
As you configure the life cycle, you can modify details such as name, description, and template associations displayed on the upper right corner of the page. Click any field to open the editor and modify the value.
Click the 
icon on the upper-right corner of the page to view the individual actions performed on the life cycle. You can view more details about the life cycle creation and update by clicking the 
icon.
Click the 
icon on the upper-right corner of the page to export the life cycle as a PDF file.
The Edit button under Settings allows you to modify the complete life cycle, including the workflow. You can either save the modified life cycle as a draft or publish it right away.
To disable or delete a life cycle, click the Settings icon next to the life cycle. During both operations, you can choose whether to preserve the existing problem associations with the life cycle. (The number of problems currently associated with the life cycle will be displayed.)
To activate a disabled life cycle, click Enable by using the Settings icon. Alternatively, you can click the toggle button on the right corner of the life cycle.
To publish a life cycle draft, click Publish under the Settings icon.
To duplicate a life cycle, click Copy under Settings. Copied life cycles will have only the workflow duplicated. No template will be associated and the life cycle will remain unpublished.
The Search field allows you to locate any life cycle by using its name or the associated template. Click Search, choose the criteria between Name and Associated Templates and type out the first few letters of the item in the field. The matching results will be listed below.
The Problem Life Cycle feature in ServiceDesk Plus Cloud is a drag-and-drop life cycle builder that can be effectively used to provide guidance to the technicians.
A transition refers to the path between two statuses, and each transition is further divided into Before, During, and After phases with individual configurations.
Restrict the visibility of the transition to specific Organization/Technician Role or Group by configuring Scope in the Before transition.
Define when the transition can be invoked by configuring Criteria in the Before transition.
Collect relevant and just in time data by configuring mandatory fields in the During phase.
Update field values on the fulfillment of certain criteria by configuring Rules in the During phase.
Check the transition's validity and abort it if necessary by configuring Rules in the During phase.
Notify relevant stakeholders by configuring email notifications in the After phase.
Add the necessary tasks with the problem in the After phase.
Connect ServiceDesk Plus Cloud with third-party applications and sync data by configuring webhooks in the After phase.
