2.5 Change

2.5.1 Change Management

The goal of Change Management is to ensure that standardized procedures are used to efficiently handle all changes, and minimize the impact of any related Incidents upon a service. The Change Management process prevents unauthorized CMDB modifications and reduces disruption to Customers. It does this by coordinating the build, test and implementation of any change that impacts the CMDB.

Changes may arise reactively in response to Problems or externally imposed requirements, for example a new or changed regulatory situation. They may also be proactive, instigated by management to improve an organization’s efficiency and effectiveness, or to enable or reflect new service improvement initiatives.

The Change Advisory Board (CAB) is responsible for approving any Request for Change (RFC). This involves assessing the impact, resources and priority of the RFC. The CAB then advises the Change Manager of their assessment and assigns an appropriate Workflow.

Change Workflows within the system ensure that each RFC is handled with consistency, based on the risk and impact assessment of the CAB. Change Workflows define the actions required to correctly implement the change, and define the responsibilities, authorization and timescale expected to manage the change.

Once a Workflow is assigned to an RFC, it is routed to an appropriate Technician based on the Change Workflow State. After a Technician completes their assignment, the RFC is forwarded to the next Technician based on the next state of the Change Workflow.

When the RFC has progressed through all of the required Workflow States, a change review is undertaken to verify that the RFC has achieved its objectives. If the change objectives are not met, the RFC’s associated back-out procedure is implemented to rollback the change and restore the CMDB to a valid state.

As part of the Change Management Process, all requests related to a Change Request are automatically closed when the related RFC is closed. The system views the request hierarchy from low to high as Service Request, Incident, Problem and Change Request, and if a related request of a higher type is closed, all the lesser type requests are automatically closed.

Implementing Change Management

To set up the Change Management Process in the system, the following steps are to be completed:

Assign the Change Process to the relevant Users within the User Information screen under the User>Users tab.
Create or review the SLA within the Service>SLAs tab, and associate the Incident Service Request Workflow to the SLA in the SLAs Workflow tab. (NB: The Supervisor User setting up the SLA must be assigned the Internal Process of Service Level in their User Information screen to complete this action.)
Review on or more Change Management Workflows within the Service>Workflows tab.
Create a Change Management Team within the User>Teams screen.
Associate the SLA to an Item or Customer or Org Unit. This final step ties all the elements together when a Change Request is created, as the SLA associated with the Item, Customer or Org Unit assigned to the Request determines the Workflow, Team and Technicians that are made available within the Service Request Information screen.

Change Requests (RFCs)

The Change Request tab defaults to display all Requests for Change (RFCs) logged within the system. The available List Filters include:

Filter	Description
All Change Requests	Displays all Change Requests logged in the system regardless of their Status or Assignment.
My Change Requests (Active)	Displays all Change Requests in an active Workflow State that are assigned to the logged-in User.
My Change Requests (All)	Displays all Change Requests, in active and inactive Workflow States, that are assigned to the logged-in User.
My Teams Change Requests (Active)	Displays all Change Requests in an active Workflow State, allocated to the Teams with which the User is associated.
My Teams Change Requests (All)	Displays all the Change Requests, in active and inactive Workflow States, allocated to the Teams with which the User is associated.
Pending Approvals	Provides the User with quick access to a list of Change Requests that require Manager approval. (This is only available if the User has Manager access.)

The default display is ten RFCs per batch. The list can be re-sorted by clicking on a column header and the number of RFCs displayed per batch can be altered using the Display pop-up option.

Creating an RFC:

To create an RFC within the Change Requests tab, the following information is required:

Change Request Search Tips:

The Change Request search option has a default Status to search only Active Requests. To ensure search success, select the relevant Incident Status, if unsure, select All
To search for multiple RFC numbers at once, insert a comma separator between ID numbers
To search based on an RFC status, select the RFC Workflow option from the Workflow drop-down list. Once selected, a list of States is displayed
To search by Classification, select an Item Category from the Category drop-down list. After the category is chosen, a list of Classifications is displayed
To search based on the content of an RFC Description, select the Full Text option within the Search and enter a relevant term.
To search using an Item's Custom field information, select the Item Category to display any Custom Fields enabled for that Item.

RSS Feeds

To easily access up to the minute details regarding Change Request activity within an RSS feed browser bookmark, Users can subscribe to RSS feeds by selecting the RSS button within the Change Request list. When the RSS button is selected, Users are presented with the application options for subscribing to receive the information and where the Recent Activity information is to be accessed. To readily access the information through a browser window, save the feed the to the Bookmark Bar.

The following is an example of the information obtained by clicking on the RSS bookmark:

Customer Tab

The first step in creating a new RFC requires that a Customer be assigned to the request. There are two ways to assign a Customer to an RFC, either search and select an existing Customer or create a new one.

Create an RFC for an existing Customer

To search for and assign a Customer who already exists in the system:

Go to Change>Change Requests
Click New
Search and select a Customer

Within the Find Customer field, enter any known Customer details or leave the search field blank to access the complete Customer List. If Custom Fields have been enabled in the Customer Information screen, the Advanced Search option can be used to search on data recorded within these fields.
Click to search the Customer database
Select the relevant Customer Name hyperlink to assign the Customer details to the RFC.

The screen will open the Find Item field.

Create an RFC for a new Customer

If the Customer does not exist within the system, an account can be created when entering the RFC:

Select Change>Change Requests
Click New
Within the Find Customer field, select

An expanded editable Customer Details form is displayed.
Enter the Customer details
Click Save

The form will revert to a non-editable screen of the newly entered details.
Click Next to assign an Item to the RFC. Or select Quick Call if a template is to be used.

Supported Org Units Only option

This option is visible within the Find Customer search field, if the logged in User has been assigned to support specific Organizational Units. Uncheck the option, if search results are to include Customers belonging to all Organizational Units recorded in the system.

Quick Calls

Quick Calls are used for common requests that are logged using a template during the Change Request creation process.

If the Quick Call functionality is enabled for the system, after the Customer and if relevant, Item details are assigned to the RFC, within the Details tab the Quick Call options are displayed below the dashed line in the Request Type drop-down list.

NOTE:Quick Call Templates also define the stage of the Workflow for the RFC being created, which enables pre-approved RFCs to be created in the system.

Quick Calls and Item Assignment

When creating a Quick Call, an Item can be assigned after the Customer information has been set or when the Quick Call template is applied to the Request.

If the Item is to be assigned to the RFC using the Quick Call Template configuration, the User simply selects the Next button after assigning the Customer information to the RFC. The application moves to the Details tab and within the Request Type options, the list displayed only includes Templates that have Items preset.

NOTE:The Next button will only be visible after the Customer has been assigned to the RFC, if Quick Call templates that have Items assigned are configured in the system.

If a specific Item is associated with the Quick Call Request within the Customer tab, the options displayed within the Request Type drop-down list will include Quick Call templates associated with the Item Type already assigned to the Request, and templates assigned the Unknown Item.

For RFCs created with multiple Items assigned that use different Items, Quick Call templates with no Items assigned are displayed. For RFCs where the same Item is assigned on multiple occasions, Quick Call templates that have the matching Item and no Items assigned are made available in the Request Type drop-down list.

To create an RFC using a Quick Call:

After allocating a Customer and Item(s), click Next to move to the Details tab
Within the Request Type drop-down list, select the relevant Quick Call template displayed below the dashed line
Assign the Classification
Click Done

All RFC details will be populated according to the Quick Call template. Any amendments can be made through the RFC Summary screen.
Click Save.

NOTE:When saved, the Request created using the Quick Call template can be duplicated to minimise data entry requirements for multiple similar Requests.

Item Information

After the Customer details are assigned to the RFC, an Item or Items are associated with the Request. This assignment sets all the relationships of the Item(s), including service level agreements and Team assigned to support the RFC.

If the Customer assigned to the RFC owns Items directly, they are listed below the Find Item search box. By default, the list is defined by the All Assigned Items option, but it is also possible to search by:

All Items

(Only visible if the Search All Items option is enabled within Admin>Setup>Privileges>User tab.)
All Assigned Items (Customer and Organizational Unit)
Assigned Items by Customer
Assigned Items by Organizational Unit

The list can be filtered using the Include Global* Items option. This will display Items that are available to all Users in the system, as they have not been assigned to a specific Customer or Organizational Unit. It can also be filtered using the Active Items Only option, which means only Items that are assigned an active lifecycle state are displayed if the option is checked.

Multi-Item Requests

The system also allows for multiple Items to be assigned to a Request during the Request creation process, if relevant. This results in separate RFCs being created for each Item assigned to the initial RFC, which are then displayed within the Related Requests window within the Change Request Information screen.

The Requests are managed as individual RFCs to cater for any special requirements relative to each Item. For example, consider a situation where a Team rolls-out an update in an organization. In this instance, during the Request creation process multiple Items are assigned to a single RFC, which the system automatically allocates to separate RFCs that are then managed on an individual basis. This allows appropriate Teams/ Technicians to be assigned to the RFCs relative to their skill-set or departmental assignments. The implementation process more effectively differentiates between the tasks and Items being modified and ensures each Item has its own Audit Trail, Attachments and Notes for future reference.

Multi-Item Requests are listed as separate RFCs within the Change Requests List View, and can be accessed as a group with the Change Groups List View.

RFC Item Assignment

To assign an Item to the RFC:

Click the relevant Item link if listed below the Find Item search box

Or, Search for an Item or click to Create an Item

The option to create an Item is only available to Technicians if the system Administrator has enabled the Create Items option within the Setup>Privileges>User tab.
Click Next to move to the Details tab if only one Item is to be assigned to the Request

Or, select Add to assign additional Items. If Add is selected, a Request Selections window will be displayed that lists all the current Items assigned to the Request.
Continue to add all the relevant Items to the Request and then select Next to move to the Details tab.

Within the Details tab, the RFC is profiled by assigning a Classification and RFC Description.

Contract Tab

When Contracts are enabled for the system, the Contract tab is visible within the Change Request Information screen.

The Contract tab of a Request includes the details of the Contract Type and SLA assigned to the Request. If a valid contract is active for the Customer, Item or Organizational Unit assigned to the Request, then the details of the contract will be displayed. If an SLA is not assigned to the Customer, Item or Org Unit and the Billing functionality is not enabled, the system automatically applies a default SLA based on the Item Type or the system default SLA.

When Billing is enabled and the Contracts or Invoices functionality is active, the system verifies the service entitlement status of the Customer assigned to the Request, and if a valid contract is not in place, the Request is assigned a status of Pending-No Contract and locked until a valid contract is associated with the Request. The Customer is automatically sent the NoContractCreateRequestSummary email when the Request is saved with this Status.

A reminder email can be sent to the assigned Customer by the Technician from within the Summary tab by clicking .

Details Tab

To successfully create an RFC, the Request must be profiled by completing the Request Type, Classification and Description details. Within the Details tab, there is also the option to select any relevant Quick Call Templates that have been configured for the Item Type assigned to the RFC.

Entering an RFC Description

To profile the RFC:

Define the Request Type

The New Change Request option is locked in if there are no Quick Call templates available for the Item or Process.
Select a Classification

If multiple Items are assigned to the Change, the option to assign a specific Classification for each Item Request is provided.
Complete any required customized fields
Define the Subject content, if desired
Enter all relevant information within the Description field

This is a mandatory field.
Click Done to enter the new RFC into the database.

A unique reference number is generated automatically for the request at this point. When a Change is submitted successfully, the RFC Summary Tab is displayed. If the Force Analysis functionality is enabled in the application's Setup, the system will move to the Analysis Tab.

Request Subject

It is recommended that a summary be included in the Subject field, as the details recorded in the Subject field are displayed in scroll-over summaries throughout the application. For example, when a new Request is being entered for a Customer, a Recent Customer Requests list is displayed during the Request creation process for all Items the Customer owns either directly or via shared ownership. The Requests list includes a scroll-over summary where Subject content is displayed, if the Subject is completed for a Request. Subject information can also be included within a column in the Change Requests List View, for a quick glance summary of a Change Request.

Analysis

Within the Change Request Analysis tab Backout Procedures can be created or the current RFC can be related to other requests. The options within the Change Request Analysis tab include:

Analysis Tab Drop-down Options
New Solution	Displays Knowledge Base editor to allow the User to enter a new Solution. Solution Articles are used as Proposed Solutions for future requests.
New Backout Procedure	Allows the User to create fallback plan, should the implementation of the Change Request not go to plan.
Link Incident	Allows the User to enter full text or ID number to search on Incidents. Select a No. link to immediately link the current RFC to Incidents.
Link Problem	Allows the User to enter full text or ID number to search on Problems. Select a Problem ID number to immediately link the current RFC to Problems.
Link Change Request	Allows the User to enter full text or ID number to search on Change Requests. Select a Change Request ID number to immediately link the current RFC with other Change Requests.
New Release	Allows the User to create a new Release package that is automatically associated to the RFC to manage the environment update.
Link Release	Allows the User to associate the RFC to an existing Release.
Alerts	Allows the User to create an Alert directly related to the Request. Displays any reminder alerts that have been created in the Summary tab of the Request. Select the Alerts option to view Alerts list, and click on an Alert Publish Date to view Alert Content.

Creating a Backout Procedure

RFC's can implement a Backout Procedure if a necessary fallback plan is required.

To create a Backout Procedure:

Select an RFC from Change > Change Requests
Go to the Analysis tab
Click Edit
From the drop-down list select New Backout Procedure
Adjust the Review Date, if relevant
Complete the Summary and Content fields
Upload any relevant attachments
Click Save.

