Content Comparison

Identify release date 9/27 (pushed to 10/11)

see Release Calendar

minutes

Schedule cloning

clone from prd to: pre, trn, and tst for after release; https://hi.service-now.com/

minutes

Schedule code review

this should happen after initial handover and before release

minutes

Submit change request CHG0003347

Open a build/test change request in https://yale.service-now.com/

,

assign

to

INF

SN

App

Support

minutes

Start release document

Copy from template ServiceNow Release YYYY-MM-DD

minutes

Requirements freeze

Curate, then freeze requirements, providing estimates for each using estimator spreadsheet or equivalent

hours

Build phase work

Begin work in dev

days

Unit tests

Ensure all pushed to tst & unit tested

hours

Initial code freeze

Hand over initial requirements list for functional & QA validation in tst

minutes

Conduct code review

Shouldn't take long, just basic validation of approach and docs

hours

Defect fixes

Iterative follow-up work in dev, test for defect resolution

days

Finalize release

Identify changes & updates that are going/not going. Push to pre.

hours

Final code freeze

Hand over final requirements list for functional & QA validation, w/ regression, in pre

minutes

Go/no-go

Decide to push to production.

minutes

Production deployment

Push to prd.

hours

(n/a)

Production rollback

If applicable; follow ServiceNow Rollback Procedure.

hours

Notify stakeholders

send out email w/ summary status & link to release documentation, close out RFC and cancel clone requests, if rollback or no-go.

minutes

Target/Actuals

Deliver target/actuals using estimator spreadsheet or equivalent

hours

584

Knowledge: Allow all ITIL users the ability to create a new KB Submission. They should see the 'Submissions' section and nothing else under this menu. There should be an item added to the Submissions section that says 'Create New Submission'. Clicking on this would create a new SUB ticket, not a KB ticket. See attachment for screen shot.

588

When a KB article is created fill the 'role' field by default with the 'itil' role.

533

Currently the published date is prepopulated with today, even though the submission is in draft state. That field should be blank, non-required, until the article is published. Once the article is put into published status and saved, the published date field should be mandatory and auto-filled with the date the article is put into published status. Lori would prefer that the published date be a non-editable field, it should just be set when the workflow requires it.
(The other reason that the published date being mandatory and a date after today being annoying is that anytime I want to save a draft I have to update the date to today or a future date. This seems counterintuitive.)
Move the published date field down towards the bottom of the screen in the 'Activity' section with the author, created, updated by and updated fields.

585

Knowledge: When KB Submissions are created they should automatically be assigned to MGT Knowledge Management queue. They are currently not assigned to any unit and Lori must go in and manually assign them to her assignment unit.

387

User comments should not be shown on the published Knowledge record. Only folks with the knowledge manager role should be able to see feedback left on the KB article. Note that if the ability to view the user comments cannot be restricted to just the folks with the Knowledge Manager role just remove the ability to submit feedback comments.

660

Knowledge: Information from the Incident (Text, Submitted By) should be pulled into the KB Submission when it's created from an Incident.

661

Knowledge: All the 'Save and Exit' button to the Create Article knowledge screen.

516

This is an example of an email to a Client from the Service Now system. Can the wording be changed when a work order is put on "Hold" where it says that "Your ticket has been placed on hold because we require additional information from you" My Client's understand why the work order has been placed on Hold but are getting confused because it says that "we require additional information from you".
How about something like this, "Your ticket has been placed on Hold. You can click on the following link to check the status of your ticket."
submitted by Marty Wallace/John Martino
Please note these are covered in the attachment for Requirement #659.

364

When an Incident is put on hold the 'additional comments' field is required to let the customer know why their Incident was put on hold. This is OK. However when the ticket is updated with ANY update when the Incident is on hold the additional comments field is required and when this field is updated it sends a notification to the client/contact. Sometimes the tech or someone else needs to update the work notes or change a categorization or assignee and the client should not receive an update. This 'additional comments' field needs to be required ONLY when the ticket is placed on hold and not for subsequent updates afterwards.

