1. Contains search by default

One thing you will inevitably notice your ServiceNow administrator do when searching for something in ServiceNow is to type a * before the search keyword.

This is because ServiceNow will only search for records that start with your keywords but if you put a * in front of your search keyword, it will look for all records that contain the keyword, be it at the start, middle, or end. You can make the default search mode to be contains search so there is no need to type * as shown in Figure 11-1.

Figure 11-1. It is easier to fill forms in ServiceNow with contains search.

2. Personalized global search

The global search box in the top-right corner of every ServiceNow page (Figure 11-2) offers the quickest way to look things up in ServiceNow. But it shows search results from all the tickets in the instance, which if you are in a large organization, can be hundreds of thousands.

Figure 11-2. The global search box in the top-right corner searches all records in ServiceNow.

Most of the time however, you are looking for a ticket that you opened or for a ticket a colleague in your team referred you to, and are not interested in tickets logged on the other end of the world. So you will have to dig deeper and modify the search query to find what you were looking for.

You could however customize the default search results to be prefiltered for tickets assigned or opened by your team (Figure 11-3). That way, by default you get what you want most of the time from the first time you search, while for less frequent searches you can modify the search filters.

Figure 11-3. The default filters for global search can be made more local or personalized.

Note, if you have implemented a tickets confidentiality solution (Chapter 9) in such a way that other teams cannot even see the presence of confidential tickets, then you may not need to add filters because ServiceNow will then by default not show you tickets that you do not have access to.

3. Color-coded ticket numbers

The state of a ticket is essentially one of three: Open, on hold, or closed.

To quickly identify the state of a ticket in a list without reading the state field, you can color-code the background of the number field with a color to denote each state (Figure 11-4).

Figure 11-4. Green background color for the number field of a closed ticket, and amber for a ticket on hold.

A transparent background could mean that the ticket is open (either new or work in progress), amber that it is on hold, and green that it has been resolved (or closed).

4. Look up callers by staff ID

When receiving a phone call , the Servicedesk can ask callers for their staff ID and use it to immediately look them up directly in a new incident record (Figure 11-5). Once the caller is identified, the agent can preview recent tickets for the caller in ServiceNow or continue logging a new incident ticket.

Figure 11-5. Asking callers for their staff ID is often much easier than spelling their full name.

5. Info messages with hyperlink

Once a ticket is updated in ServiceNow it can take a few steps to get back to it again!

For practical convenience, whenever a ticket is submitted or updated you could show an overhead info message confirming the change that just took place and providing a hyperlink back to the ticket (Figure 11-6).

Figure 11-6. Information messages with hyperlinks that can take you back to the ticket or that you can use to copy the hyperlink to the ticket.

Such conveniences can be very useful for first-time users as well as advanced users operating under pressure.

6. International date format

Dates in ServiceNow are used to report on when a ticket was opened, last updated, or closed. Dates are also used in the Due date field if you set a deadline for a Task or Project.

ServiceNow allows each user to set their date format but as you can imagine most users will simply not do it. If you have users across the world, each will be used to a date format that is confusing to the other (dd-mm-yyyy in Europe and Asia and mm-dd-yyyy in America).

To elegantly circumvent this issue I recommend you set the default date format to the dd-mmm-yy format which is unequivocal on both sides of the Atlantic (Figure 11-7).

Figure 11-7. A ServiceNow opened field with the date in the dd-mmm-yy date format.

7. Rounded-up time fields

When scheduling the planned start and end dates of a change, you can go granular by the minute or round up to the earliest and latest 5-minutes interval as shown in Figure 11-8.

Figure 11-8. Planned end date is conveniently rounded up so that the change duration is a multiple of 5 minutes.

All changes’ scheduled durations will be in multiples of 5 minutes which will be easier to remember and will fit more nicely in calendars. This is especially so if you display change requests on a shared global calendar.

8. Outlook global changes calendar

If you find ServiceNow’s built-in Global changes calendar a bit clunky and you have your own Calendaring system (e.g., Outlook) you may create a subscribeable public calendar in Outlook that will show in real-time all scheduled Change requests in Outlook as shown in Figure 11-9.

Figure 11-9. Shared calendar in Outlook showing all changes planned in ServiceNow.

ServiceNow by default sends out calendar invites for Change requests to the person to whom the Change is assigned to. You can set it to also send the invite to your public calendar so that the changes are immediately visible on the shared calendar as well.

9. Read-only open details

By default, ServiceNow automatically sets the fields that capture who opened the ticket and the time when it was opened. Those fields are set as read-only so that they cannot be changed.