Once the Backout Procedure is created for an RFC it can be viewed via the Request. To view a Backout Procedure:

Select the Analysis tab for the RFC
Select the View Backout Procedure option.

The page will expand to display the article.

Linking Requests

Within the Analysis tab, RFC's can be linked to other Incidents, Problems, Change Requests and Releases that are new or pre-existing.

Link with Requests
Link Incident	Allows User to enter full text or ID number to search on Incidents. Select an Incident ID number to immediately link the current RFC to an grouped Incident.
Link Problem	Allows the User to enter full text or ID number to search on Problems. Select a Problem ID number to immediately link the current RFC to a grouped Problem.
Link Change Request	Allows the User to enter full text or ID number to search on Change Requests. Select a Change Request ID number to immediately link the current RFC to a grouped Change Request.
Link Release	Allows the User to enter full text or ID number to search on Releases. Select a Release ID number to immediately link the current RFC to an existing Release group.
New Release	Allows the User to create a Release and manage the RFC implementation as part of Release and Deployment lifecycle. When selected, the screen defaults to a New Release Information window, where the Title and Description can be entered and other options edited and automatically associates the current RFC. For further information about Releases

To link a request to a Group, within the Analysis tab:

Select Edit
Search for a Request Group using the full text or ID option
Select the relevant search result ID number.

This automatically adds the current RFC with the existing group.

Creating an Alert

Within the Analysis tab, an Alert that is associated with the Request can be created by:

Select Edit within the Analysis tab
Select the Alerts option in the drop-down list

The New button is made accessible
Click New

Refine the content for each required field

Alert Details	Description
Created	The current date and time.
Publish	The date the Alert is published. Use the calendar icon to the right of the field, to select a Publish date. Set to a date in the future, or use the default to publish the Alert immediately.
Dismiss	The date the Alert ceases to be available. Use the calendar icon to the right of the field, to select a Publish date. On this date, the Alert will disappear from a User's Alert list.
Severity	The type of Alert to be published. The choices are: Information – for general Alerts Warning – to warn Users of potential issues Urgent – to publish an urgent actionable message. The icon appearing with the message will depend on the type of Alert.
User	The type of Users to receive the Alert, which include: Specific Customer or User User Role Personal Alert Organizational Units. In the Find User or Customer list, click search to select the recipient from the drop-down list. An Alert sent to a User Role will go to all Users with that Role. A personal Alert appears on the User's own screen at the Publish date.
Title	Enter the title of the Alert.
Message	Enter the main content of the Alert.

Click Save.

Summary Tab

Summary

The Summary tab provides comprehensive details related to an RFC and gives access to the tabs required to work on the RFC.

IMPORTANT:In the Summary page, you can view or update the available details:

To view details of a Customer, select the Customer name link within the Change Request Information screen.
To update details of the Customer and the Item assigned to the Change Request, click within the Summary tab when the change request is in Edit mode.

The Change Request Information Summary tab includes the following:

Summary Tab	Description
Details	The following details are displayed: Customer:The customer assigned to the RFC. Click on the customer name link to view customer information. Scroll over the information icon next to the Customer for quick information such as Username, Org.Unit, > Phone and Local Time. Item:An item assigned to the RFC. Select the Item Number link for more information about the Item. Scroll over the information icon next to the Item Number to view Item information recorded on the Details tab. is visible next to the Item Type, if the RFC is in a Workflow State with the Item Editable option is set to Yes. Click the icon to edit the Item details. Click to view the Item Relationship map. Any Item displayed in the map can be set as the Item associated with the Incident, by making it the central node of the Relationship map and clicking on the centralized map icon to confirm the Item assignment change. Type: is visible when the RFC is created as part of the "Control CMS via RFC" functionality and the RFC was created due to an Item update or creation. It appears in an Item Editable stage of the Change Workflow and allows the Item update details that prompted the creation of the RFC, which will be detailed in the Description field, to be applied to the CMDB. Classification: Displays the RFC Classification that was selected when the Change Request was created. This can be updated, if required. Urgency: Impact: Priority: Shows the Priority of the RFC, which determines the Service Level triggers applied to the Request.If the Derived option is enabled in the applications Setup, then the Urgency and Impact drop-down lists are displayed. The User is required to select the corresponding Urgency and Impact for the Change Request to alter the Priority assigned.

Assignments	The following details are displayed: Escalation: This is visible if the Escalation Control option is enabled in the application Setup. This is only available to the Supervisor, and allows them to disable the escalation timers. Escalation Layer: Shows the name of the current Group of Users assigned to the Request. When the Workflow State is updated, this could also result in an update of the assigned Group of Users. Technician: The name of the Technician assigned to the RFC. Subject: Description:
Notification	The following details are displayed: Customer: Shows how updates regarding the RFC are sent to the Customer who logged the RFC, or to all Owners of the Item associated with the RFC. Customer CCs: Customer CCs is a free text field for any additional notification recipients, these can be divided into Customer and Technician CC lists. Technician: Allows the User to adjust the default Technician notification between None, Email or SMS for updating the assigned Technician, all Technicians in the Team or Layer of Escalation assigned to the RFC. Technician CCs: Technician CCs is a free text field for any additional notification recipients, these can be divided into Customer and Technician CC lists. Alternate Team:Is visible if the Notify Alternate Team option is enabled in the Admin>Email>Setup tab. This allows the User to define another Team to be notified about updates regarding the RFC.
Change Request	The following details are displayed: Team: Displays the default support Team assigned to the RFC. This can be changed by selecting another option within the drop-down list. The Team list is derived from the Workflow and Workflow State. Workflow: Displays the default Workflow assigned to the RFC. This can be changed by selecting another option within the drop-down list. The Workflow list is derived from the SLA assigned to the RFC.Select to view the Workflow in its entirety. Status: Shows the current Workflow State of the RFC. Next Action: Lists all the states available after the current RFC State. This is based on the Workflow assigned to the RFC. To move the RFC through the Workflow, select a Status included in the list displayed. By assigning a different Workflow State, the Work or Manager Group assigned to the RFC may also be automatically updated, based on the Workflow and Team Configuration. Refer to the Escalation Layer and Technician Fields to view if an assignment change is made as part of the Status update. Status Due: Details the expiry time for the current Workflow State if the State has an OLA assigned.
Service Terms	The following details are displayed: Agreement : Displays the Service Level Agreement assigned to the RFC. The service level is derived from either the Item, Customer or Organizational Unit. Service Manager: Displays the name of the Service Level Manager responsible for overseeing Requests related to the assigned service agreement. Progress: Visually displays how the Request is tracking against the assigned SLA and displays the percentage of SLA used when greater than 10%. The grey progress bar is gradually filled in based on the status: - Workflow is in an SLA paused state. Triggers will not fire. - Workflow is in an SLA timers on state. Triggers will fire. . - Workflow is in an Exit state and the SLA has been successfully maintained. - Assigned SLA has been breached and Workflow is in an Exit state. Dates: Summarizes the important date details for the RFC. The Due Date is automatically calculated based on the Service Level assigned to the RFC. Time Recorded: Displays the amount of time the Request has been open and worked on. Affects: Displays the number of Users assigned to the Item.

NOTE:Only Technicians assigned to the Workflow Group associated with the RFC can edit the Change Request.

Summary Tab Buttons
	Edit opens the Request in edit mode. This allows the Request details to be amended, Notes to be added and time is automatically recorded against the Request whilst in edit mode.
	Changes the default assignee of an RFC to a different technician.This right is available only for technicians belonging to the same layer or team.
	Opens the Request in edit mode and moves directly to the New Note editor.
	Duplicate creates a copy of the Request and links the copy to the original Request. The User can then amend the Customer or Item details, if required.
	Print opens a summary of the Request in a Print View window. This includes a Description and all Notes added to the Request. It is a good alternative for viewing Request information within one window when adding a new Note.
	Allows the User to create or view reminders related to the RFC. When published it will be displayed like the normal alert icon.
	This option is visible next to the Item Type, if the RFC is in a Workflow State with the Item Editable option is set to Yes. Click the icon to edit the Item details.
	The escalation buttons allow the User to escalate the Request to the next layer within the Team, or de-escalate the Request to the lower level, if required.

Changing an RFC's Item or Customer

After an RFC is created, it may be necessary to change the assigned Customer or Item. This may be the case when the Unknown Item is associated with a RFC, or a Service Item has been assigned to the RFC and the relevant hardware, software or network Item needs to be associated with the request. When the "Allow Unknown" option is disabled in the Setup>Privileges>Requests tab and a Request that is assigned to the Unknown Item is opened in Edit mode, the User will be prompted to update the Item assigned to the RFC before the Save button action can successfully record changes to the RFC.

NOTE:This option is also required when a request is created through email, as the Item assigned may be the system's default Unknown Item or the Org Unit's default Item.

To change the Item:

Click the RFC's Edit button
Select the RFC's Customer tab
Click the Item Number

The Find Item option appears.
Search and select a new Item
Click Apply to update the RFC
Select the Summary tab to continue working on the RFC, or click Cancel and Done to close the RFC with the newly assigned Item.

To change the Customer:

Click the RFC's Edit button
Select the RFC's Customer tab
Click next to the Customer Name
Search and select a Customer
Click

If the RFC's Item needs to be altered as a result of the Customer change the Find Item field appears. Search and select the appropriate Item using the Find Item search.
Select the Summary tab, to continue working on the RFC
Click Save.

NOTE:Technicians do not have the ability to delete Change Requests or Customers.

Item Relationship Map and Assignment

Selecting opens a pop-up window that displays a map of Items that are related to the Request Item that can be navigated by clicking on the icons within the map. To view related Item information, scroll over the relevant Item icon.

Updating the Item associated with the Request

The Item associated with the Request can be updated when in the request is in Edit mode:

See: Item Relationships.

Select
Navigate the map to move the relevant Item icon to the central point of the map

Select the Item icon label in the Map to move it to the central node.
Click the icon label when it is in the middle of the map

A warning message is displayed, prompting the confirmation of the Item change.
Select OK and the Item association will be updated

(If the Enable Item Shadow option is enabled by the Administrator in the Setup>Privileges>Customer tab, the change of Item information will not be visible on the Customer Portal.)
Select to close the window.

The Item assignment change is recorded in the Audit tab.

Notes Tab

Notes

The RFC Notes tab displays entries made by a User regarding the Change Request. New Notes are date-stamped automatically and associated with the User logging the Note.

The number of Notes recorded against a Request is displayed in brackets on the Notes tab, and if a Note has been added by a Customer or a Technician other than the Technician assigned to the Request, an asterisk will also be visible on the Notes tab until the assigned Technician opens the Note.

Add Note Button

The Add Note button can be used to open the Change Request in Edit mode and automatically access a new Note window, as shown in Step 4 below.

Viewing All Notes

Use a Change Request's Print button to access a list of all Change Request Notes in one screen. To hide Private Notes in the Print output, remove the tick from the Show Private Notes box.

Adding a Note

When the first Note is created for a Change Request, the Request Description automatically populates the New Note editor allowing the Technician to enter their response.

To add a Note:

Click the RFC ID Number

The Change Information>Summary tab appears.
Click Edit
In the Notes tab, click New
Enter the Note details

Or, select a Template, if a relevant pre-configured response has been set for the Item Type or Category for the Item assigned to the Change Request.
Enter Note Time

The time entered represents the amount of time accumulated to formulate the Note's content or time spent working on a request away from the system. If no additional time has been spent on the Request away from the application this field will be automatically populated with the Logged Time when the Request is in Edit mode, if the Manual Request Time option is disabled in the Setup>Privileges>User tab. When this option is disabled, is visible next to the Change Request number in the top right corner of the Summary Tab screen when the Request is in Edit mode.
Adjust the time and date work was completed, if required
Add attachments to be sent with the Note, if required

A maximum of two attachments can be added per Note.
Adjust the Note visibility, if relevant

The default Private or Public visibility for Email Notes is set within Admin>Setup>Privileges>Requests, and can be adjusted on a per Note basis.
Refine the Email Recipient options as required

The default Request Notifications for Notes is set within the Team assigned to the Request, and can be adjusted on a per Note basis.

Vendors, as Email Recipients, is displayed as an option if the Change Request is in a State associated with an Underpinning Contract.
Click .

NOTE:A Technician can only add RFC Notes if they belong to the work group associated with the current RFC status.

Create Knowledge

When a new Note is created for a Request it can be added to the Knowledge Base by selecting the Create Knowledge option. By selecting this option and then manually moving the Request to a Closed State, the system automatically creates a Solution Knowledge Base Article with a visibility of Assigned Request. This visibility allows Customers of a shared Item assigned to the Request to also view the Solution. For the Solution to be available to other Customers of the same Item Type, the visibility must be adjusted to Technicians and Customers within the Analysis tab or the Knowledge Tab.

Solution

If a Note resolves the issue, the Note can be saved as the Solution. This will convert the Note into a Solution Article (found under Change Request>Analysis tab), by enabling the Create Knowledge option before selecting the Solution button. Clicking the Solution button will automatically move the Change Request to the default Closed State. If the Solution button is applied to a Change Request containing attachments, the attachment is included in the Solution email.

To save a Note as the Solution:

Enter the Note details
Select Create Knowledge, if the Note content is to be available in the Knowledge Base
Click Solution.

For Create Knowledge enabled Notes, the content will be recorded as the solution under the Analysis tab. The Status of the Change Request will change to default exit State of the assigned Workflow.

Draft Note

