Request Life Cycle in ServiceDesk Plus Cloud allows admins to formulate a request resolution process with built-in guidance for the help desk technician. Through a simple drag and drop process, the SDAdmin or HelpdeskConfig 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 incident or service templates. For example, you can define a life cycle for any asset request and associate it with service templates configured for laptop, mobile phones, or any hardware requests.
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 Request Life Cycle feature, you can provide adequate guidance to the technician to resolve the assigned requests. When a life cycle is configured to a request 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 incorrect customer notifications on the request status. That is, for a request that is temporarily put on hold, if the technician chooses Closed, instead of Onhold, the customer might receive an incorrect (closed) notification for the request logged.
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:
Request Life Cycle Terminology
Configuring Request Life Cycle
Life Cycle Status Modifications
Before you configure the request life cycle, familiarize yourself with the following terms:
Status is the actual state of the incoming request. For example, all logged in requests are in the Open status while all requests 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 request 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 request 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, execute a custom function, 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 request. They are not status/es; they can be connected to active statuses such as Open/Assigned or Completed/Closed. While creating a request, only the status/es connected to the Start block will be shown in the New Request form to the user.
Before: This refers to the phase before a transition occurs and the request 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 request into the In-Progress status, you can select $Ticket 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 request to move into the status. The criteria define whether the transition will be shown to the technician. For example, you can define the Approval Status criteria as Approved. That is, only if the Approval Status of the request is approved, the next transition, say Assigned is shown in the Request 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 request is moving into a specific status. These configurations have two parts, mandatory fields and rule set. While the request is about to move into the status, you can mandate certain fields. For example, you can mandate the technician field for all requests to move into the Assigned status, or the Resolution field for all requests in the Resolved status. That is, the user must fill out the mandatory fields for the request 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 requests from VIP users, when the request moves into the Assigned status. (refer Fig.)
After: This refers to the phase when the request has moved to a status. Here you configure rules to check for criteria and accordingly define custom actions, such as sending notifications, adding tasks, executing a custom function, and triggering webhook. (refer Fig.)
You can configure notifications for technicians and stakeholders. Notification templates can be configured and sent to users, such as $Requester, $Technician, and $Group Members. You can also send notifications to specific technicians. You can append the request fields by using $. For example, when a request from a VIP user is assigned to a technician, a unique request assignment notification can be configured to be sent.
Custom functions allow you to manipulate data in ServiceDesk Plus Cloud and external applications. For example, you can reopen a Jira issue whenever the corresponding request moves into the Reopen status.
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 an issue in Jira once a request moved into the Approved status in ServiceDesk Plus Cloud.
You can add tasks to a request after the request moves into a specific status, say Approved.
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, requests 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 >> Request Life Cycles.
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 .png?Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9kemY4dnF2MjRlcWhnLmNsb3VkZnJvbnQubmV0L3VzZXJmaWxlcy84NjYvMjUxNC9ja2ZpbmRlci9pbWFnZXMvcmVzZXQoMSkucG5nIiwiQ29uZGl0aW9uIjp7IkRhdGVMZXNzVGhhbiI6eyJBV1M6RXBvY2hUaW1lIjoxNzY2MDc4ODU3fX19XX0_&Signature=V5RzF2XD8SIo4NU~d5~L1kNLqLsXw3hnWnqRnaovRJVUv~JusFureB~x10xPAS9bvorCEoBrSlEJovnpfVIgvPF1evExZTD7CtnFAzgSFwSTHLmFS5r8-DtGlfp6si3M6bCngWCqnc9F1IssS5H~gV4cIad8Xvg50Jh5A9Pu0rIf3dfH9vkk4AaMb560uBjpVG8i2pL20R5hNsc3LizzIkmfHDv~EHLGRJaw1gKvAIqOScFFSiUfbS2zAu20x4oR9tEIQ35ILLd5WR8wgmHbJOCjeNFXgxwg0jQfDivvwAGcuRofd2h2DCs75qNEeq0ATlA6YpgJC5SYXhOVG-av0g__&Key-Pair-Id=K2TK3EG287XSFC)
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 Request Details page.
The request life cycle begins at the Start block and completes at the End block. While creating a request, only status/es connected to the Start block are displayed to the user. Similarly, the request flow is closed only when the request 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 one of the most commonly raised requests in any organization; the request for a laptop. This life cycle can be associated with service request templates already configured for desktops, mobile phones, and other hardware requests.
The request resolution process for this request will contain the following statuses: Open, Approval, 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 request may not necessarily be linear. For example, an open request can be canceled or even rejected. Similarly, a closed request 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 request will remain in the same status.
The following screenshot displays the life cycle for a laptop request:
For the sample life cycle, let's look at the configurations set up for the Assign Technician transition. First, you can make the transition visible only to the request's Group Head. In that case, under Before > Scope > Organization Roles, select Group Head of Request. For the request to move into this status, you can choose the Approval Criteria as Approved.
Then, when the request moves into the Assigned status, you can mandate Technician and Group for the request resolution. This might appear as a pop-up to the technician working on the request. Also, you can configure a rule to set the priority as high if the request is from VIP user.
Finally, when the request has moved into the Assigned status, you can execute rules on the fulfillment of certain criteria. For example, you can write a custom function to trigger the tasks added to the request. Also, if the request is from a VIP user, you can send a notification to the SDAdmin, including SLA details 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 issue in Jira.
The sample life cycle has a common transition called Reopen that allows technicians to reopen the request from various statuses such as Closed, Cancelled, and Rejected.
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.
Request life cycle configurations for status modifications take precedence over all other configurations and rules, including business rules.
In the following cases, life cycle configurations can stop request processing:
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.
Following screenshots capture the linear and map views of the life cycle to associate with the Request for Laptop (discussed above).
.png?Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9kemY4dnF2MjRlcWhnLmNsb3VkZnJvbnQubmV0L3VzZXJmaWxlcy84NjYvMjUxNC9ja2ZpbmRlci9pbWFnZXMvU2NyZWVuJTIwU2hvdCUyMDIwMjAtMDQtMDYlMjBhdCUyMDdfMDdfMzYlMjBQTSgxKS5wbmciLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE3NjYwNzg4NTd9fX1dfQ__&Signature=UP4t5xW6ji2tMyH0o4vYp~VsYzIVBtRKp1wcM12XyTaWlau627fXIXx2ioQn3fqnlrVoYYzIcyQ6vuKDv~A97OnwE5-3wVEUbKQCE6d-Vp4cM2kEXyLgxBVqHFXYV9FKqfxfo1tE4r1IpP8TGMWBULlTq5WON-TmnCpIKgRPLuwzWald7-9h2gfJyZqhyXFyEcUWCDv8053Cu3nsWlQ4BDhuWjrpoDuDHD6ZlQEJopr-Qhv6KunCTfz~RFO1tjIUNMdhGATxtaAgt~ADPvgKw6d1ssLZy90aRkbeVQhlR7jkRawbKa98kiLgsSQtbRfnDLrhYzbUQgxbrR6RRWjPSg__&Key-Pair-Id=K2TK3EG287XSFC)
As you configure the life cycle, you can modify details such 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 .png?Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9kemY4dnF2MjRlcWhnLmNsb3VkZnJvbnQubmV0L3VzZXJmaWxlcy84NjYvMjUxNC9ja2ZpbmRlci9pbWFnZXMvaGlzdG9yeSgyKS5wbmciLCJDb25kaXRpb24iOnsiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE3NjYwNzg4NTd9fX1dfQ__&Signature=CbL8ecGcg~1WXoU-q9sqtb8Ir2YdLCqxk8qyMx4heGYv53uBE9ufZYVpKBvV0RwhQxCv8HUkhZUZ-EgNw00e4AN9PNCya9OG5zPfg2NimCjE83ROpjVfWK2AbZKtvJ1VF1oaAqMy39mde0AeQlwxkLj2OaF4nylf66ZGY77qP1fN8g8mW4kp8Q~YKXdfNuQ8EvG0fruxR8VbpFT4x1Cg05ObPxbMGXVI9mvv4xdVLJESgmVrTbjo06NwEIu0dgWN3ynrmBHjhn7Rj-6KO0WlObxShYUBPCQO~9PZvP808hKsxrVkMKH9mXYXqFIIzZ69oCTGuUobG8aL-WwBOSnYcg__&Key-Pair-Id=K2TK3EG287XSFC)
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 
icon.
Click .png?Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9kemY4dnF2MjRlcWhnLmNsb3VkZnJvbnQubmV0L3VzZXJmaWxlcy84NjYvMjUxNC9ja2ZpbmRlci9pbWFnZXMvZXhwb3J0KDEpLnBuZyIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTc2NjA3ODg1N319fV19&Signature=GaetnCH7QEJFe2kDm3KIAbLLn3zLc17XPk64quC7jkb-2uIITtDUzCl6tFrmXL7hVWpcaGCOWyv033qPBOjVirKjriZmG2Gyw~WUNBwuWMCaAIHSYC4T4yjJZOT~OmJ5M63gd96CeWsOhCitCkjKJpHSx4jmRS92rMrvK3KmXioubgkhu~0-K02zlbpxBTHJ1sQhPFAett-d-W-jKCMdFJw0866XCzkqeOrFnUqmV--Oo~J-fKwUfXT3iPpiNciuvsjAbPxd~DzIDUam0SThs26rhZe5F1asJXMUbBBTr~hZpewGAxUeappmKDqF726nE3Y1jhmpcaz0sB6cSsEIQA__&Key-Pair-Id=K2TK3EG287XSFC)
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 request associations with the life cycle. (The number of requests 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.
To create a life cycle as a workflow, click the Actions icon beside the life cycle and select Create as workflow.
Below are a few limitations when converting a life cycle to a workflow:
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 Request 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 request in the After phase.
Connect ServiceDesk Plus Cloud with third-party application and sync data by configuring webhooks in the After phase.
Enable actions over third-party applications by configuring custom functions in the After phase.