Some teams will argue that they need to log tickets with back dates, for example setting the opened date to when exactly the incident was experienced instead of when the incident ticket was logged. But if you enable ITIL users to set the opened date be ready to find tickets logged with future dates, unless you customize that the date cannot be set past the current time.

Also, the Caller field in ServiceNow is by default changeable by both ITIL users and the caller itself do you want to keep it this way?

10. Related records header

When setting the caller for a new Incident record, ServiceNow also allows the Servicedesk agent to quickly preview recent tickets for the caller to know if there is already a ticket for the caller’s issue or if she had the same issue recently.

But the way the caller tickets are shown and the urgency on the phone may make it somewhat difficult to look through those recent tickets. You can customize what is shown as you deem suitable for example see the table header in Figure 11-10.

Figure 11-10. Adding the Comments and work notes field to the list view allows you to hover over the field and quickly preview the latest messages on the ticket.

11. Buttons to change ticket state

A ticket’s state is by default controlled through a drop-down field which ITIL users are expected to set as they update tickets. But there is also a Resolve button, which sets the ticket state to Resolved straightaway.

What will often happen however is that when updating a ticket many users may neglect setting the ticket state, for example, not changing it to or from On hold, although this is important for the calculations of the SLA and for the notification sent to the caller (see Chapter 5).

Just like with the Resolve button, you can have a Hold button that when clicked will save the ticket in the On hold status (Figure 11-11). If the button is clicked without writing a Comment to the caller you may also prompt the user to first type an explanation to the caller.

Figure 11-11. By clicking the Hold button the ticket will be saved in the On hold state.

Once a ticket is already On hold, to update the ticket you should hide the Update button and instead require the user to make an explicit choice of how to update the ticket (Figure 11-12):

• Unhold: Updates the ticket and resets the ticket state to Work in progress. SLA clocks may resume.

• Hold: Updates the ticket as still pending caller input. A message will be sent to the caller with the update, soliciting urgent update.

• Resolve: Updates the ticket as resolved.

Figure 11-12. Unhold updates the ticket and resets the state to Work in progress. Hold updates the ticket but keeps it on hold.

What if you want to cancel a ticket?

You could select the Cancel state and right-click on the ticket header and click on Save. Like Update, Save does not affect the state.

But you could also eliminate the need to fiddle with the state field and introduce a Cancel right-click menu item as shown below in Figure 11-13.

Figure 11-13. The context menu accessible by right-clicking a ticket header provides additional options to operate on a ticket.

12. Un-hold tickets automatically

When a ticket is put on hold it makes sense for the SLA to also be paused while awaiting customer updates.

But as soon as a new comment is received on the ticket via email or through the self-service portal the ticket should automatically be put back in the Work in progress state and the SLA clock should resume. Otherwise would defeat the purpose of the SLA.

13. Close on-hold tickets

It happens that sometimes tickets put On hold are ignored by the caller and never receive an update again. For this, you can set up ServiceNow to automatically close tickets on hold that have not received an update in more than seven days (or any number of days you deem appropriate).

If you introduce this behavior, remember to make it obvious to the users. When viewing a ticket currently on hold, show an information bar message informing that the ticket is on hold and after how many more days will it be automatically closed (Figure 11-14).

Figure 11-14. Notice shown when viewing on-hold tickets, informing that the ticket will soon be automatically closed if not updated.

14. Replies to closed tickets

By default, email replies to a closed ticket do not reopen it and thus don’t restart the SLA.

To make sure the replies do not go unnoticed you can list those tickets in a special list on the home page of your Servicedesk who will then decide whether to re-open the tickets or just note the provided feedback. For details about handling email replies to closed ticket notifications, see Chapter 4.

15. Re-opened incidents

What should happen when a ticket is intentionally re-opened by the caller? You may set tickets to be automatically re-assigned to the Servicedesk team to troubleshoot.

If the ticket was previously assigned to a person in another team chances are that she may not be available on shift to pick up the ticket again, and so the ticket may unnecessarily go neglected for a while. How you configure the re-open workflow depends on the nature of your support organization and the urgency of tickets.

16. Priority and SLA setting

By default in ServiceNow users do not set a ticket’s priority directly but the priority is computed based on low-medium-high settings of Impact and Urgency fields, while the caller can set the Urgency of the ticket.

At Al Jazeera we have tied SLAs to the ticket’s priority and also made it more straightforward to set the priority. The default priority of a received incident via email or self-service is Medium (P2) with an SLA of 10 hours as shown below in Figure 11-15.