Use the Draft button to save an incomplete Note entry, which will be displayed in the Notes list. When a Note is saved as a draft, the Status will be displayed as . If the Add Note button is selected when a draft Note has been recorded against a request, a warning will be displayed. To continue working on a draft Note, open the request in Edit mode and select the Note No. hyperlink.

Changing the Status of a Note

When the Note is created, it can be either public or private. After the Note is saved, it is possible to switch visibility
If a Note is marked Private, a padlock graphic is visible. To change the status to Public, click to display
To change the Public Note to Private, click to display .

Viewing a Note

An asterisk is visible on the Notes tab when the Technician assigned to the Request is yet to view a Note added to the Request.

To view a Note:

Select an Incident ID Number
Select the Notes tab
Click on the Incident Note Number hyperlink.

When Notes are viewed without opening the Request in Edit mode by clicking the Note No. link, the User can scroll through the Notes list by selecting inside the top right corner of the Notes window.

Replying to a Note

To reply via email to a Customer Note:

Click the required Incident ID number.

The Change Information screen appears.
Select Edit
Select Notes tab
Click on the Note number

The Note appears.
Click Reply

The new Notes editor is opened and includes the Note that is being responded to.
Enter the Note content
Adjust the Visibility and Recipients settings, accordingly
Select Add Note to send the Note, or click Draft to finish the Note later.

Emailing Saved RFC Notes

To email a Customer after a Note has been saved:

Click the required RFC ID number

The Change Information screen appears.
Select Notes tab
Click on the Note number

The Note is displayed.
Click Email to send the Note to the Customer and any other Users added to the Notification list.

Adding Notes to Groups

When a Note is created for a Request that belongs to a Group, the Apply to Group option is visible within the Notes tab. If the new Note is to be assigned to all requests within the Group, select the Apply to Group option.

NOTE:Any new requests added to the Group at a later date will also have all pre-existing Notes, with this option selected, applied to the newly grouped request.

When the Apply to Group option is selected, the Add Note Time to Group option is displayed. Select this checkbox to also apply the Note Time to each of the requests.

Selecting the Apply to Group option and then clicking the Solution button, closes all requests within the Group.

Attachments Tab

Attachments

All Users can attach any type of file to an RFC.

Adding an Attachment

To add an Attachment:

Select an RFC number ID
Click Edit
Select the Attachment tab
Click
Browse and select a file
Mark Private, if the attachment is not to be available on the Customer Portal
Enter a file description, if necessary
Select to upload the file or to cancel the process.

The Attachment is automatically date stamped and shown as a File Name link with its file size.

To open an Attachment, select the file name hyperlink.

NOTE:Requests that are part of a Group and have attachments uploaded within the Group Details Screen display within the Share Column.

Deleting an Attachment

To delete an Attachment, select the checkbox beside the File Description then click Delete. The addition or removal of Attachments is recorded within the Audit Trail of the Change Request.

Impact Tab

Impact

The Impact tab provides the capability to measure the progress of an RFC relative to agreed Service Level targets and Workflow time estimates. It also includes a quick reference for identifying other Services or Items affected by the RFC. This tab displays a summary of the following:

Service targets
Workflow estimates
The impact of the current RFC on related infrastructure.

The drop-down filter options within the Impact tab include:

Options	Description
Service Targets	Displays the target response, restoration and resolution times based on the Service Level Agreement/OLA assigned to the RFC.
Service Level Breaches	Displays service level breaches that have occurred and allows Users to assign a breach code and explanation for the breach.
Services Affected	Displays the Service Item Number, the Service SLA and number of Affected Users for any Services related to the Item associated with the Request.
Estimates	Provides a summary of the time estimated for each state of the Workflow based on the OLA assigned to the RFC. This can also be manually completed inside the Request.
Planned Outages	Provides a list of all the Planned Outages for the Item assigned to the RFC.
Contract Monitor	If the current Change Workflow State is assigned an Underpinning Contract or OLA, a table is displayed outlining the response, restoration and resolution milestones. When a milestone is met, the User is required to check the relevant checkbox. The application will automatically calculate the actual time accrued to achieve the milestone. The value displayed here is used for the Contract reports.
Purchases	When Purchase Orders are enabled in the system, any Purchase Orders associated with Items assigned to the Request are accessible through this option.

Service Targets

The details displayed here are drawn from the Service Level assigned to the RFC. These include the target Response, Restoration and Resolution times for an RFC, based on the Priority assigned. If an Underpinning Contract or OLA has been assigned to the RFC's current State then the targets for that contract will also be listed.

Service Level Breaches

When an RFC Service Level Agreement is violated, a service level breach is recorded against the RFC. The User assigned to the request will be notified and asked to provide a reason for the breach, and assign a Breach Code.

To assign a Breach Code:

Click the RFC number
Click Edit
Select Impact > Service Level Breaches
Click Edit
Assign a Breach Code

(The available codes are created by the Supervisor within the Service tab)
Add any additional information, if required
Click Save.

All breach information is used for reporting on Service Level Agreements.

Services Affected

When the request is logged against an Item that is associated with Services within the Item Relationships tab, the Services Affected option displays the Service Item Number, the Service SLA and number of Affected Users.

Estimates

The Estimates option allows Users to view an indication of the approximate time a Change Request should remain in each State of the Change Workflow, the amount of time logged in each State and the length of time the RFC resided in each State.

Options	Description
Estimate	Indicates the approximate length of time the Request will spend in the Workflow State. This field is automatically completed if an OLA or UC is assigned to the Workflow State.
Logged	Is a combination of time accrued against the Request when in edit mode with the automatic timers enabled, and the sum total of Note Times manually entered by Users.
Total	The total time a Request has resided in the Workflow State.
% Active	The percentage of the Total time that the Request was actively worked on when in the State. The calculation is, (Logged time divided by Total time) x 100.

The Estimate Times are drawn from the OLA and Underpinning Contract assigned to the current State. However, these can also be adjusted manually for each RFC. To manually adjust the estimated time for a Workflow State:

Select a Request number ID
Click Edit
Move to the Impact tab, select Estimates from the drop-down list
Select the State hyperlink within the Status column of the Estimate Time to be adjusted

An editor box is displayed.
Enter the adjusted time in the available field
Click Save within the editor box
Make any other time adjustments, if required
Select Save to record all manually entered time adjustments against the Change Request.

Planned Outages

Planned Outages can be created and linked to the RFC. The Planned Outages are used as an indicator for the preferred time that a change to an Item should take place.

Creating an Implementation Outage:

Select an RFC number ID
Click Edit
Move to the Impact tab, select Planned Outages from the drop-down list

The Implementation editor appears.
Click New to create an Outage or Click Link to access the Planned Outage information recorded within the Item Details tab
Enter Outage information
Define Notification and Reminder Email requirements
Click Save.

The Outage is assigned to the RFC.

Contract Monitor

When a Workflow State with an OLA or Underpinning Contract is assigned to the Request, the Contract Monitor displays the details of the Contract.

The information is used for reporting purposes and includes:

Details	Description
Contract Type	Specifies if the Contract Type is an OLA or Underpinning Contract.
Start Time	Auto-generated time the request moved to the current Workflow State.
Milestones
Expected Response Time	Response Time calculated using the Contract target parameters.
Responded	Actual Response Time auto-calculated when the User checks the box.
Expected Restoration Time	Restoration Time calculated using the Contract target parameters.
Restored	Actual Restoration Time auto-calculated when the User checks the box.
Expected Resolution Time	Resolution Time calculated using the Contract target parameters.
Resolved	Actual Resolution Time auto-calculated when the User checks the box
Comments	Allows for additional comments, if required.

NOTE:If Milestones are breached the Response, Restoration and Resolution times are assigned a red marking.

Audit Tab

Audit

The Audit tab lists all activities that occur within the lifetime of an RFC, the resources used, and the history of the RFC's Item. It provides access to information relating to Approval activities logged against the RFC.

Audit Trail

The Audit Trail option records all activities related to an RFC. The recorded activity, which can be exported to PDF includes:

Date and time the RFC was assigned and/or reassigned to Users
When the RFC moved to a new state, or had its Priority or Due Date changed
Details of Notes added
Attachments activity
Classification change
Logged time

Resource Utilization

The Resource Utilization option displays a breakdown of the time an RFC was worked on at each level of support. It details the User's name, the escalation layer they belong to and the amount of time they spent on the RFC.

Item Audit Trail

The history of the Item associated with the RFC is detailed within Item Audit Trail. To access more information regarding an Item Audit Trail entry, select the ID number hyperlink.

Request Approvals

For RFCs that are assigned an Approval State, the details, including the time and date the RFC entered and exited the Approval State, are recorded within this tab. Select the Date hyperlink to view the Approval Action information. The complete list and details can be exported using the PDF option.

Service Terms

The Service Terms sidebar displays the Service Level Agreement (SLA) assigned to the RFC and provides details of key dates.

By default the application calculates the Due Date based on the Priority of the SLA assigned to the Customer, Organizational Unit or Item. The email reminders and escalations are then managed accordingly. If an SLA is not associated with the Request via the Customer, Org Unit or Item, the system default SLA will be automatically assigned to the Request but can be manually adjusted by the Technician. Once the Workflow is moved from the default Open State, the SLA can no longer be edited.

Service Terms
Agreement	Displays the Service Level Agreement assigned to the Request. The service level is derived from either the Customer, Organizational Unit or Item. When Contracts are not enabled, the Agreement field can be edited when the RFC is in edit mode.
Service Manager	Displays the User assigned as the Service Manager for the assigned SLA.
Progress	Visually displays how the Change Request is tracking against the assigned SLA. The grey progress bar is gradually filled in based on the status of the SLA: - Workflow is in an SLA paused State. Triggers will not fire. - Workflow is in an SLA timers on State. Triggers will fire. - Workflow is in an Exit State and the SLA has been successfully maintained. - Assigned SLA has been breached and Workflow is in an Exit State.
Open Date	The Open Date field is automatically populated when the Change Request is created.
Due Date	By default the application calculates the Due Date based on the SLA Target for the Priority assigned to the Request, and email reminders are sent accordingly.
FSC Date	The Forward Schedule Change date is automatically updated by the system when a Planned Outage is created within the Impact tab. The Planned Outage and RFCs change due dates are also visible within the Home>Calendar tab.
Fix Date	Auto-filled when the Request moves into a Workflow State that is defined as meeting the SLA Resolution Time.
Remaining	Auto-filled and visible when there is SLA time remaining.
Time Overdue	Auto-filled and visible when the SLA is overdue.
Close Date	Auto-filled when the Status of a Change Request is set to Closed. This date is fixed.
Resolution Time	Auto-filled with the number of minutes it took for the request to move from the first SLA active State to a Workflow State that is defined as meeting the SLA Resolution Time.
Last Action Date	Auto-filled when Done or Save is selected after the Change Request has been modified or opened in edit mode. As updates may be made to a Request after it has been Closed, this date may fall after the Close Date.
Time Recorded	Displays the sum total of automatically logged time, when the Change Request is in edit mode plus any manually entered Note Times.
Affects	Number of Customers assigned to the Item associated with the RFC.

NOTE:Each User can customize the date format within the My Account sub-menu option. To change the date format go to Home > My Account, click Edit and select the preferred format.

Time Recorded

Time Recorded uses a combination of auto-timing and manual Note Time entries to measure and monitor the time spent working on an RFC.

The Auto-timer is activated when a Change Request is opened in edit mode, if enabled by the Administrator in the Admin>Setup>Privileges>User>Manual Incident Time. When the Request is saved after any amendments have been made, the timer stops and records the length of time the Request has been worked on. This total is added to the sum total of any manual Note Time entries made by Technicians when they are adding Notes.

The Time Recorded is used by the system when the Contracts functionality is in use.

Related Requests

The Related Requests sidebar is automatically displayed when a Change Request is linked to other Requests.

RFCs can be linked in the following ways:

Using the Group option within the RFC list
Using the Change Group feature under the Change tab
Linking requests within the RFC's Analysis tab
A result of multi-Item Request creation.

Any Requests that belong to a Group can be viewed within the Related sidebar window, inside the Change Information screen. Within this window, all related Requests are listed and can be controlled as one. For example, Notes can be applied to all related Requests, or the entire Group can be closed.

Managing Related Requests

The details of a Related Request can be viewed by hovering the mouse over the colored Icon. Click on the same Icon and the system moves to the Change Information screen of that related Request.

Bulk Updates

The Bulk option allows one or more related Requests to have the following information updated simultaneously:

Priority, Workflow, Status, Team, Escalation Layer & Technician
Notification method and recipients
Request Classification
Items
Description, Attachments and Notes.

To bulk update for any of the above elements:

Select Change>Change Requests
Click on the Request # link of the relevant Grouped Request
Tick the checkboxes of the appropriate requests in the Related sidebar that are to be updated
Select

The system displays the Bulk Editor screen.

NOTE:The system does not allow Requests with a status of Pending-No Contract to be updated. If the Bulk update is only associated with Requests of this Status, an error message is displayed.
Amend the appropriate element as per the above list
Click Save.

Remove Related Requests

To remove a request from a Group:

Go to Change>Change Requests

Or, within Change>Change Groups select the Group # link and move to the Elements tab
Click on the Request # hyperlink of a Grouped Request
Click

The RFC opens in Edit mode and checkboxes become available next to the requests in the Related sidebar.
Tick the checkboxes of the requests to be removed
Select .

The marked requests are removed from the Group.

Closing Requests within Groups

Requests within the Related sidebar can be closed individually by moving the Workflow State to a Closed State within the Change Information Screen. Grouped Requests can also be closed as a group, by changing the Request Status to an Exit State as part of a Bulk update. (See Bulk Updates above.)

