5) Change, Release and DevOps

State Field (Change Task) [Implementation]

Pending Open In Progress Closed Canceled

2. Approval

Approval - Approval policies - Configure workflows - Configure CAB

4. Closure

Closure - Build PIR, if required.

Change Approval Policy [Approval]

Course of action that can be applied to a change request = uses a set of variable inputs to evaluate decisions associated w/it (each matching decision = associated approval definition is applies). - Can contain multiple decisions. - Based on Decision tables. - Order field: leverage all decisions that match or only run the first decision that matches.

3. Implementation

Implementation - Define change tasks per type.

Type Field (Change Task) [Implementation]

None Planning Implementation Testing Review

Change Request Form - Planning [Creation and Scope]

Planning tab: Justification Implementation plan Risk and impact analysis Backout plan Test plan **CAB-related fields hidden from form view through UI policy when viewing standard change.

Configuring Risk Conditions [Creation and Scope]

Risk conditions may set Risk and Impact fields. Calculate Risk UI Action = risk conditions evaluated in order + highest risk value returned. System displays message indicating which risk conditions led to final value [see photo].

DevOps(?)

[Make Quizlets.] p 304

Release Management End to End Lifecycle

p 301 [Review photo.]

Integration Points

API - ChangeRequest and ChangeRequestSNC script includes. Platform Web Services - Full support for REST and SOAP integrations. - Best Practice: leverage Import Sets and Transform Maps and lookup tables. ITSM Applications - Create change from incident, problem, service catalog, configuration management.

Change Request Interceptor [Creation and Scope]

Change > Create New (creates new record in Change Request [change_request] table) 1. Normal: opens new change request record in the Default view and sets Type to Normal. 2. Standard: - Redirects to Standard Change Catalog. - Standard Change Catalog > All Templates = items to request new standard changes/modify existing/retire existing. - Properties set to establish standards. 3. Emergency: opens new change request record in Default view and sets Type to Emergency. Edit Interceptor button: - Modify wording on existing option. - Modify target URLs. - Add new type of change. **System Definition > Interceptors (found and modified here)

Understanding Risk [Creation and Scope]

Change Risk Conditions: Risk assessed based on conditions in Change > Administration > Risk Conditions. Add/modify. Set to highest level based on matching conditions. ** Requires you to click Calculate Risk UI Action (glide.ui.risk_calculate_rule property may be set to calculate risk on insert and update of changes). **NEEDS RISK ASSESSMENT, SCHEDULE, and CI. Change Management - Risk Assessment plugin: Additional factor to use = define Risk assessment surveys (on form, click Risk Assessment + complete, responses scored and overall score matched against thresholds to calculate risk). ^Risk automatically collected when submitted. ^Run for Risk Conditions and Risk Survey (Related Links: Risk Assessment).

Change Tasks [Implementation]

Change Tasks created manually or automatically when changes enter Implement phase. Workflow triggers Change Request-<type> change tasks sub-workflow. Automatically generated tasks per change type include: Emergency - Implement - Post Implementation testing Normal - Implement - Post Implementation testing Standard - Implement - Post Implementation testing

Unauthorized Change Request [Creation and Scope]

"Unauthorized" Boolean automatically in Emergency Change. [Review more? p 238] Unplanned CI activity occurs on CIs that are part of an application service --> change captured to review impact and for approval to be requested. - Activity automatically identified. - Unauthorized emergency change request created. - CI field automatically populated (w/details of change in Description field). - Change request record automatically assigned to Change Management + notifications sent to tChange Management team/any defined owners.

PIR [Closure]

- No functionality or fields in baseline (when unauthorized Emergency Change Request record moves to state = Review, change task for PIR automatically created). - Varies greatly from customer to customer. - Typical custom functionality: new form section on change w/relevant fields, script include code prevent closure until PIR fields completed, modification in workflow to address PIR.

Change Advisory Boards (CAB) [Approval]

- Scoped Application - Multiple CABs supported. - Conditions define appropriate CAB per change. - Setup checklist: CAB Definition and Schedule Entries. Change Management - CAB Workbench application enabled by default. - Schedule series of CAB meetings. - Manage meeting invitations + track attendance. - Define CAB meeting agendas. - View change calendar. - Approve/reject changes. - Review/take meetin gnotes.

Key Change Management Features

- Standard Catalog Change - Standard Change Request and Approval Process - Workflows per Change Type - State Model Management - Risk and Conflict Detection Analysis - Change Advisory Board (CAB) Workbench - Blackout and Maintenance Schedules - Discovery and SAM Integrations

Change Request Workflow - STANDARD [Approval]

1. Change automatically marked as Approved, state = Scheduled. 2. State = Implement. - Actual start date populated with current date/time. - Change request - Standard change tasks sub-workflow called to generate change tasks. 3. When done, state = Review.

Change Lifecycle Review

1. Creation and Scope: create change request and document all relevant details (and locate one that was assigned to you/your group). 2. Approval: if necessary, change reviewed + can be approved or rejected. 3. Implementation: one or more change tasks may be created to guide through the implementation. 4. Closure: complete the PIR, if required (change may close automatically following completion of final change task or PIR process or manually close). **Change type determines details of process (including specific fields, approvals/pre-approvals, and which tasks, if any, are created).