Figure 11-15. You can make it mandatory for ITIL users to explicitly set the ticket’s priority when logging the ticket.

ITIL users can freely change the priority of the ticket but to do so they also need to write an internal work note in the ticket explaining their reasoning. Also, callers are not given information about the ticket priority or urgency.

17. SLA reminders gauge

ServiceNow comes pre-configured to send two email notifications for SLAs:

1. One email is sent to the assignee of the ticket to warn when the SLA on the ticket is about to breach.

2. If the SLA is breached however, the notification is sent to the manager of the assignee.

And if the ticket is not assigned to anyone, no email notification is sent out.

Especially at the beginning, users and management will be excited about those notifications and may require the configuration of more SLA alerts (e.g., alert when the ticket SLA reaches 50%), send an email notification to the whole team, etc.

In addition or alternatively to SLA notifications you can create a home page gauge that shows the number of open tickets with active SLAs due to breach within 10 hours or already breached.

As shown in Figure 11-16 this will give the team a lot more visibility about tickets before they breach and hopefully enable them to re-negotiate priorities and eventually meet more SLAs.

Figure 11-16. Dial to monitor the number of team tickets with running SLAs soon to breach.

As with other ServiceNow gauges clicking on the gauge will list for you the tickets in question as shown in Figure 11-17 so you can drill in and take action.

Figure 11-17. Clicking on the SLA gauge you can drill into the tickets.

Alternatively you could show an SLA progress bar as in Figure 11-18.

Figure 11-18. SLA progress bar

There is also a home page in ServiceNow dedicated to SLA reports (shown in Figure 11-19) if you want to get a more detailed view of the SLAs for your teams as well as all other SLAs tracked in the instance.

Figure 11-19. Out-of-box home page dedicated to SLAs.

18. Assignment based on email address or location

You can automatically route incoming emails directly to certain assignment groups based on the email address that they were sent to.

But if the support request was sent to the generic support email address, you could assign the ticket based on the sender’s location.

The workflow to assign an incoming new incident could be the following:

• If the incident ticket was auto-created from email then assign the ticket to the team registered to be assigned tickets sent to the addressed email, if any.

• If the location of the user is known or another location for the incident has been set then the ticket is automatically assigned to the team registered to be assigned tickets for that location.

• If the ticket could not be assigned to any group it should be assigned to a specific team you set as a catchall fallback option.

For more on setting user locations based on their OU in Active Directory, refer to Chapter 3.

19. Assignment based on Configuration item

Since ServiceNow is not just for the Servicedesk many tickets ought to be assigned to other teams.

One mechanism to determine to whom the ticket should be assigned is by setting the Support group field in Configuration items (CIs).

Based on the selected Configuration item of the ticket the Assignment group is automatically populated with the Support group of the selected CI, if any is set (see Figure 11-20).

Figure 11-20. The assignment group can be automatically set based on the Configuration Item selected.

20. Discard unregistered emails

Because it is easy to redirect emails to your ServiceNow instance some teams may set up automated redirects to ServiceNow without agreeing on who should handle those income tickets and how they should be handled. Many of those may even be automated alerts from systems that they manage.

Our ServiceNow instance at Al Jazeera regularly receives tons of internal emails such as these.

By default ServiceNow would process any incoming email and since unrelated to any existing ticket, open a new ticket for each new email. This will flood the Servicedesk who puzzled and frustrated will not know what to do with the incoming alerts or who to assign them to.

You can avoid this problem by requiring that ServiceNow only process emails sent to recipients it is configured to receive emails from and for which you have configured an assignment group.

This way, even when someone redirects alerts to be automatically sent to ServiceNow nothing will happen on the tickets side until you explicitly configure ServiceNow to accept those emails and auto- assign them to a particular team .

21. Re-assignment pop-up

When tickets are assigned between teams or even team members, teams and people on the receiving end of the ticket may be confused as to why the ticket has been dumped onto them and may re-assign it back or ignore it for a while.

Especially when tickets are escalated to tier 3 teams, the receiver will want to see that the Servicedesk agent assigning a ticket made an effort to troubleshoot the issue first and collected some basic details that will help in the resolution (steps to reproduce, screenshots, MAC address, etc.).

In order to encourage such hand-over notes when reassigning a ticket, you can show a pop-up (Figure 11-21) every time a ticket is set to be reassigned and no internal work note has been typed.

Figure 11-21. Pop-up shown when a ticket is re-assigned to another person or team without leaving a work note.