Status

Change Request Workflows are a combination of any number of stages or States that cover the lifecycle of a Change Request. A Supervisor creates new Change States for the default Change Workflows or builds new Workflows in the Service >Workflows tab.

Within the Change Request Information Summary page, the assigned stage of the Workflow is displayed within the Status field, with the Next Action field displaying the options of where the Request can move to. To view an assigned Workflow in its entirety select.

The system provides the following States for each Change Workflow:

Status	Description
SLA Timers On
Open	The RFC is open. Request timers are running and the automated SLA reminders, warnings and escalations will fire relative to the Triggers configured for the SLA.
Pending	Work on the RFC has not commenced. The Response-time SLA trigger will fire for RFC's with this Status.
SLA Timers Off
On Hold	The RFC has been put On Hold for some reason. SLA triggers will not fire for RFC's with this Status.
Closed (Verified)- CAB	RFC has been resolved and verified by the CAB.
Closed Resolved	The issue has been resolved and the RFC has been closed. SLA triggers will not fire for RFCs with this Status.
Cancelled	The RFC has been cancelled. SLA triggers will not fire for RFCs with this Status.
Cancelled- Unpaid*	The contract for a RFC has not been paid. The RFC is cancelled.
Pending- No Contract*	RFC has been created without a Contract. The Contract must be processed before work on the RFC can commence .
Pending- CAB	Work on the RFC has not commenced, and the RFC is pending approval from the CAB.
Rejected- CAB	The RFC has been rejected by the CAB.

*Denote System States that cannot be deleted.

NOTE:When an RFC is created, it is automatically assigned the Pending-CAB status. The CAB defines the Workflow the RFC follows, which in turn determines the Statuses available for the RFC.

Updating a Request's Workflow and Status

To manually change an RFC's Workflow or Status:

Select Change > Change Requests
Select a Request #
Click Edit
Within the Workflow list, modify the Workflow as required
From the Next Action drop-down list select the RFC's next Status.

The States listed in Next Action are based on the Change Workflow selected. To view the complete Workflow lifecycle click .
Click Save.

The system can automatically move an RFC to a Pending CAB Status through the following actions:

When Billing is enabled and payment is not received
When SLA parameters are violated.

Requests with a Pending-No Contract Status

Requests logged with the system that do not have a valid Contract are assigned the Pending - No Contract status. These requests are locked until a valid Contract is applied, and if relevant, paid.

Viewing a Status Note

When Requests move into a State with a Status Note, is displayed beside the Status field within the Summary tab of the Request. Scroll over to view the contents of the Status Note. If the Status Note includes an attachment, click the displayed link in the pop-up window to download it.

Request Reminders

When Change Requests move into a Customer, Line Manager or Team Manager Approval State, Technicians who are part of the Change Team have access to the Send a Reminder option within the Summary tab. Clicking sends a reminder email to the Manager or Customer, depending on the type of approval required, and records the action in the Request's Audit tab. (The message is customized by the Administrator in the Setup>Email>Templates, Approve Service Request link.)

SLA Triggers and Request Status

SLA Triggers fire for Requests that are in a Workflow State that has the Service Timer Active option set to Yes. The default Timer Active set for systems States can be changed if relevant for the organization. For example, it may not be appropriate for an organization to have SLA Triggers fire when a Request is moved to the system default "On Hold" State.

The following icons displayed in the Service Terms box, visually indicate how the Request is tracking against the SLA and if the SLA timers are active:

Current SLA Status
	Workflow is in an SLA paused State. Triggers will not fire.
	Workflow is in an SLA timers on State. Triggers will fire.
	Workflow is in an Exit State and the SLA has been successfully met.
	Assigned SLA has been breached and Workflow is in an Exit State.

Supervisor Users can verify the Timer Active status of a Workflow by scrolling over the Status in the Workflow map available in the Summary Information screen, or within the Service>Workflows>selected Workflow> Lifecycle>selected Status screen.

Priority

The Priority determines the timeframe in which a Request should be handled and sets the service level targets adopted by the Request that drive the SLA triggers and actions. It represents the degree of importance of the service request to the Customer and also indicates the urgency of the Change Request to the Technician.

A Request for change can have one of four possible Priorities:

Urgent
High
Medium
Low.

Setting RFC Priority

The Administrator configures the options for determining the Priority within the Setup>Privileges>Request tab. The Priority options include:

Selected Priority - where the system configured default Priority is applied to the Request but can be manually adjusted by the User.
Derived Priority - where the Impact is derived from the Item Criticality and the User enters the Urgency, enabling the system to calculate the Priority.

Urgency: The value selected reflects how quickly a resolution is required.

Impact: The value selected indicates the impact the Request has on the User and Organization. The higher the Impact the higher the Priority to resolve the Request.

If the Administrator has set the Request Priority option to Derived, the Priority of a Request results from the Impact being mapped from the Criticality of the Item and then combined with the selected 'Urgency'. However, if required, the Impact can be manually adjusted within the Request Information screen to affect the Priority.

The following table displays the calculations applied by the system using the Item Criticality mapped directly to the RFC Impact, to determine a Request's Priority:

The above calculations result in the following Priorities:

RFC Assignment and Escalation

When a Change Request (RFC) is logged within the system, it is allocated to the Team that is associated with the SLA and Workflows used by the RFC or to the default Team assigned to a Workflow State. The RFC Status is automatically set to the default Entry State of the Workflow.

The appropriate Change Request Workflow is assigned within the Change Request Summary tab, by selecting an option from the Workflows drop-down list. This list is derived from the SLA assigned to the Customer, Organizational Unit and Item. Once the Workflow is selected, the associated Teams are available for assignment. Based on the Team assigned, a Technician in the Group associated with the first State of the selected Workflow is allocated to work on the RFC. This can be adjusted manually, if required. As the RFC moves through the Workflow, it is allocated to an Assigned Technician within the Group associated with the assigned State.

Note, that if the Technician assigned to the RFC is also included in the Group associated with the next Workflow State, the system will by default reassign the RFC to the same Technician when it moves to that next State.

It should also be noted that for each Change Request Team, there is an over-arching layer of escalation above the Technicians assigned to each Workflow State. This means that throughout the Workflow Lifecycle, in addition to changing the Technician by moving Workflow States, the RFC can be escalated to a higher level of support if required.

The Request is automatically escalated according to the SLA assigned to the RFC and the triggers configured within the Priority of the SLA. An RFC is escalated if the assigned User exceeds the Escalation trigger point defined for the Response, Restoration or Resolution time of the assigned SLA, when the assigned Workflow State is an SLA Active State. Or, it can be manually escalated by a User, if required.

RFC Assignment

When an RFC is assigned to a User, the system follows a series of steps to look for the most appropriate Technician for the job, based on skill set, location and workload. The order of business logic is as follows:

The system will identify the Team associated with the Service Request's SLA and associated Workflows
The system will find Technicians/Supervisors assigned to the Team
If Users are assigned to an Organizational Unit, the system will identify the Users that belong to the same Organizational Unit as associated with the Request by the Customer assignment
If Classifications/Skills are assigned to Users, the system will find Technicians/Supervisors assigned to the Request's selected Classification
Based on the Team configuration, if the Live Priority option is enabled for the Team, the system will look for a User who is logged into the system
The system verifies Work Hours/Availability of Users within the Team for appropriate Request assignment
The system will assign the Request to the User who has the lowest workload, i.e., the fewest number of Open or Pending Requests
If there is a tie, the system randomly allocates the Request to a User in the tie.

If a more appropriate Team member is available, the User assigned to the RFC can re-assign it manually by selecting a Technician from the drop-down Technician list in the Change Information screen.

Note, if the Self Assign option is enabled for the Team, the system assignment logic is ignored and the User creating the request is automatically assigned the RFC.

Automated Escalation

An RFC's Service Level Agreement includes trigger points that set the rate at which automated escalations will occur for an RFC. Auto-escalation is triggered when the number of support hours specified for either an RFC's Service Level Response, Restoration or Resolution time is exceeded and the SLA Trigger action is set to Escalate. When it is escalated, the RFC is assigned to a Technician or Supervisor in the over-arching escalation layer for the assigned Change Team.

Manual Escalation

The Escalate button next to the Technician name in the Change Request Information Summary Screen, escalates the RFC to an over-arching escalation layer for the Change Team. Any Technician assigned within the escalation layer can be assigned to the RFC.

Escalation Control

If the Escalation Control functionality is enabled in Admin>Setup>Privileges>Requests, there is the option to enable or disable escalation within the Change Request Information Summary screen.

NOTE:This option is only visible to Supervisor Users. Once an RFC is created, a Supervisor can elect to switch the Escalation option to Off. This means all SLA timers stop, which prevents escalation. Switching the option back to On will re-start the timer and reactivate the SLA triggers.

Notification

The Notify option sets the method of messaging used by the application to notify Customers and Technicians of the following changes to an RFC:

RFC is created
RFC is closed
RFC is deleted
RFC Note is added
RFC is escalated (Technician only).

The default notification status of Requests is set on a per Team basis within the Users>Teams>Team Information screen, with the default recipients of new Notes being configured by the Administrator in the Setup>Email>Setup tab. However, this can be adjusted on a per Request basis within the Notification Method field and on a per Note basis, when new Notes are created.

The methods of Notification can be set for Customers and Technicians, and include:

None, which ensures that no messages are sent
Email, which means an email is sent containing the Change Request detail updates
SMS notifications, which sends an SMS message to Technicians and Customers about the RFC update. This is only available to Users and Customers who have a mobile number and a service provider entered in their User and Customer Information screen.

Notifications can be sent to:

Customer- the Customer who logged the RFC
All Owners - all Customers who share the Item assigned to the RFC
Customer CC's - email addresses to receive Customer email correspondence when the CC field is selected in the New Notes screen

This field is automatically populated by the system with email addresses included in the CC list of the original email used to create the Request. Multiple addresses should be separated by a comma.
Team - notifications can be sent to all members within the Team assigned to the RFC, or restricted to members within the layer of escalation to which the Request is assigned
Technician CC's - enter any User account email addresses that are to be sent Request Notifications. Multiple addresses should be separated by a comma
Alternate Team - this option is visible if the Notify Alternate Team option is enabled in the Admin>Email>Setup tab. Notifications can be sent to a Team within the related Process, by the User selecting an option within the drop-down list.

The following is a sample email sent by the system to the Customer and assigned Technician, confirming the creation of a request. The message sent can be customized by the system Administrator:

Email Sample

Workflow

When a Change Request is created it is assigned a Workflow that governs the life-cycle of the Change Request. The SLA allocated to the RFC determines the Workflow options made available for the Change Request. Before saving the RFC, the User can adjust the system assigned Workflow, if more than one Workflow option is available.

After the Workflow is assigned to the Change Request, all stages of the assigned Workflow can be viewed by selecting . The Workflow map displays the entry points (blue boxes), transitional States (orange boxes) and exit points (red boxes).

The User moves the Request through the Workflow Lifecycle by adjusting the options displayed in the Next Action field.

Moving through the Workflow

To move a Change Request through the stages of the Workflow, in the Summary tab of the Change Request Information screen:

Click Edit

The Next Action field with a drop down list of Status options is displayed below the Status field.
Click on the Next Action field

The Status options are displayed. This list is based on the configuration of the assigned Workflow.
Select a State
Click Save.