Change Request Workflow - EMERGENCY [Approval]

1. Moved to state = Authorize. - Approvals requested from CAB Approval group members. - If one approves, change marked as Approved, state = Scheduled. - If Skipped, change marked as Approved, state = Scheduled. - If one rejects, state = New, Approval = Rejected. 2. If change begins, state = Implement. - Actual start date populated with current date/time. - Change request - Emergency change tasks sub-workflow called to generate change tasks. 3. Once done, state = Review. **Workflow automatically creates PIR if change is flagged as unauthorized OR if change related to an outage record.

Release Management Concepts

1. Product 2. Releases 3. Release Phases 4. Features 5. Release Tasks

Change Request Workflow - NORMAL [Approval]

1. Starts: user clicks "Request Approval" or changes state = Assess. 2. Technical approvals sent to members of the Assignment group. - If one approves, state = Authorize. - If one rejects, State = New, Approval = Rejected. 3. State = Authorized --> approvals requested from CABB (required moderate - high by default). - If one approves, change marked as Approved and state = Scheduled. - If one rejects, state = New, Approval = Rejected. 4. Change begins: state = Implement. - Actual start date populated with current date/time. - Change request - Normal change tasks sub-workflow called to generate change tasks. 5. Once implemented, state = Review.

Mobile

Approves can use ServiceNow Agent application to receive notifications, review and approve requests (directly from mobile devices). Can also: - Access change tasks assigned to them/group. - Add comments + work notes. - Reassign change tasks. - Receive push notifications.

Change Request Form - Conflicts [Creation and Scope]

Conflicts tab: Check Conflicts UI action (run manually) runs Conflict Detection logic manually + populates results in embedded list view. Change > Administration > Conflict Properties - Triggers: manual, insert or update of change records, scheduled jobs based on lead time to Planned start. - Checks: --not executing during blackout. --executing during approved maintenance window. --not running in time period that conflicts w/other changes. --conflicts with changes to parent and child CIs. --conflicts for all Affected CIs. Update Conflicts business rule runs on insert + update for all active changes to update conflict information. - Planned start >= 1 month away (run every 7 days) - Planned start <= 1 month away (run every 2 days) - Planned start < 1 week away (run daily) ^Runs more frequently as approaching Planned start date. **Schedules now defined at application service level.

1. Creation and Scope

Creation and Scope - Validate change types. - Validate state model. - Configure forms. - Configure Conflict Detection. - Configure risk.

Change > Overview

Dashboard includes widgets and reports to help users manage change process.

Integrations

Discovery Integration of change management and Discovery enables Discovery customers to automate the maintenance of any CI with an IP address. --> when Discovery triggered, status record created + linked to CI (Affected CI related list). Software Asset Management Integration of change management and software asset management provides insight into potential cost implication of a requested change. *SAM aka software asset management.

Process Flow - States used per change type

Displayed through the Process Flow on Change Record. Managed by state model State Includes [see photo]. ChangeRequestStateHandler - Constants to use when referring to change states within code. - Functions, like isNext, moveTo, canMoveTo, canMoveFrom, getNextStates, getStateName, getStateValue, isOnHold. ChangeRequestStateModel_<type> - to<state>_canMove (if conditions that must be met before change can move to a particular state, add logic in the appropriate 'canMove' function, ex. if customer wants all change tasks to be completed before moving from Implement to Review, include that validation here). - to<state>_moving (if fields must be updated/other system processing defined when moving one state to another, include logic in 'moving' function, ex. when change moving to Implement state, populate Work state field w/current date and time). Change Management > Configure Change Management > State model and transitions > Add a State to the State Model ^to add a new state.

Change Management ITSM Touchpoints

Incident = caused by/resolved by. Problem = caused by/solved by. Knowledge = knowledge updates. SC + Request = standard change. Configuration = CI creation/update (usually affects 1+). Release = builds, tests, executes. --> DevOps = automates, collaborates.

CAB Workbench [Approval]

Leverages Service Portal functionality --> interface for managing CAB meetings. Change manager and delegates have control to run meetings/take notes. 1. cab_workbench form view controls layout of Change Request form displayed in workbench. 2. To edit change record completely using default interface = click pencil icon (pop-up window). 3. Meeting notes recorded/sent to attendees after meeting. Meeting minutes associated w/entire CAB meeting (not with each change). Auto Add Agenda Decision option selected on CAB definition, CAB Workbench automatically logs approvals/rejections to work noes on CAB meeting notes.

Create Change [Creation and Scope]

Manual Creation Create from Change application. Incident Management UI Actions defined to Create Normal Change and Create Emergency Change (incidents must be active, not already associated w/a change request). Copy # of fields from incident to newly-created change request + update change request field on form to note relationship. Related Records section of incident form has field called Caused by Change. Problem Management UI Actions defined to Create Normal Change and Create Emergency Change (problems must be active, not associated w/a change request). Copy # fields from problem to new change request + update Change request field on problem to note relationship. Configuration Management Proposed changes may be associated with each Affected CI for a change. Once change implemented, prosed change applied to CI. Service Catalog Standard changes may be requested through Standard Change Catalog.