At this point the agent will be reminded about the importance of leaving a note or two to the receiving colleagues .

Typing a work note does not need to be mandatory as it may sometimes be obvious why the ticket is being assigned. The pop-up as a reminder should be enough and conducive to good practice.

22. Closing unassigned tickets

It can happen that for one reason or another, many tickets are closed without a name set in the Assigned to field.

If you want to report on the number of tickets assigned to each team member, you can make the Assigned to field mandatory when closing the ticket or just show a pop-up prompting the ITIL user closing the ticket to set the Assigned to field, as shown in Figure 11-22.

Figure 11-22. Pop-up prompt shown to ITIL users closing a ticket that is not assigned to anyone.

23. Track participation

When you first introduce ServiceNow in your organization people will wonder which metrics will be used to measure teams’ and individuals’ performance. Should management report on the number of tickets assigned to individuals and teams, the number of tickets closed, opened, or what?

Some teams may also not be used to the concept of assigning ownership for the ticket to an individual person and may ask about the ability to count the participation of more than one person in a ticket.

In Private tasks created from the Visual task board ServiceNow now offers the ability to set additional assignees (Figure 11-23). You may customize and introduce similar behavior to incident tickets or keep it to one primary assignee per ticket and instead track participations from others as described below.

Figure 11-23. In Private tasks ServiceNow introduced the concept of Additional assignees.

You may introduce a participation metric that keeps track of the number of tickets that an individual participated in. So in addition to the standard reporting metrics you can also report on tickets the user was not assigned to but collaborated in.

How you define participation depends on your circumstance. At Al Jazeera we consider someone to have participated in a ticket if they have left a work note or comment in the ticket, encouraging communication and making sure the contribution is actually felt and received by those working on the ticket.

24. Assignment group based on Assigned to

ServiceNow allows you to assign tickets directly to a particular person without assigning the ticket to a group (Figure 11-24). This may not fit the process by which other teams handle their collective workloads and may lead to disputes or to some tickets simply going unnoticed for a while.

Figure 11-24. Tickets in ServiceNow can be assigned to an individual without also assigning it to the group that she belongs to.

If this is an issue for you, make setting the Assignment group mandatory once the Assigned to is set.

More conveniently, you can have the Assignment group of the ticket be automatically populated with the assignee’s primary group (see Primary Group feature below, under Users and LDAP settings).

25. Parent assignment groups

If you have a lot of teams in ServiceNow, chances are that you will introduce some hierarchy to nest related groups (Figure 11-25). This will help new Servicedesk agents navigate through groups based on some logical grouping of teams (e.g., by location, or by function).

Figure 11-25. Related teams can be nested under Container groups for ease of navigation.

The problem with nested groups is that tickets could now be assigned to parent groups, and go unnoticed for a while because all teams are focused on the tickets assigned to their team and have enough.

Ideally, they would consider the parent group their team and also pick up tickets from there, but if that is impractical you could have ServiceNow forbid the assignment to parent groups. So tickets could only be assigned to child groups but not their parents .

Also refer to Chapter 3 for granting consistent access rights through parent groups so that access rights automatically cascade to the groups under them.

26. User communication and internal tabs

As discussed in Chapter 11, for every ticket ServiceNow tracks two communication threads: One for the messages exchanged with the end user, and one for those exchanged internally between resolver teams and perhaps vendors.

For compactness ServiceNow has recently combined the two threads and text boxes into one single text box and added a checkbox to determine if what you type should be posted as a comment or as an internal work note.

If users find this confusing and start mixing up messages by posting internal notes to end users, you can split the two threads into two separate tabs as shown below in Figure 11-26.

Figure 11-26. Separating the Comments user communication thread from the internal Work notes thread into two distinct tabs.

26. Vendor ticket number

Some issues require consultation with external vendors and partners such as with ServiceNow HI.

As in the case with getting support from ServiceNow if you cannot get vendors to use your instance you may still need a way to indicate that the ticket in your instance is related to a ticket somewhere else. This is to be used for hand-over or future reference.

You could invite people to simply note vendor ticket numbers in the work notes, or add a Vendor ticket number field dedicated to storing such information.

For letting some suppliers and partners collaborate on tickets directly in your instance, see Chapter 3 for vendors access and Chapter 9 for controlling tickets confidentiality.

27. Primary group

In the assignment section earlier, I described how you can have the assignment group of a ticket automatically populated once the Assigned to field is set based on the assignee’s primary group .