481

Email Notification: List the resolution in the ticket in closure email notification so folks know how the issue was resolved. Please note these are covered in the attachment for Requirement #659.

432

Incident Email Notification Modifications per Dawn Colonese. Please note these are covered in the attachment for Requirement #659.
1) On all email notifications add a link to the ticket referenced in the notification.
2) On email notifications to the client that let them know the ticket has been opened include the name of the person who opened the ticket. If no person opened ticket (e.g. via email intake) no name added, just include the service desk contact information.
3) On any follow up email notification to the client include the Incident assignee's name in the signature. If there is no assignee then it's the person who started the ticket.

659

- iterate on defect fixes

Make Changes to Customer Facing Incident Email Notifications. See attachment for text.

662

Queries: Create a special query for the DSPs so they may view and sort their work by DSP contract.

664

Request for New Request Type: RITM0017469. This request will allow you to publish or share a template or a report with another assignment group. Requested by/for the ITSM team.

657

This service request allows you to request adding or removing staff from ServiceNow assignment groups. Requested by Adriene Radcliffe.

656

This will request a virtual machine in the Enterprise VMware infrastructure. Requested by Mike Caplin on behalf of John Coleman.

663

General System: Integrate ServiceNow with Bomgar

375

(n/a) emails were sent & received for both incidents

Sept 27 Release Testing: Client facing emails not being sent from TEST system. Creating a new ticket, updating the ticket and resolving the ticket are not sending emails from the system to the customer. The ticket is being updated with the updates however no email is being sent. See INC0053338 or INC0053340 for an example.

376

added a column for SCTASK dotwalk

Sept 27 Release Testing: The DSP Query is not showing the CONTRACT, the field in the query output is blank. We need to see the short description in the SERVICE CONTRACT in this spot.

377

this didn't carry over in update set, made a note for manual change during deployment

Sept 27 Release Testing: Assignment Group not set to INF SN App Support for SC Tasks for request for SN Assignment Group changes. Request creates RITM correctly and creates SC Tasks correctly however they are not assigned to SN INF App Suppoprt assignment group.

378

with caveats, see description

Multiple defects in the Add/Remove SN Assignment Group Membership:
1. Form behavior - In a case where a user is request more than one change - after clicking the "Add to Cart" button, the "Select Staff Member" field should be reset so there is no entry. as-is it's a more efficient design... either group or user may stay the same for next entry.
2. RITM - The Client and Contact fields display but without the field names listed
3. RITM - on the Remove items, the Queue Manager is extraneous. This does not effect the operation, it may just appear confusing to someone looking at the resulting RITM (not a show stopper) this is the way it works for all requests... unless we open a separate defect for it, it doesn't make sense to address it at this early stage
4. RITM - Estimated Delivery should be set to 2 days in all cases was it in the release requirements to start using this field?
5a. Resulting SCTASK - has "Requested for" which should be Client, was this in the release requirements to change the sctask form?
5b. [Resulting SCTASK] does not show Contact, does not show the variables for staff member being added/removed, or queue manager value
6. Notifications should be sent to CONTACT on completion, but I could not test that not clear what this means, because there is an existing notification for the parent request that goes to requested_for, and then there are fulfillment notifications for each request item; these go to the contact. I've changed the request notification to opened_by.

379

Defect/enhancement reported from Mike Caplin:
1. "Template to be deployed" variable does not prop over to related SCTASK
2. Enhancement - Can TEXT field at the bottom for form titled "Additional Information". Prop that to both the RITM and SCTASK

380

Email notification 1B (Incident created via self-service portal or email) is missing a word in the subject line. Please add the word 'Received' to the subject. It should read "Request for ITS Support Received - Ticket Number: XXXXX"

381

yes, this is a non-issue, the URL is parametrized