Metrics and Database Views

Metrics: track length of time changes stay in each approval state (ex. Not Yet Requested, Requested, Approved). Database views: exist to facilitate reporting if and when SLAs are associated w/change or incident time_worked field is leveraged.

Change Request Form - Schedule [Creation and Scope]

Schedule tab: Planned start date/Planned end date (used in conflict detection and risk assessment, risk conditions set to 'Very High' if lead time <3 days). Actual start date/Actual end date (set by functions in Change Request State Model scrip includes = Implement/Actual start date + Review/Actual end date). CAB required (doesn't drive application logic, but determines whether CAB is required based on CAB definitions). CAB date (when change added to CAB meeting agenda). CAB delegate (user who represents change in upcoming CAB meeting, included in notification). CAB recommendation (informational only).

Release Management Components

This application encompasses planning, design, build, configuration and testing of hardware and software releases to create a defined set of release components. - Handles releases using task record system. - Tasks can be assigned to appropriate release management team members. Release Management: effectively used to coordinate releases as a VEHICLE for planning releases, composed of individual features. Once release finalized, Change Item can be generates (custom-built UI action) = allows implementation + deployment of a release to be handled within change management process.

Exam Question [Creation and Scope]

True or False: you can copy a standard change. Answer = false. *When you copy a change, it'll create it as a different type (need to go through process again). Risk Assessment Process: make sure you take into account the risk. Fill it out but doesn't automatically do it --> have to click "Calculate Risk" (business rule).

Scoping Discussion Topics

[Do I need to memorize this?] Core discussions and decisions that need to come from change management workshops.

Use Case Diagram

[Memorize photo.] ITSM Roles Plugin (com.snc.itsm.roles) plugin = provide more granular roles = (ITSM Roles - Change Management) sn_change_read and sn_change_write AND Business Stakeholder plugin, which automatically activates approver_user. **No role or user has the ability to update the change type on an existing record or the ability to delete a standard change proposal.

Change Management Platform Roles

[Memorize photo.] p 232 Takeaways: - No admin, itil_admin or itil role can approve change requests. - [look at CAB things] - itil_admin can DELETE but an itil role cannot. Roles can do what? What are roles called?

Release Management v2 Table Structure

[Memorize photo?] Release Management v2 plugin (table structure): Parent and Child release and Parent and Child features. Table differ from old Release tables because they're now extensions of Planned Task table (now use all functionality specific to the Task table, ex. Approval and Assuagement Rules AND standard time-related functionality provided by Planned Task).

Change Architecture - Data Structures

[Memorize table.] Table > Show Schema Map 1. Change Request [change_request] extends from the Task [task] table AND stores change requests. 2. Change Task [change_task] extends from Task, BUT is RELATED to Change (table is a related list on the Change Request form). 3. Related tables for Change (including other ITSM processes). 4. Referenced foundation data tables.

Flow of Work

[Memorize?]

Conduit for Most IT Work

[Photo?]

Comparing Change, Release and Devops

[Review photo.] Change = see that something has been altered. Release = falls under change (build/testing of new release). DevOps = make sure everyone is informed/working together/on the same page.

Configuring Risk Assessments - v2.0 [Creation and Scope]

[View photo.] Related Links has Edit in Assessment Designer (create + view survey in visual format). Similar to Flow Designer - drag/drop different types of questions, specify answers and give scores.

Release Management ITSM Touchpoints

p 295 Serves as an input/output to other ITSM process areas (Release is...): - Incident: caused by or result in. - Problem: known errors documented. - Change: container for change requests and manages execution of change management. - Knowledge: input to knowledge articles. - SC + Request: input to updates and new items. - CMDB: leverages for planning. - DevOps: automates and collaborates.

Release Phases and Process Integrations

p 298 1. Release Planning Defines specific plans for the release that are agreeable to all relevant stakeholders/support fulfillment of the involved changes. Plans subject to authorization requirements specified by change governance and release policy. Plans updated/refined as necessary throughout lifecycle of the release. 2. Build and Test These activities start w/authorization to build release + end with change management authorization for release package to be checked into the DML through Configuration Management process. This phase = release may cycle through multiple iterations of building/testing/authorization (via sprints) until package ready for deployment and satisfies Change governance. 3. Deployment Activities begin w/authorization to deploy release package to 1+ target environments, ends w/handover to service operations + early life support. Any known errors documented via Problem Management. 4. Review and Close Release view and closure marks conclusion = includes formal review of deployment activities from start to finish (including final status of release record, which is also reflected in associated change records).

Example Product Hierarchy

p 300 What release hierarchy might look like for product, Service-Now.com that has 2 releases + release phases, features and tasks within those releases. Product [rm_product] is Service-Now.com --> parent of two release records [rm_release] --> each is the parent of 3 release phase records [rm_release_phase] --> release phase RLSE001003 is parent of 2 release features [rm_feature] --> parent of 2 release tasks [rm_task]. **Parent reference field available to all of them.