For this to work, you need to add a Primary group field to each user profile in ServiceNow and have it automatically default to the smallest group the person is a member of, or set manually from the user profile.

When collecting approvals, you could take the group manager of the Primary group of the user to be the section head.

Finally, some ITIL users may be part of several teams that they work with, or supervise, on different days and may require seeing only a team’s particular tickets queue on particular days.

You could build custom home pages for them, or have a home page that shows your primary group’s tickets. With the latter, they can change their primary group and only see the tickets for the group they want.

28. Functional accounts

When we first went live with ServiceNow we had set up the Active Directory integration to sync user profiles with the Users OU in Active Directory.

Where all your user profiles reside in your directory depends on your specific setup but you may need to log tickets for functional accounts such as [email protected]. These groups may be in a separate OU from your main users.

29. Email required for sync

In a dynamic organization user profiles may be in flux with new freelancers joining and leaving, and changing profile details. Your directory may also store temporary or phantom accounts used for testing or other purposes.

To ensure your users’ details in ServiceNow are as clean as possible I recommend that you only import user profiles that have a registered email address, assuming every staff member has an email address. Otherwise if you log a ticket for callers that have no email address associated, they are not going to receive any email notifications about their ticket.

30. Unique user attributes

To ensure duplicate accounts are not created in ServiceNow or that ticket updates are sent to the wrong person, ensure that no two users have the same:

Full name (a.k.a. display name)

Email address

User ID

Staff ID

For uniquely identifying users and matching them between your directory servers and ServiceNow , it would be better if you rely on an immutable ID provided by your directory server for each user profile.

Microsoft’s Active Directory assigns each user a unique identifier called ObjectSID (and there is also another globally unique identifier called objectGUID). Never changing, this field is the best to identify and sync users.

31. Location in tickets

Every ServiceNow ticket has a location field that is by default hidden from the incident form.

If your callers report incidents from different locations, or location is an important attribute of how you deal and route incidents then show the location field in incident forms, as in Figure 11-27.

Figure 11-27. The default incident form in ServiceNow does not show a location field. But if you add the Location field, ServiceNow will conveniently prepopulate it for you based on the caller’s location (if known).

Locations can be imported from your organization’s directory servers together with user or department details. You can also define or add locations in ServiceNow.

32. Delete role

In ServiceNow access to delete records is constrained to those with the ITIL-admin role while to delete Assets you need the SAM access role.

You may however further restrict the deletion of records only allowing admins to do so, or those with a new CanDelete access role that you selectively grant to certain people only.

33. Access to add vendors

As with access to delete records , in ServiceNow people with the user_admin role can add, modify, or delete users or companies’ records.

You may also want to have a new special role that only allows managing companies’ records (used for tracking contracts and assets by vendors) but not users. This could then be safely used by your contracts administrators and asset custodians.

34. User details in preview window

For every Incident caller ServiceNow provides a convenience preview window to quickly see more details about the Caller (Figure 11-28).

Figure 11-28. You can choose which user details are shown in the Caller preview window of Incident tickets.

Imagine the Servicedesk agent listening to the caller on the phone and glancing over the preview window on the screen and pick what user details you imagine she will want see in the preview window (the more fields you put, the more likely that she will not see them).

The details you set to show in the preview window will be the same shown also in Request tickets for the Requester and wherever else user details are looked up.

If ServiceNow system administrators (or user_admins) occasionally need to see other fields as well such as those related to the LDAP integration then add those to the view but with security constraints that make them visible only to users with the admin or user_admin role. For more details about access roles see Chapter 3.

35. Request form and communication

When the Servicedesk (or another fulfillment team) is assigned a Catalog task they will see whom the request is for and the short description of the Task (Figure 11-29).

Figure 11-29. Catalog task for a Request.

In order to view more details about what is requested, one would have to abandon the task and navigate to the Requested item (RITM) record. There you can see the form as it was submitted. The same goes for viewing the comments exchanged with the requester; You would have to navigate to the RITM or the Request (REQ) record.

Alternatively you could make those directly visible in the Catalog task under a Request Form tab and a User communication tab as show in Figures 11-30 and 11-31.

Figure 11-30. In a Catalog task you can show the entire form submitted in a tab.

Figure 11-31. Catalog tasks can be configured to show directly the Request’s comments rather than have a separate User communication channel of its own. You can have the Request’s comments conveniently shown in the User communication tab of the Catalog task.

36. Request tickets descriptions

When a new incident is received via email the subject line is by default set as the Incident’s short description.