The selected Status is assigned to the Change Request with the updated logic applied (i.e., The SLA Timers may now be active or inactive based on the newly assigned State configuration or an alternative Work or Manager Group may have been assigned to the Request.

Approval State

Approval States in Change Request Workflows provide the facility to approve or reject Request activity to Manager Groups that have been assigned to the Approval State. When a Request moves into an Approval State, the Edit button is only visible to Manager Users within the Manager Group that is assigned to that stage of the Workflow. Users who are not Managers within the Team, can send Managers a reminder to action the Request, by selecting .

Managers who are assigned a Request for approval can (approve) or (reject) the Request, which automatically moves the Request to the next pre-configured stage of the Workflow. Requests assigned a Customer or Line Manager Approval State can be processed via the Customer Portal or email.

Assigning a State with an Underpinning Contract

Each state of a Workflow can be customized for either internal support contract management that is monitored by an OLA, or out-sourced to an external support provider, which is monitored by an Underpinning Contract.

When a Request moves into a State that is governed by an Underpinning Contract, for internal contract control the Request can be assigned to the Service Level Manager, if configured in the Workflow. This allows the Manager to maintain control of the RFC, and to easily follow up with the external service provider, if required. The assigned SLM will be able to adjust the current Status, add Notes and udpate the Contract Monitor information in the Impact tab.

Alternatively, the Workflow State can be configured for the Technician assigned at the time the Request is moved to the Underpinning Contract State to maintain Request editing privileges and manage adherence to the assigned service agreement. If the Workflow is configured for the responsibility of the Request to be maintained by the Technician when the Request is in an external contract state the Technician will be able to adjust the current Status, add Notes and, if the Technician is assigned the Internal Process of Service Level Management amend the Contract Monitor information in the Impact tab.

OLA Status Due

Within the Summary screen, the Status Due field is visible when a Workflow status is monitored by an OLA. The time, date and percentage remaining information displayed is calculated using the OLA's Target Resolution time.

Team Assignment during the Workflow Lifecycle

To ensure that all Change Requests are managed throughout the Workflow, the Team assigned to the RFC when it is first logged within the system is set as the default Team. If a Request moves to a State that has an OLA assigned with a Team, the RFC is re-assigned to that OLA's Team. When the RFC moves out of the OLA State to a State where no OLA or Team is assigned, the RFC is re-assigned to the default Team.

Pending - No Contract Status

When the Contracts or Invoices functionality is enabled and a request is created, the system will verify the service entitlement status of the Customer and if a valid contract is not in place, the new RFC is assigned a Status of Pending-No Contract and locked until a valid contract is associated with the RFC.

In a Request Group where the Customer and Organizational Unit does not have a Contract, if an Item applied to an RFC has a Contract and another does not, a relevant Status will be applied to each request. The User will be able to edit the RFC with a valid Contract, but the RFC without a Contract will be locked down to a Pending - No Contract Status, until a valid Contract is applied to the RFC.

The Customer is automatically sent the NoContractCreateRequestSummary email when the Request is saved with the Status. A reminder email can be sent by the Technician from within the Summary tab by clicking , when the RFC maintains this Workflow Status assignment.

The RFC report entered during the request creation is recorded within the Description tab. Amendments can be made to the RFC report if required, but it should be noted that an Audit Trail is not maintained for alterations made within this screen. Therefore, it is recommended that any RFC report amendments be entered as an RFC Note.

The details recorded in the Subject field are displayed in scroll-over summaries throughout the application. For example, when a new Change Request is being entered for a Customer, a Recent Customer Requests list is displayed during the Change Request creation process for all Items the Customer owns either directly or via shared ownership. The Requests list includes a scroll-over summary where Subject content is displayed, if the Subject is completed for a Change Request. Subject information can also be included within a column in the Changes List View, for a quick glance summary of a Change Request.

NOTE:The Administrator can set the Subject field to be required for Technicians and Customers within the Setup>Privileges>User and Setup>Privileges>Customer tabs, respectively.

2.5.2 Change Groups

Change Requests that are related can be linked to form Groups. Once the Group has been created, RFCs can be managed as one.

For example, RFCs can be grouped if:

They are all logged by Users of one department
They are all logged by one Customer
They are all logged for the same Configuration Item
They have a common Description or Solution.

NOTE:New Groups must consist of RFCs that are not already linked, unless the merge facility is used to combine existing Groups..

Users can group Requests manually through the Change Groups tab or Change Request List. Change Requests that have multiple Items assigned to them during the Request creation process, are also listed within the Change Groups tab. The Change Groups list can be exported using the PDF, Excel and Project buttons.

Creating a New Group via the Change Groups Tab

To create a new Group via the Change Groups Tab:

Select Change >Change Groups Tab
At the Change Groups screen, click New
Enter a Name for the Group
Assign an Item Type, if applicable
Assign a Classification, if an Item Type is selected
Assign a Group Priority
From the drop-down list, select a Status (i.e., Open, Closed or Resolved)
Enter a Group Description

The screen will default to the Analysis Tab, which allows the User to group existing RFCs.
Check the field next to the relevant Request # to add the RFC to the Group
Select Add
Click Done to record the new Change Group.

Creating a Change Group using a Group Template

To create a new group using a Group Template:

Select Change>Change Groups
Click New
Select the Use Template checkbox

A list of Group Templates will be displayed.
Select an appropriate Template

The Group details are listed.
Enter a Name, as unique identifier for this Group

The selected requests for the Group are displayed. These requests are the Quick Calls assigned to the Group Template.
Click Next

The Find Customer field is displayed.
Search and select the Customer to be associated with the tasks included in the template

If the Customer details are not in the database and are to be created as part of the tasks included in the template, assign a default customer and update the details in the Customer tab of the Request, when the Customer details exist in the system.
Review the Selected Requests displayed for the Group

These Requests are the Quick Calls assigned to the Group Template. To exclude any of the Requests from the newly created Group, untick the checkbox next to the Template name.
Define the Creation option:
- On Save for all the requests to be created when the Request Group is saved
- In Sequence for the first request to be created when the Request Group is saved.
Click Save.

The Group is created including all requests.

The type of group created, whether it be an Incident, Problem or Change, will depend on the Quick Call Tasks assigned to the Group Template. For example:

If there are Incident Quick Calls, the Group will become an Incident Group
If there is at least one Problem Quick Call, the group will become a Problem Group
If there is at least one Change Quick Call, the Group will become a Change Group.

Billing/Contracts

Item RFC

To monitor all changes made to the CMDB each time an Item is created, modified or deleted an RFC can be generated. To ensure an RFC is created each time an Item is updated, the Control CMS via RFC option must be enabled by the Administrator within Setup>Privileges>Requests tab.

When this option is enabled, when one of the following actions occur an RFC is generated:

Create an Item
Update the Item Type
Update an Item Status
Update an Item's Team
Update fields within the Details tab
Adjust Item costs
Delete an Item.

The steps outlined below assume that the Control CMS via RFC option is enabled.

NOTE:Only Users assigned to the assigned RFC Workflow State can edit the RFC.

Creating an RFC for an Item

When an Item is created or modified an RFC is generated. To create an RFC for an Item change:

Select Configuration > Items
Click New to create an Item
Enter the Item details
Click Save

The system will inform the User that an RFC has been generated.

NOTE:The Item will not be visible within the Items List View until the RFC has been approved and applied
To access the new RFC go to Change>Change Requests.

Working with the RFC to update the CMDB

The RFC that is automatically generated during the Item creation process, when the Control CMS via RFC option is enabled, includes the details of the Item creation or update in the RFC Description field. When the Change Request moves into a State that is defined as Item Editable, it allows the newly created or updated Item information to be applied to the CMDB. The Item Editable option is configured by a Supervisor in the relevant Workflow>Lifecycle>Status tab.

When the RFC moves into an Item Editable State, the Edit and Apply Item options are visible next to Item Type link.

The option allows the Item update details that prompted the creation of the RFC to be applied to the CMDB. Scroll over to view the Item details and refer to the RFC Description field for information regarding the Item change. The option allows the Item details to be edited within the RFC before applying to the CMDB. When is selected the Item Information screen is displayed in Edit mode, the details can be updated and when the Save button is selected, the changes are committed to the CMDB.

To update the CMDB by applying the newly created or edited Item details that prompted the creation of an RFC:

Go to Changes>Change Requests
Select the Change ID# of the RFC for the Item change
Click Edit

Refer to the RFC Description field for information about the Item that prompted the creation of the RFC.
Move the RFC to a State defined as Item Editable

is displayed next to the Item Type link, scroll over to view the details to be applied to the CMDB.
Click to apply the Item information to the CMDB

Or, if the Item Details are to be edited, select , amend the information in the Item Information screen and click Save.

The Item Editor screen appears and the system prompts the User that the details described in the RFC have been applied and need to be approved.
Click Save to apply changes

The Item is updated.
Save the RFC.

Move the RFC through the Workflow States to the Exit State, as configured.

NOTE:An Item's Audit Trail always records any RFCs created assigned with Item.

Creating an Item within an RFC

NOTE:The option to create an Item within an RFC is only available to RFC's created using a Group Template.

An RFC within a Group Template can be used to create a new Item. For example, a Group Template can include a Quick Call task to purchase a new piece of hardware. When the Group Template is applied, the RFC is created and assigned the Unknown Item. When the RFC moves into an Item Editable Workflow State, a New button appears next to the Unknown Item, which allows the User to define the new Item details.

To create a new Item within the RFC:

Go to Changes>Change Requests
Select the relevant Change ID# of the RFC to define the Item
Click Edit

To define the Item, the RFC must be in an Item Editable Workflow State to access the New button.
Click the , next to the Item Type 'Unknown'

The Item creation screen appears.
Define the Item details

Search and select the Item Type, click Next and enter any known information within the Item Details fields.
Click Save when completed

The new Item is assigned to the RFC and created within the CMDB.
Click Apply to add the new Item details to the associated RFC
Select the Summary tab to return to the RFC Information screen

Continue to work on the RFC as required.
Click Save and Done.

The new Item and RFC updates are committed to the database.

Analysis Tab

RFCs can be linked to a Group in the Analysis screen of a Change Group. To search for Requests to add to the Group, use the system Filters or the Search option.

The system filter includes the following:

Unassigned Requests	Description
Project Requests	Requests that have been assigned to the Change Group/Project.
Unassigned Requests	All Requests that exist in the system and have not been assigned to the Group.
Potential Requests - Item Type & Classification	Requests in the system that match the Item Type and/or Classification of the Group.
Potential Requests- Keyword match	Requests with keywords that match between the Request description and the Group description. NOTE:The match is only performed on the first 250 characters of the description.
All Change Requests (sys)	Lists all Requests in the system irrespective of Workflow State or User assignment. Note that this option is not visible to Technicians when the privilege to View All Requests is disabled by the Administrator.
My Change Requests (Active) (sys)	Displays all Requests in an active Workflow State that are assigned to the logged-in User.
My Change Requests (All) (sys)	Displays all Requests, in active and inactive Workflow States, that are assigned to the logged-in User.
My Teams Change Requests (Active) (sys)	Displays the all the RFCs in an active Workflow State allocated to the Teams with which the User is associated.
My Teams Change Requests (All) (sys)	Displays the all RFCs, in active and inactive Workflow States, allocated to the Teams with which the User is associated.
Pending Approvals (sys)	If the User has Manager privileges, this view provides them with a list of Requests that are assigned an Approval stage of the Workflow.

To link Requests within the Change Group Analysis tab:

Go to Change>Change Groups
Select the Change Group # link
Move to the Analysis tab
Choose the Filter option
Select the relevant RFC checkbox on the left
Click Add
Click Done to return to the Groups list.

Elements Tab

The Elements tab displays all the Requests that belong to the Change Group. From this screen, any Request can be removed.

To remove a Request:

Go to Change > Change Groups
Select the Change Group # link
Move to the Elements tab
Select the checkbox of the relevant RFC
Click the Remove button.

Merging Change Groups

Existing Change Groups can be merged within the Change Groups tab, to allow all related RFCs within the Groups to be managed as one.

To combine Change Groups:

Go to Change>Change Groups
Check the fields next to the relevant Group #'s
Click Merge

The screen defaults to the Details tab for the Merge Group.
Set the Name, Item Type, Classification, Status, Priority and Description that best defines all associated Requests
Click Save.

The History tab records details of the Groups merged to form the new Group. Click the No. hyperlink to view the details. The Impact Tab records the Type and Number of requests associated with the Group.

Closing a Change Group

To close a Change Group and all related requests:

Go to Change>Change Groups
Select the Change Group # link
Move to the Elements tab
Select a Request # hyperlink

The Summary tab of the Request is displayed.
Click Edit
Within the Related sidebar check all related Change Requests
Select the Bulk option

The Bulk Editor screen is displayed.
Select the relevant Exit State
Click Save
Click Save and Done.

The Details tab of the Group now displays a Status of Closed - Resolved.

NOTE:When an RFC is duplicated, the new RFC is linked to the original RFC creating a Change Group. RFCs can be unlinked through the Group's Related tab.

Multi Item RFCs

2.5.3 Grouping Change Requests

RFCs can be linked to form project Groups when Requests are related in some way (e.g., Requests that require the same action). New Groups must consist of Requests that are not already linked.

Creating a New Group via the Change Request Tab

From the Change Requests list under the Changes tab, tick the check boxes in the far left-hand column corresponding to unlinked Requests
Click Link to group the RFCs.

A Group Number will be assigned and an instant Group hyperlink will appear under the Group column, if included in the List View.

Adding RFCs to an Existing Group

To add RFCs to an existing group:

Within the Change Requests list, check the boxes of the new RFCs and at least one member of the Group to which you wish to add the RFC
Click Link.

NOTE:This will not work if RFCs representing more than one group are included. For instance, if you have two Groups (A and B) each with two RFCs (A1, A2, B1and B2), and you want to add two unlinked RFCs to Group A, click the check boxes for the unlinked RFCs and either A1 or A2 or both. If B1or B2 is also clicked, the linking process will fail because it will not know which group to add the two new RFCs to.

Merging Request Groups

Existing Change Groups can be merged within the Change Groups tab, to allow all related Requests within the Groups to be managed as one. To combine Change Groups:

Go to Change>Change Groups
Check the fields next to the relevant Group #'s
Click Merge

The screen defaults to the Details tab for the Merge Group.
Set the Name, Item Type, Classification, Status, Priority and Description that best defines all associated Change Requests
Click Save.

The History tab records details of the Groups merged to form the new Group. Click the No. hyperlink to view the details. The Impact tab records the Type and Number of requests associated with the Group.

2.5.4 Grouping Requests

Multi-Item RFCs

Also displayed within the Change Groups List View are any Groups that are created as Multi-Item Requests. These Requests allow for multiple Items to be assigned during the Change Request creation process and result in separate Requests being created for each Item assigned to the initial RFC, which are then displayed within the Related Requests window of the Change Request Information screen.

The Requests are managed as individual Requests to cater for any special requirements relative to each Item. For example, consider a situation where a Team deploys an update in an organization. In this instance, during the RFC creation process multiple Items are assigned to a single Change Request, which the system automatically allocates to separate RFCs that are then managed on an individual basis. This allows appropriate Teams/ Technicians to be assigned to the RFCs relative to their skill-set or departmental assignments. The implementation process more effectively differentiates between the tasks and Items being modified and ensures each Item has its own Audit Trail, Attachments and Notes for future reference.

Multi-Item Requests are also listed as separate Change Requests within the Change Requests List View.

Multi-Item Requests are created like a single Item Request, but have more than one Item assigned during the Change Request creation process.

Multi-Item Request Item Assignment

After assigning a customer to a Request move to the Find Item field to assign Items to the Request:

Click the relevant Item link if listed below the Find Item search box

Or, Search for an Item or click to Create an Item.

The option to create an Item is only available to Technicians if the system Administrator has enabled the Create Items option within the Setup>Privileges>User screen.
Click Next to move to the Details tab if only one Item is to be assigned to the Request

Or, select Add to assign additional Items. If Add is selected, a Request Selections window will be displayed that lists all the current Items assigned to the Request.
Continue to add all the relevant Items to the Request and then select Next to move to the Details tab

Within the Details tab the Request is profiled by assigning a Classification and Description.
Select the Classification, enter the Subject and Description
Click Done to enter all Requests simultaneously.

The Requests are created individually and automatically applied to a Group.

2.5.5 Related Requests

RFCs that are included in a Change Group list the associated RFCs within the Related tab of the Change Summary tab. .

Grouping Requests

Requests can be grouped by selecting the checkboxes next to the Task list, followed by the Link button.

NOTE:The type of Request Group created is based on the Request type assigned to the Group.

If the Group contains Service Requests/Incidents, it is an Incident Group
If the Group contains Incidents/Problem, it is a grouped as a Problem
If the Group contains Service Requests/Change, it is a Change Group
If the Group contains Service Requests/Incidents/Problem/Change, it is a Change Group
If the Group contains Problem/Change, it is a Change Group.

2.5.6 Releases

Release and Deployment Management

The purpose of Release and Deployment Management is to maintain the integrity of an organization's production environment when deploying releases. Effective Release and Deployment processes allow your service organization to deliver change faster and with minimal risk to the business. It provides consistency in implementation approach and assures customers that they can use a new or changed service in line with business requirements.

Part of the Service Transition phase of the Service Lifecycle, Release is responsible for planning, scheduling and controlling changes and updates from Test to Live environments. It ensures the integrity of the Live Environment is protected and that the correct components are released. While Deployment includes the activities or tasks responsible for moving new or changed hardware, software, documentation and process to the Live Environment.

This process is overseen by the Release Manager, whose role is paramount to the success of a release and a required member of a Release Team. The Release Manager directs the process using all information presented to help assess release readiness, and to efficiently identify deployment targets for the deployment phases of a release. This level of control guarantees the Release Manager can deliver updates to the live environment successfully, to all relevant parties, on time.

The capability to leverage relationship maps defined within the embedded CMDB allows the Release Manager to assess the impact of a release, as all related Items can be easily associated with a release package. The extensive use of CIs to represent all aspects of a release and the capability to directly associate any category of CI with the release itself provides a complete picture of how a release will impact the organization before any tasks are undertaken. The Release Manager can identify CI Types impacted by the deployment and CMDB information details users, organizational units and specific infrastructure affected by a release.

Complex and generally a lengthy process, large scale deployments require project management to ensure success. To this end, Release Management includes related activities that require scheduling in and around the internal activities of the service desk. The Release Manager can readily achieve this by exporting release package information to Microsoft Project and administering the full process using a dedicated project management tool.

Exported project files contain all related Change Requests for a Release, providing all relevant parties with an end-to-end schedule of change. The export can also be filtered to include deployment activities that can be merged into the final schedule once the Implementation of all Changes is completed, resulting in a full historical account of the release cycle.

Within the system, the Release Manager creates and manages the Release within the Change>Release tab. Within the Deploy tab of a Release, the Deployment Tasks are generated and made available as groups within the Change>Deployment tab, while the individual activities are available within the Change>Deployment Tasks tab.

To review examples of Release and Deployments, refer to Release Management Applied.

Releases

Users who are assigned the Change Process of Release are provided access to the Releases, Deployments and Deployment Tasks sub-menu options within Change. These Users can oversee the Release process and also action Deployment Tasks, as required.

Within the Release tab, Users can create Releases, with the associated Deployments and Deployment Tasks. The Releases can also be exported using the Project button, to allow the User to manage the Release in a project management tool.

The Releases tab defaults to show active Releases logged in the system. This view can be filtered to show:

Filter	Description
My Releases (Active)	Displays all Releases in an active Workflow State that are assigned to the logged-in User.
My Releases (All)	Displays all Releases, in active and inactive Workflow States, that are assigned to the logged-in User.
Releases (Active)	Displays all Releases logged in the system that are in an active Workflow State.
Releases (All)	Displays all the Releases logged in the system regardless of their Status or Assignment.

The list can be re-sorted by clicking on a column header and the number of Releases displayed per batch can be altered using the Display pop-up option.

Getting started with Release Management

Before creating Releases, the Workflow and Team need to be configured. Also, Release Managers need to decide if Deployments are to be controlled by Change Management. Doing so means that when the Release moves into a Deployment State of the Release Workflow, RFCs are automatically generated and must follow the Change Workflow to the assigned Deployment State, before the Deployment Tasks can be acted upon. To manage Deployments with Change Management, the Administrator must enable Control Deployments via RFC in Admin>Setup>Privileges>Requests.

Creating a Release

Releases within the system include the following five areas of information:

Details: Provide a Release overview describing the Release, its Priority, assigned Workflow and Workflow State, and Release Manager
Types: Details the Item Types that are to be affected by the Release and if the Release involves installing new, updating or replacing Items
Analysis: Allows the User to associate existing Change Requests to the Release
Related: Lists the Change Requests assigned to the Release
Deploy: Defines where the Release is to be pushed out to, this covers specific Customers, Organizational Units and Global Releases.

Details Tab

The Release Manager defines all elements related to the Release within the Details Tab.

After entering the initial information about the Release, the Manager also uses the Details Tab to move the Release through the Workflow States. Each stage of the Workflow can be assigned to different Managers, so by moving the Release through the Workflow States, the User is also potentially reassigning control of the Release.

Also, within the Workflow, States may be defined as Approval or Deployment States. When the Workflow moves into an Approval State, the accept and reject options are visible. The Manager selects the appropriate option and the system automatically moves the Release to the pre-configured State of the Workflow relative to the option selected.

If the Workflow is configured as a Deployment State, when the Release is moved into this State, the Deployment Tasks created within the Release can be actioned by the assigned Technicians. However, if the "Control Deployment via RFC" is enabled, when the Release moves into a Deployment State, RFCs are automatically created for the Deployment, and when the RFCs hit the Deploy State configured within the Details tab of the Release, the Deployment Tasks become active and allow Technicians to action the Tasks. The Change Manager can view all Deployment Tasks related to the RFC within the RFC Summary screen and when all Tasks are moved to Closed-Resolved the Change Manager can close the related RFC.

When all Deployment Tasks are completed, the Deployment is automatically closed by the system and the Release Manager can close the Release within the Details Tab, by moving the Release Workflow to the Exit State.

To create a Release:

Go to Change>Releases
Click New

Complete the following information:

Release Fields	Description
Name	Enter a Name that reflects the objective of the Release.
Priority	Set the Priority, which will correspond to the target timeframes for the SLAs associated with the Release via the RFCs.
Team	Select the Release Team who will oversee all part of the Release.
Workflow	Set the Workflow that includes the relevant stages to manage the Release. The Release Manager moves the Release through the stages of the Workflow, relevant to the events being undertaken and completed.
Status	This is set to the Default Entry State of the selected Workflow.
Next Action	Based on the assigned Workflow, select the next Workflow State for the Release, as required by the next Release activity. Some States are Approval States, when the Release moves to an Approval State the Approve and Reject options are visible. The Release Manager selects the appropriate option and the system automatically moves the Release to the pre-configured next State, relative to the option applied.
Manager	From the drop-down list of Managers assigned to the default Entry Point of the assigned Release Workflow, select the Release Manager to manage the project when it is initially created. The User defined here, is the Manager who can edit the Release after it is saved and then move it to the next State.
RFC Control	If the Control Deployments via RFC option is enabled in Admin>Setp>Privileges>Requests, this field will be displayed. Select Yes if the Deployment is to be routed through Change Management, to enable the scheduling of Deployment Tasks. Select the RFC Workflow to manage the Change Request associated with the Deployment, and set the default Open State or Deployment State for the Tasks (i.e., when the RFC moves into this stage of the Change Workflow the associated Deployment Tasks move Pending to Open allowing the Technician to work on the Task.)
Description	Enter information that describes the goal of the Release.

Click Save.

Move to the Types tab to associate the Item Types with the Release, for Items being upgraded, replaced and installed from new.

Attachments

The Attachments tab allows the Manager to upload any relevant files, but also provides access to any Media Files that are associated with Deployments during the Release and Deployment creation process.

To add Attachments to a Release, within the Release's Details tab:

Click Edit to display the Attachment tab New button
Click New
Browse and select a file
Enter a Description, if required
Click.

To delete an attachment, tick the field next to the File Description name link and select the Delete button.

Impact

The Deployment Tasks filter view of the Impact Tab displays the number of Deployment Tasks per Status associated with the Release. While the Change Requests view shows all RFCs, and their current Workflow State, associated with the Release using the Analysis Tab and also listed in the Related tab.

History

The History tab records all changes and updates for the Release, relative to the assigned Workflow State. To view a historical entry within the Release Details tab:

Select the History tab
Click on the identification number hyperlink to display the entry details
Click Cancel.

The expanded window is closed.

Item Types Tab

Within the Types Tab the Release Manager can define one or multiple Item Types for the Items that will be affected by the Release and why the Types will be affected. The reasons the Types are affected include creating new Items, updating existing Items in the CMDB, or replacing existing Items with other newly created Items.

If the Release involves creating a new Item, it is assumed the Item Type does not exist in the CMDB, therefore setting the Reason to New allows the User to create a new Item Type and set the default service Teams, SLAs and criticality level of the Item Type. If the Release is to update an existing Item, the User only needs to search for an existing Item Type in the CMDB and assign it within the Release Types tab. Releases that cover an Item replacement require the User to associate the existing Item Type with the Release and create a new Item Type. A Release can include a mix of reasons, if relevant.

As part of defining all Releases, media attachments required for the process, such as an installer or executable file, can be associated with the Release in the Types tab.

New Items can be created from existing Item Types by using the Find Item Type field in the Item Types tab, but to define new Item Types for Items that are to be created as part of the Release, with the Item Types tab in Edit mode:

Click

The New Type field is displayed.
Select

The Item Types field is expanded to allow the User to create a new Item Type.
Enter the Name for the Item Type and set all other Item Type template information
Click Save

The screen displays Item Details Fields for the Item being created.
Enter any known details in the Item Details Fields

This information will automatically be populated to the newly created Item's Details tab, when the Deployment Task is completed and the Item entered into the CMDB.
Upload a media file for the new Item, if relevant

The media file may be an installer or executable file and will be made available within the Deployment Task.
Click Save.

Additional Item Types can be added to the Release by repeating the above process.

To upgrade Items as part of the Release, define the Item Type within the Types tab in Edit mode by:

Click
Set the Reason to Update

The Find Item Type option is displayed.
Search and select an Item Type

The Item Details Fields are displayed.
Complete any information that is to be updated in existing Items associated with the Item Type

For example, if the Release involves upgrading software it would be relevant to include the new version number in the Item Details. All Items that use this Item Type would have their Item Details automatically updated, based on the information entered here, when the Deployment Tasks are completed.
Upload a media file for the new Item, if relevant

The media file may be an installer or executable file and will be made available within the Deployment Task.
Click Save.

Additional Item Types can be added to the Release by repeating the above process.

To replace Items as part of the Release, define the Item Type within the Types tab in Edit mode by:

Click
Set the Reason to Replace

The Find Item Type search field is available for the Item Type that is to be replaced. The New Type field displays the options to create a new Item Type by selecting or searching on an existing Item Type using the Find Item Type field.
Search and select the Item Type to be replaced
Use the Find Item Type field within the New Type field to replace the Item Type with a Type that exists in the CMDB

Or, create a new Item Type by clicking . The Item Types field is expanded to allow the Manager to create a new Item Type.
Enter the Name for the Item Type and set all other Item Type template information
Click Save

For the new or existing Item Type associated within the New Type field the screen displays Item Details Fields for the Item being created.
Enter any known details in the Item Details Fields

This information will automatically be populated to the newly created Item's Details tab, when the Deployment Task is completed and the Item entered into the CMDB.
Upload a media file for the new Item, if relevant

The media file may be an installer or executable file and will be made available within the Deployment Task.
Click Save.

Additional Item Types can be added to the Release by repeating the above process.

After all the Item Types have been added to the Release click Save, and move to the Analysis tab to associate any pre-existing Change Requests to the Release package.

Analysis Tab

As a Release Manager, the Analysis tab allows you to associate any pre-existing Change Requests to a Release. To add RFCs to a Release within the Analysis tab, check boxes next to relevant Request # links and click .

Elements Tab

The Elements tab allows the Release Manager to view all Change Requests associated with the Release and output this information to PDF. This list can be managed by allowing the Manager to remove any irrelevant RFCs from the Release package.

To remove any RFCs from the Release, check boxes next to relevant Request # links and click .

Deploy Tab

The Deploy tab allows the Manager to define where the Deployment is to be pushed and who will be working on the Release by creating Deployment Tasks. Deployments can be created on a Per Customer, Per Organizational Unit or Global Deployment basis.

To define the Deployments for the Release, with the Deployments tab in Edit mode:

Click New

Set the Deployment Type option:

Options	Description
Deployment per Customer	Allows specific Customers and Items to be assigned to the Deployment. By selecting this option Customer Names are displayed for Customers that own Items derived from Item Types associated with the Release. Use the Search Options field to find a specific Customer. Use this option if an Item being created, updated or replaced is to be owned by the Customer directly.
Deployment per Org. Unit	Allows Organizational Units to be assigned to the Deployment for the Release. Selecting this option displays Org Units configured in the system. Use this option for Items that are created, updated or replaced as part of the Deployment, which are shared by all Org. Units included in the Deployment or are assigned ownership on a per Org. Unit basis. NOTE:Use the Search Options field to find a specific Org. Unit or select Search All for a search and view all Org.Units configured in the system.
Global Deployment	Sets the Workflow that includes the relevant stages to manage the Release. Selecting this option creates the Deployment for the entire customer base and displays the Next button.

Options

Description

Deployment per Customer

Allows specific Customers and Items to be assigned to the Deployment. By selecting this option Customer Names are displayed for Customers that own Items derived from Item Types associated with the Release. Use the Search Options field to find a specific Customer.

Use this option if an Item being created, updated or replaced is to be owned by the Customer directly.

Deployment per Org. Unit

Allows Organizational Units to be assigned to the Deployment for the Release. Selecting this option displays Org Units configured in the system.

Use this option for Items that are created, updated or replaced as part of the Deployment, which are shared by all Org. Units included in the Deployment or are assigned ownership on a per Org. Unit basis.

NOTE:Use the Search Options field to find a specific Org. Unit or select Search All for a search and view all Org.Units configured in the system.

Global Deployment

Sets the Workflow that includes the relevant stages to manage the Release. Selecting this option creates the Deployment for the entire customer base and displays the Next button.

Tick the relevant Deployment targets in the list, for Customer or Org. Unit Deployments
Click

The selections are added to the Deployment and displayed in the Selected Org. Units side-bar.
Click Next

The screen allows the Manager to define the Deployment Work Group who will action the Deployment Tasks of the Release, and the State of the Deployment Workflow in which the tasks are to be actioned.

The Items Field will also display any Items associated with the Customer or Org Unit for Update or Replace Item Type Releases.
Set the Work Group who will complete the Deployment Tasks

The list is derived from the Groups tab of a Release Team.
Set the Workflow State that the Deployment Tasks move to Open

This is when the tasks are to be worked on by Technicians in the Work Group. The Deploy Status list is derived from Release Workflow States that have Deployment State option set to Yes.
ForUpdate & Replace Item Releases, select one, multiple or all Items displayed in the Items List or use to search for Items
Click once the Items have been identified

The Items will be listed in a Selected Items sidebar.
ForNew Item Releases, click

The screen defaults to the New Types list.
Select the Item Type for the Deployment
Set the Item Ownership Status
Click Create

The Selected Item box displays the New Item to be created. Continue to create Deployment Tasks, if relevant or click Create to lodge the Deployment in the system.
Click Done when all Deployment Tasks have been created.

A unique reference number is automatically generated for the request at this point. The Deployments will be listed within the Change>Deployments tab.

When all Deployment Tasks are created they are included in the Deployments listed in the Change>Deployments screen. The individual Deployment Tasks will be visible within the All Deployment Tasks filter of the Change>Deployment Tasks tab.

Working on Deployment Tasks

Releases can have multiple Deployments that are to be completed at different stages of a Release lifecyle, and to allow for this, multiple stages of the Release Workflow can be defined as Deployment States when creating a Release Workflow. The different Deployment States can be selected as the Deploy Status for a Deployment when a Release is created in the system. Then, as the Release Manager moves through the Release Workflow, by adjusting the Next Action State in the Details tab of the Release, and when a State that is assigned as the Deploy Status for the Deployment is assigned to the Release, the Deployment Tasks move into an active Open State.

When a State that is assigned as a Deploy Status is selected for the Release, the Deployment Tasks for that Deployment created within the Release move to Open and can be actioned by the assigned Technicians. However, if Control Deployment via RFC is enabled, when the Release moves into the Deployment State, RFCs are automatically created for the Deployment, and only when the RFCs hit the Deploy State configured for the RFC Control option within the Details tab of the Release do the Deployment Tasks become active. The Change Manager can view all Deployment Tasks related to the RFC within the RFC Summary screen, and when all Tasks are moved to Closed-Resolved the Change Manager can close the related RFC.

When all Deployment Tasks are completed, the Deployment is automatically closed by the system. When all Deployments are closed for a Release, the Release Manager can close the Release within the Details Tab, by moving the Release Workflow Status to the Exit State.

Release Management Applied

Release Management in the system provides Release and Deployment Managers with a centralized repository for managing the introduction of changes, regardless of size or risk, to the environment. Two examples for rolling out a Release are detailed below, as Releases can potentially be very complex, which requires great flexibility in the system.

The first example illustrates a software rollout, with software being upgraded, replaced and a couple of new installations. Although this Release may be considered a little complicated, the nature of the Release is low risk. Due to the minimal business criticality level of the Release, it has been decided that this deployment will not be controlled by Change Management. The second example that manages the update of Microsoft Exchange, a higher risk Release, controls the Deployment with Change Management.

Before commencing the examples, the system needs to be configured to handle Release Management and the following elements must be in place:

Users assigned the Release & Deployment Process

Create a Release & Deployment Team

Build or Edit the Release Workflow

Example 1: Install, upgrade and replace Office packages

Release Objective: To rollout the latest update of Office 2008 to customers. Replacing existing software for customers that have Open Office, and installing new software for customers without access to any Office applications.

The Release Team that will action the Deployment Tasks has also been divided into three Groups: Software, Hardware and all Deployment Technicians.

To create the Release:

Go to Change>Releases
Click New

Complete the Release information

Release Fields	Description
Name	Enter a Name that reflects the objective of the Release.
Priority	Set the Priority, which will correspond to the target timeframes for the SLAs associated with the Release via the RFCs.
Team	Select the Release Team who will oversee all part of the Release.
Workflow	Set the Workflow that includes the relevant stages to manage the Release. The Release Manager moves the Release through the stages of the Workflow, relevant to the events being undertaken and completed.
Status	This is set to the Default Entry State of the selected Workflow.
Next Action	Based on the assigned Workflow, select the next Workflow State for the Release, as required by the next Release activity. Some States are Approval States, when the Release moves to an Approval State the Approve and Reject options are visible. The Release Manager selects the appropriate option and the system automatically moves the Release to the pre-configured next State, relative to the option applied.
Manager	From the drop-down list of Managers assigned to the default Entry Point of the assigned Release Workflow, select the Release Manager to manage the project when it is initially created. The User defined here, is the Manager who can edit the Release after it is saved and then move it to the next State.
RFC Control	If the Control Deployments via RFC option is enabled in Admin>Setp>Privileges>Requests, this field will be displayed. Select Yes if the Deployment is to be routed through Change Management, to enable the scheduling of Deployment Tasks. Select the RFC Workflow to manage the Change Request associated with the Deployment, and set the default open State or Deployment State for the Tasks.
Description	Enter information that describes the goal of the Release.

Select Save.

From the above screen snap, we can see that Simone Supervisor is the Release Manager assigned to the Release and that the Release is of low Priority, will be handled by the Release Team and managed using the Release Workflow. The Release is currently in the default entry point of the Release, the Plan State. It should be noted that moving through the Release Workflow is determined by your organization's business processes and the defined Workflow. The system is to be used as a central repository to manage Releases and a point of reference to keep all relevant parties updated regarding a Release.

Assign Item Types

To associate the Items that are to be created or updated as part of the Release, the Release Manager has to define the reason for the Release and assign the relevant Item Type to the Release. This is achieved within the Item Types tab of the Release. For our example, there will be three reasons for the Release:- Upgrade existing software, replacing existing software and installing new software.

As a Release Manager, to assign Item Types to the Release:

Select the Item Types tab inside the Release information screen
Click Edit
Click Add
Assign the Reason of Update

For customers with Office 2008, based on the system configuration within the CMDB Item Type of Office 2008, we will just be updating the software version number in the Item Details tab.
Search and select the Item Type Office 2008 in the Find Item Type field

When the Item Type is associated with the Release, the fields available on the Details Tab of Items using the Type are displayed.
Enter the information that is to be updated against the Item in the CMDB and Save

For our example 2011 will be entered in the Version # field.
To replace Open Office with Microsoft Office 2008, click Add
Select the Reason of Replace

The Find Item Type field is displayed next to the New Type field.
Search and Select the Item Type to be replaced within the Item Type field

For this example it is Open Office.
Select the Item Type link for the Item Type to be replaced
Search and Select the Item Type that is to replace the existing Item Type

For this example, Office 2008 is the replacing Item Type.
Select the Item Type link for the Item Type information to be replaced

The fields contained on the Details tab of Items applying the Item Type are automatically displayed.
Enter information into the fields that are to be updated on the Items in the CMDB

For this example, the Version # details is updated to include 12.0.3.
Click Save
To create new Items in the system, click Add

The Reason of New is assigned by default.
Search and select the Item Type to be applied to newly created Items in the CMDB

For this example, new Items using Office 2008 are being created.
Assign the Item Type to the Release

The fields available on the Details tab of Items using the Type are displayed.
Enter the information that is to be updated against the Item in the CMDB

For our example 12.0.3 will be entered in the Version # field.
Click Save
After all Types have been assigned to the Release, move the Release to the next relevant State.

For this example, the Release moves to Plan Approval and approval is given. The system automatically moves the Release to Build.

As the Release is not to be managed using Change Management, the Release Manager can move directly to the Deploy tab to create the Deployment Tasks.

Create Deployment Activities

Deployment Tasks, the activities completed by Technicians included in the Release Team Groups, are created in the system by considering the physical location of the Customer or Organizational Unit. That is, when grouping the tasks that are to be completed as part of a Release, the system presents the information based on Customer location so Technicians can be deployed to specific locations to complete jobs.

Tasks can be created on a per Customer Deployment basis for Items that are assigned specifically to Customers. Or, for Items that are shared across Org. Units or by an Org. Unit, the Create option of Deployment per Org. Unit can be used for creating the Deployment. The Global Deployment option allows the Tasks to be created for the whole Organization as the Item being updated, created or replaced is owned/accessed by all Customers in the system.

Once the Customers are assigned to the Deployment, either directly or via an Organizational Unit the Release Manager must define the Group of Technicians within the Release Management Team who will action the Tasks and set the stage of the Release Workflow for the Deployment Tasks to move into an Active State ready to be completed by Technicians.

To create the group of Deployment Tasks:

Select the Deployments tab inside the Release information screen
Click New

The screen expands to show the options for the type of deployment to be created, the list of Customers who own an Item associated with the Item Types included in the Release Types tab and the Search Options box.
Select the type of Deployment that is to be created

For this example, per Customer Deployments will be created as all Items associated with the Release are owned directly by Customers. The list of Customers can be sorted into Org. Unit groups by clicking the toggle in the Org. Unit Column Header.
Assign the Customer(s) to the per Customer Deployment by selecting the field next to the Customer name and clicking

The selection is included in a Selected Customers window to the right of the main window. When all Customers are assigned to the Deployment, the group of Technicians who will action the Tasks and the Workflow State where the Tasks will become active in the system must be defined.
Click Next
Select the Group of Technicians who will work on the Deployment Tasks from the Group drop-down list

For this example the Software Technicians will be assigned.
Assign the stage of the Workflow where the Deployment Tasks will become active in the system

As the Release is related to simply upgrading or installing Office 2008, the Deploy State will be assigned as the action State.
Select the Items to be included in the Deployment

For this example, as the replacement and upgrade of Items is simple software, all Items will be created as one Deployment that will result in individual Tasks being created.
Click
Click
For the new installations of Office for customers select within the Items field
Tick the relevant Item Type and define if the Item is to be shared or one created for each Customer
Click
Click Done.

All Tasks are now saved with a Status of Pending assigned. When the Release Workflow moves to the Deploy State, the Tasks' Status will automatically by updated to Open, prompting Technicians to complete the Deployment Tasks and move their State to Closed - Resolved. When all Tasks are completed and moved to Closed - Resolved, the Release will be automatically Closed.

Action Deployment Tasks

The Deployment activities created within the Deploy tab of the Release are listed in the Deployments and Deployment Tasks tabs of Change in the system. The Release Manager works the Release through the assigned workflow within the Details tab of the Release. When the Status of the Workflow is set to the Deploy State defined within the Deployment, the Tasks will move from Pending to Open.

For this example, within the Releases>Release#>Details tab the Release Manager has moved the Release through the Workflow States of Plan, Plan Approval, Build, Test and is currently assigned the State of Deploy Approval. Selecting Accept will move the Release to Deploy, and the associated Tasks will automatically move to Open.

Within the Change > Deployment Tasks tab, Technicians can edit Deployment Tasks by adding Notes using the New Note button, which are stored in the Notes tab, or update the Status of the Task to Closed-Resolved. When all Deployment Tasks are completed, the Deployment is automatically closed by the system. When all Deployments are closed for a Release, the Release Manager can close the Release within the Details tab, by moving the Release Workflow Status to the Exit State.

Item details in the CMDB are also automatically updated, based on the information included in the Release.

Example 2: Update Microsoft Exchange

Although this is considered a less complex activity as it involves only one Item, due to the business critical nature of Exchange the risk is higher. Therefore, as a Release Manager, it has been decided to manage this Release using Change Control. To manage Deployments using Change Management, ensure the Administrator has enabled the Control Deployments via RFC option in the Setup>Privileges>Requests Tab.

Release Objective: To update Exchange to Microsoft Exchange 2010

The example will apply the system default Release Workflow that includes an added Workflow State of Trial Deploy and also has a number of Approval States. It includes Deploy and Trial Deploy States, as the stages of the Workflow where the related Change Requests (RFCs) are automatically created for the Deployment, and only when the RFCs hit the Deploy State configured for the RFC Control within the Details tab of the Release do the Deployment Tasks become active. The Change Manager can view all Deployment Tasks related to the RFC within the RFC Summary screen, and when all Tasks are moved to Closed-Resolved the Change Manager can close the related RFC.

The Release Team that will action the Deployment Tasks has also been broken down into three groups, Software, Hardware and all Deployment Technicians.

To create a Release with the Deployment Control managed by Change Management:

Define the settings within the Details Tab and set the RFC Control option to Yes
Click Save

From the above screen snap, we can see that Simone Supervisor is the Release Manager assigned to the Release and that the Release is of low Priority, will be handled by the Release Team and managed using the Release Workflow. The Release is currently in the default entry point of the Release, the Plan State. It should be noted that moving through the Release Workflow is determined by your organization's business processes and the defined Workflow. The system is to be used as a central repository to manage Releases and a point of reference to keep all relevant parties updated regarding a Release.
Move to the Item Types tab
Click Edit
Select Add and set the Reason to Update
Within the Find Item Type field, search for Exchange
Click on the Exchange link to add it to the Release
Upload Media Attachments, if relevant

If an electronic upgrade file is to be used for the upgrade, it can be uploaded within the Media Attachment field. This would then be made available within the Deployment Task associated with the Release.
Enter information that is to be updated on the Details tab of the Item being updated

These will automatically be updated in the CMDB when the Deployment Task moves from Open to Closed-Resolved.
Click Save and Save again.

Move to the Analysis Tab.

Associating RFCs with the Release

Within the Analysis tab, the Release Manager can access a list of existing RFCs that are yet to be associated with the Release. To add an existing RFC to the Release, the checkbox is marked next to the Request # link, and the Add button is clicked. The RFC no longer appears in the Analysis tab, and is now visible in the Elements tab, where it can be removed if the association was made in error.

For this example, it is assumed no relevant RFCs exist in the system, so we move to the Deployments tab where the RFC will be created as a result of the Deployment.

To create the Deployment:

Select the Deployments tab inside the Release information screen
Click New

The screen expands to show the options for the type of deployment to be created, the list of Customers who own an Item associated with the Item Types included in the Release Types tab and the Search Options box.
Select the type of Deployment that is to be created

For this example, a per Org. Unit Deployment will be created as the Item associated with the Release has shared ownership. When selected, the Organizational Unit associated with the Item that uses the Item Type associated with the Release is displayed in the Org. Unit. list.
Assign the Org. Unit by selecting the field next to the Org. Unit name and clicking

The selection is included in a Selected Org. Units window to the right of the main window. The group of Technicians who will action the Tasks and the Workflow State where the RFC will be created to manage the Deployment must be defined.
Click Next
Select the Group of Technicians who will work on the Deployment Tasks from the Group drop-down list

For this example the Software Deploy Group of Technicians will be assigned.
Assign the stage of the Workflow where the RFC will be created for the Deployment

When the Release Workflow moves into the Deploy State, for this example, an RFC will be generated. This RFC will be assigned the Change Deployment Workflow and be assigned to the Change Team. When the RFC is assigned the Status of Deployed the Deployment Task will move from Pending to Open, allowing the Team member from within the Software Deploy Group of the Release Team to action the Deployment Task.
Select the Item Type to be upgraded in the Deployment

If an Item Type is not displayed in the list, click to search the CMDB.
Click

The selection is displayed in the Select Items window to the right of the main window. If an incorrect assignment has been made, click.
Click Create
Click Done.

All Tasks are now saved with a Status of Pending assigned. When the Release Workflow moves to the Deploy State an RFC will be created. When the RFC hits the Release's RFC Control Deploy State the Tasks' Status will automatically be updated to Open, prompting Technicians to complete the Deployment Tasks and move the State to Closed-Resolved. When all Tasks are completed and moved to Closed - Resolved, the Release will be automatically Closed.

RFC Creation and Management

The Release Manager moves the Release through the lifecycle of the Workflow as activities are completed. For this example, within the Releases>Release#>Details tab the Release Manager has moved the Release through the Workflow States of Plan, Plan Approval, Build, Test and is currently assigned the State of Deploy Approval. Selecting Accept will move the Release to Deploy, and an RFC will automatically be created.

From the above RFC, we can see that the Change Team has been assigned the RFC, and they will move the Request through the Change Deployment Workflow.

This Workflow includes the stages of Pending>Approval>Schedule Outage>On Hold>Deploy>Closed. When the RFC is assigned the Deploy State, the Deployment Tasks created in the Release, and now available in the Change>Deployment Tasks tab, will move automatically move from Pending to Open, and the assigned Technician can action the Task before moving the Deployment Task State to Closed - Resolved.

When the Task Status is set to Closed-Resolved, the updated Details contained in the Release will automatically be updated on the relevant Item in the CMDB. The Change Manager can view all Deployment Tasks related to the RFC within the RFC Summary screen, and when all Tasks are moved to Closed-Resolved the Change Manager can close the related RFC. When the Deployment Task is completed, the Deployment within the Change > Deployments tab is automatically closed by the system.

When the Deployment is closed for a Release, the Release Manager can close the Release within the Details Tab, by moving the Release Workflow Status to the Exit State.

2.5.7 Deployments

Deployments

Deployments are the grouping of one or more Deployment Tasks that are generated as part of a Release.

Users who are assigned the Change Process of Release are provided access to the Release, Deployments and Deployment Tasks sub-menu options within Change. These Users can oversee the Release process and also action Deployment Tasks, as required.

The Deployments screen provides Users with a complete list of Deployments created within Releases and allows the Manager to update Deployment information, such as Deployment Priority, Group and Attachments, as required.

By default the List View includes the Deployment Title and number of Tasks associated with Deployment.

The filter view includes the options of Active and All Deployments. The list can be re-sorted by clicking on a column header and the number of Deployments displayed per batch, can be altered using the Display pop-up option.

Within this screen, Users can search Deployments and output information in PDF and Excel format.

Deployment Details

To view information regarding a Deployment:

Select Change>Deployments
Click on the Deployment# link

Click Edit

The following information is displayed:

Deployment Fields	Description
Name	By default the Deployment Name combines the Release Name and name of the Deployment Target, be that a specific Customer, Org. Unit or Everyone. If warranted, edit the Name as required.
Release	Shows the name of the Release associated with the Deployment.
Group	Show the Group of Technicians assigned to action the Deployment Tasks.
Deploy Status	Shows the Release Workflow State assigned as the "Deployment" State, that is the stage of the Workflow when the Deployment Tasks move from Pending to Open, allowing the Technician to work on the Task. For Deployments controlled by Change Management, this is the State defined in the Release that RFCs are created to control the Deployment.
Priority	Shows the assigned Priority of the Release, which will correspond to the target timeframes for the SLAs associated with the Release via the RFCs. Adjust as required.
Status	This shows assigned State of the Deployment Tasks. The options are Pending, Open and Closed-Resolved.
Control RFC	The Change Request number associated with the Deployment is displayed as a link and allows the User to view the RFC by clicking the link.
Description	Shows the information entered that describes the goal of the Release. Adjust, if required.

Upload any attachments, if relevant
Click Save to record changes or Delete to remove the Deployment and erase all related Deployment Tasks.

Attachments

The Attachments tab allows the Manager to upload any relevant files, but also provides access to any Media Files that are associated with Deployments.

To add Attachments to a Deployment, within the Deployment's Details tab:

Click Edit
Select the Attachment tab
Click New
Browse and select a file
Enter a Description, if required
Click.

History

The History tab records all changes and updates for the Deployment, relative to the assigned Workflow State. To view a historical entry within the Deployment Details tab:

Select the History tab
Click on the identification number hyperlink to display the entry details.
Click Cancel

The expanded window is closed.

Deployment Tasks

The Tasks tab lists all Deployment activities related to a Deployment. The User can add and remove Tasks within this tab, when the Deployment is not assigned a State that is configured as a Deployment Active State. They can also update the assigned Technician and Status, when the Tasks are in a Deployment Active State, of multiple Tasks by using the Bulk button.

To add Tasks to a Deployment group:

Go to Change >Deployments
Select the Deployment # link

The Deployment must not be in a Deployment Active State.
Move to the Tasks tab
Click

The Item options are displayed for adding Tasks.
Tick the relevant Deployment targets in the list, for Customer or Org. Unit Deployments
Click

The selections are added to the Deployment
Click Create
Select Done.

To remove Tasks from a Deployment group:

Go to Change >Deployments
Select the Deployment # link

The Deployment must not be in a Deployment Active State.
Move to the Tasks tab
Check the boxes of the Tasks to be removed
Click .

To bulk update the Technician or Status:

Go to Change >Deployments
Select the Deployment # link

The Deployment must not be in a Deployment Active State.
Move to the Tasks tab
Check the boxes of the Tasks to be updated
Select

The screen defaults to an Update screen, providing access to Technician and/or Status drop-down options.
Make the required change

For Status updates, the options will be Open and Closed-Resolved. If all Tasks are Open, the only option displayed will be Closed-Resolved. If the Tasks have a mix of the two States, then Closed-Resolved and Open will be listed as Status options.
Click Save.

To review examples of Release and Deployments, refer to Release Management Applied.

2.5.8 Deployment Tasks

Deployment Tasks

Deployment Tasks are the activities that are completed as part of a Release, for specific Customers, Organizational Units or Everyone when adding a new Item, or updating or replacing an existing Item in the CMDB.

Users who are assigned the Change Process of Release or Deployment are provided access to the Deployment Tasks sub-menu option within Change. These Users can view, and action Deployment Tasks as configured within the Release Team.

The Deployment Tasks tab lists Tasks created within a Release and Users can search Deployment Tasks and edit Tasks that are assigned to them. Tasks can also be exported in PDF or Excel format.

The Deployment Tasks tab defaults to show active Tasks logged in the system. This view can be filtered to show:

Active Deployment Tasks
All Deployment Tasks
My Deployment Tasks

The list can be re-sorted by clicking on a column header and the number of Tasks displayed per batch, can be altered using the Display pop-up option

Working with Deployment Tasks

When a State that is assigned as a Deploy Status is selected for the Release, the Deployment Tasks for that Deployment created within the Release move to Open and can be actioned by the assigned Technicians. However, if the Control Deployment via RFC is enabled, when the Release moves into the Deployment State, RFCs are automatically created for the Deployment, and only when the RFCs hit the Deploy State configured for the RFC Control within the Details tab of the Release do the Deployment Tasks become active. The Change Manager can view all Deployment Tasks related to the RFC within the RFC Summary screen, and when all Tasks are moved to Closed-Resolved the Change Manager can close the related RFC.

To edit or process a Deployment Task:

Select Change > Deployment Tasks
Select the relevant Deployment Task # link

Only Users associated with the Group assigned to the Task can edit or add details to the Task.

The Summary includes the following information:

Tasks Fields	Description
Item Number	The number used to identify the Item in the CMDB. Click the link to view the Item Details.
Type	Details the Item Type of the Item.
Status	Shows the stage of the Item Lifecycle applied to the Item at the point of deployment.
Reason	Defines if the deployment is to create a new Item, update or replace an existing Item.
Affects	Lists the Customers, Org. Units affected by the Deployment Task. If it is Global Deployment, the field will state Everybody.
Workflow, Team	Shows the Release Workflow and Team assigned to the Release.
Manager	Includes the Release Manager's name.
Status	Shows the current State of the Release.
Group	Indicates the group of Technicians assigned to Deployment Task.
Technician	Shows the assigned Technician, but if multiple Technicians are in the Group, provides a drop down list of all Technicians. The Task can be reassigned here, if required.
Task Status	Indicates the current assigned State for the Deployment Task. The options are: Pending: Inactive State Open: Active and actionable State Closed-Resolved: Exit State. When the Release Workflow is an non-Deploy State, the Task will be locked at Pending. When the Release moves to a Deployment State, the Task automatically moves to Open.
Next Status	Allows the Technician to move the Task from Open to Closed-Resolved, when the Task has been completed.
FSC Date	This can be completed by the Technician to set the Forward Schedule Date for the Task. However, once the Task is moved to Closed-Resolved the field will be automatically populated with the Closed time and date.

Click Edit

Adjust information recorded in the Summary tab.
Click Save.

Notes Tab

The Notes tab allows Users to create Notes for updates regarding a Deployment Task. To view any Notes listed within the Notes Tab, click on the Note Number hyperlink.

Adding a Note

To add a Note:

Click

The Task opens in Edit mode and the new Note screen is visible
Enter the Note details
Enter Note Time

The time entered represents the amount of time accumulated to formulate the Note's content. If no additional time has been spent on the Task away from the application, leave this field blank, as the system calculates Logged Time when the request is in Edit mode.
Adjust the time and date work was completed, if required
Click Save.

Draft Note

Use the Draft button to save an incomplete Note entry, which will be displayed in the Notes list. If the Fast Note button is selected when a draft Note has been recorded against a Task, a warning will be displayed. To continue working on a draft Note, open the request in Edit mode and select the Note No. hyperlink.

Audit

The Audit tab records all changes and updates for the Deployment Task and lists who they were made by. The list can be exported by selecting the export to PDF icon.

To view an audit trail entry within the Deployment Task Summary tab:

Select the Audit Trail tab
Click on the identification number hyperlink to display the entry details
Click Cancel.

The expanded window is closed.

To review examples of Release and Deployments, refer to Release Management Applied.