This may be a non-issue and the link may be updated when the email notifications are moved to Prod but once moved to Prod the links to tickets in the email notifications should point to PROD and not TEST.

382

OK

Sept 27 Release Testing: Email notifications should point customers to the new ITS web site instead of the old web site. Need to see when the ITS web site is going live and if it is going live before we release we should update the links in our email notifications to point to the new web site. Assigning to Chloe to research the website go live date and the links.

383

September 27 Release Testing: Email Notification 4 (Incident Resolved) needs one word updated in the body. Where it says "Click here to go your ticket" it should read "Click here to review your ticket". Just change "go" to "review".

384

Sept 27 Release Testing: When an Incident is put on hold the customer is getting BOTH email #2 (Incident on hold) and email #3 (Incident Updated). When an Incident is put on hold the customer should receive ONE email "Incident has been put on hold". They should not receive the Incident Updated (#3) email as well.

385

fixed to show only latest comment, w/o metadata or styling

Sept 27 Release Testing: Email Notification #2 and #3 should not have lines and date/time/updatedby stamp and should only contain the most recent comment update.

386

When creating a Request to share a new Template, the RITM screen requires that a Report be selected, in additon to the Template that has been selected. See RITM0017351, e.g.

387

blank assignment unit was present, so it was saving something; the correct groups don't carry over properly in update sets; this will be handled manually during deployment.

When creating a Request to share a Report, the Task was closed without filling out the required field for Assignment Group. See, e.g., SCTASK0017307 and 17308.

388

commented out apparently superfluous sc_req_item events that had been added by Fruition

When creating a Request to share a Report, I rejected the Request and received both the Rejected and Approved notifications. See RITM0017353 and attached screenshot.

390

fixed all matching notifications

In the email notification footers of new Incident notifications please change links from/to the following:
Change www.yale.edu/its to

Change www.yale.edu/its/servicenow to

391

(n/a)

couldn't

replicate,

confirmed

non-bug

w/

Dorothy

Requirement is that only those with the Knowledge Manager role can see the user comments. Currently not even the Knowledge Manager can see the user comments, they are blocked from everyone. Submitted by Dorothy Ortale.

392

(n/a)

this

appears

to

be

a

problem

w/

mailman,

not

SN

In email notification 1B the subject has too many spaces between 'Ticket Number:' and the Incident number. It looks like it's a tab and not a couple of spaces.

393

Request to ADD/Remove staff from SN Assignment Group the staff member variable being added or removed does not come over to the SCTASK

395

Request for ITS Support Resolved notification link, guidance incorrect

2012/09/23

-

1

Requirement

584

-

Knowledge:

Allow

all

ITIL

users

the

ability

to

create

a

new

KB

Submission.

• They

• should

• see

• the

• 'Submissions'

• section

• and

• nothing

• else

• under

• this

• menu

• (bw

• -

• assuming

• OOB

• link

• to

• r/o

• KB

• view

• is

• acceptable).

• There

• should

• be

• an

• item

• added

• to

• the

• Submissions

• section

• that

• says

• 'Create

• New

• Submission'.

• Clicking

• on

• this

• would

• create

• a

• new

• SUB

• ticket,

• not

• a

• KB

• ticket.

• There

• are

• manual

• steps

• that

• go

• with

• this

• (ensure

• knowledge

• role

• is

• not

• granted

• to

• SERVICE_Desk_Queue_MGR

• group)

2012/09/23

-

2

Requirement

588

-

When

a

KB

article

is

created

fill

the

'role'

field

by

default

with

the

'itil'

role.

• change

• default

• value

• in

• dictionary

• of

• kb_knowledge.roles

2012/09/23

-

3

Requirement

533

-

Knowledge:

Increase

automation

of

published

date

field

• published

• date

• should

• be

• blank,

• non-required,

• until

• the

• article

• is

• published.

• as

• an

• the

• article

• is

• put

• into

• published

• status,

• the

• published

• date

• field

• should

• be

• auto-filled

• with