In the case of Requests submitted by filling an online form there is not a Subject field and thus the Short description is often composed from the name of the form submitted. For example, if I submit a request filling the Remote Access form the short description of the Request will be:

Remote Access for Gabriele Kahlout

Unless the workflow specifies otherwise the short description of the fulfillment Catalog task generated for the request could also be:

Remote Access – Gabriele Kahlout (REQ0041147)

This is all nice and clear for this request. But sometimes the request does not have a dedicated form, for example, for the installation of a special software and so the Short descriptions would be set as:

Other software for Gabriele Kahlout

Others – Gabriele Kahlout (REQ0041177)

Sifting through ticket lists (or emails) with generic descriptions such as those is not the best.

To get a more descriptive description you can let the person changing the Short description of a Task associated with the Request to also change the Request’s description at once.

So in the above example the descriptions would be more descriptively described as follows:

Upgrade Balsamiq Mockups for Gabriele Kahlout

When you change a TASK, RITM, or REQ’s short description you get a pop-up prompt (Figure 11-32) that asks you:

Figure 11-32. Example pop-up displayed when changing the short description of a Catalog Task.

Did you want to rename the REQ and all of its child tickets?

• Yes, change them all.

• No, change just this TASK.

You could alternatively remediate the problem of generic descriptions by either adding a Request short description field in the forms so that the requester could fill it, or by seeking to create a Catalog form for each possibly requestable item.

But the more forms you show the user, the more difficult it will be for the requester to find the one needed. The same goes for fields in the form; the more I have to fill, the more daunting the task .

37. Wait for new ad-hoc Task

Sometimes a request will be more involving to fulfill than defined in the default Workflow.

For this you can give fulfillment teams the flexibility to list new ad-hoc Catalog tasks under the Request so that the Request is not automatically closed as soon as the Tasks generated by the Workflow are complete. The Workflow will also wait for all open Tasks associated with the Request.

You may make this more flexible by allowing any ticket (Catalog task or Change) to be associated with a Request, so that you do not have to create a new Task just to hold the Workflow if a ticket already exists.

Figure 11-33. You can specify In the Workflow that governs Request fulfillment in your instance not to close the Request until all tasks associated with the request have also been closed.

38. Log to-do Tasks

In addition to Incident tickets and full-fledged Requests teams often have other Tasks that they could track in ServiceNow.

Visual task boards in ServiceNow allow you to create Private tasks which you can also share with other people (so they are not necessarily private). As ServiceNow Employee Molly Clark described them¹:

“Private tasks are not really private (so maybe not the greatest name!). They can still be viewed and reported on like other tasks. They are just intended to be a very basic task to capture someone’s other “work” that often doesn’t have a particular requester, may not need to be assigned, probably doesn’t need SLAs, etc, etc. This is often someone’s general “to do” list.”

Alternatively you can also use the familiar Catalog tasks as stand-alone Tasks that behave just like other Catalog tasks but without association to a Request or Workflow.

39. Reminder Task for return dates

Many requests are temporary , for example a temporary laptop that is required only for a day or a week. For such requests you can have ServiceNow create a new reminder Task for the Servicedesk to follow up on the return of the item, as shown in Figure 11-34.

Figure 11-34. On the home page you can show a list of reminders due on the day for the team to remember and process.

40. No going back on approved

Once a Catalog request or a Change Request is approved the Workflow of the request will move forward. Yet, the approver could still go back and reject the Approval request again even though the request is already approved and in the fulfillment stage. Leaving such an option open to approvers can be a potential source of disputes and confusion.

To avoid it, set approvals as final. Once an Approval request is approved the approval cannot be renegaded. The approver can still request to cancel or alter the request, but this will trigger the right set of actions and expectations.

Figure 11-35. Even though a request may be approved and moved into fulfillment approvers could potentially go back and renegade their approval. This will trigger an email notification to the requester, but the workflow will have already passed the approval stage .

41. Consistent workflows

The Request Workflow applies to all received Requests in ServiceNow ensuring consistency for all Requests. However after the Request workflow, the Requested item workflow will kick-in and this can be different for each requestable item.

But chances are that there will be a lot of similarity between most, if not all of your items’ approval and fulfillment Workflows.

As such, strive to re-use the same Workflows as much as possible to ensure a consistent user experience with Requests on the portal and so that bug fixes and improvements apply for all Requests.

42. Cannot reopen requests

Unlike for incidents if the user replies to a closed Request there will be no option to re-open the Request. You can however have a new Incident ticket linked to the Request.