• the

• date

• the

• article

• is

• put

• into

• published

• status.

• the

• published

• date

• should

• be

• a

• non-editable

• field;

• it

• should

• just

• be

• set

• when

• the

• workflow

• requires

• it.

• move

• the

• published

• date

• field

• down

• towards

• the

• bottom

• of

• the

• screen

2012/09/24

-

1

Requirement

585

-

Knowledge:

When

KB

Submissions

are

created

they

should

automatically

be

assigned

to

MGT

Knowledge

Management

queue.

• not

• sure

• what

• I

• was

• smoking

• when

• I

• did

• this,

• because

• it's

• very

• wrong.

2012/09/24

-

2

Requirement

387

-

Knowledge:

User

comments

should

not

be

shown

on

the

published

Knowledge

record.

• Only

• folks

• with

• the

• knowledge

• manager

• role

• should

• be

• able

• to

• see

• feedback

• left

• on

• the

• KB

• article.

2012/09/24

-

3

Requirement

660

-

Knowledge:

Information

from

the

Incident

(Text,

Submitted

By)

should

be

pulled

into

the

KB

Submission

when

it's

created

from

an

Incident.

2012/09/24

-

4

Requirement

661

-

Knowledge:

All

the

'Save

and

Exit'

button

to

the

Create

Article

knowledge

screen.

2012/09/24

-

5

Requirement

364

-

Incident:

Comments

should

only

be

required

if

state

is

changing

to

On

Hold

When

an

Incident

is

put

on

hold

the

'additional

comments'

field

is

required

to

let

the

customer

know

why

their

Incident

was

put

on

hold.

This

is

OK.

However

when

the

ticket

is

updated

with

ANY

update

when

the

Incident

is

on

hold

the

additional

comments

field

is

required

and

when

this

field

is

updated

it

sends

a

notification

to

the

client/contact.

Sometimes

the

tech

or

someone

else

needs

to

update

the

work

notes

or

change

a

categorization

or

assignee

and

the

client

should

not

receive

an

update.

This

'additional

comments'

field

needs

to

be

required

ONLY

when

the

ticket

is

placed

on

hold

and

not

for

subsequent

updates

afterwards.

• add

• a

• client

• script

• that

• only

• sets

• the

• field

• as

• mandatory

• when

• the

• incident

• state

• is

• changed

• deactivate

• the

• less

• flexible

• UI

• policy

• that

• previously

• made

• this

• field

• mandatory

2012/09/24

-

6

Requirement

516

-

Email

Notifications:

remove

mention

of

'additional

information'

from

incident

on-hold

email

notification.

• replace

• w/

• 'Your

• ticket

• has

• been

• placed

• on

• Hold.

• You

• can

• click

• on

• the

• following

• link

• to

• check

• the

• status

• of

• your

• ticket.'

• approved

• copy

• can

• be

• found

• in

• the

• QC

• requirements

2012/09/25

-

1

Requirement

481

-

Email

Notifications:

List

the

resolution

in

the

ticket

in

closure

email

notification

so

folks

know

how

the

issue

was

resolved.

• includes

• significant

• changes

• to

• text;

• approved

• copy

• found

• in

• QC

• requirements,

• used

• w/

• slight

• modifications

• to

• clarify

• instructions

• for

• end

• user.

• enable

• the

• Reopen

• Incident

• button,

• as

• implied

• by

• the

• supplied

• message

2012/09/25

-

2

Requirement

432

-

Email

Notifications:

Standardize

copy

&

fields

1)

On

all

email

notifications

add

a

link

to

the

ticket

referenced

in

the

notification.

2)

On

email

notifications

to

the

client

that

let

them

know

the

ticket

has

been

opened

include

the

name

of

the

person

who

opened

the

ticket.

If

no

person

opened

ticket

(e.g.

via

email

intake)

no

name

added,

just

include

the

service

desk

contact

information.

3)

On

any

follow

up

email

notification