Challenge: warn about Critical overload

How challenges work

1. Read the ticket. It is written like a story from a real project, with acceptance criteria that say exactly what must work. Your work note can be worded differently, but it must appear at exactly the moments the criteria describe.
2. Build it in your PDI. Keep this page open in one tab and your instance in another.
3. Stuck? Take a hint. Hints open one at a time, from a gentle nudge to almost the answer.
4. Still stuck? Open the full solution. It walks through every step, with the code.
5. Check your build and mark it done. Tick each criterion once you have tested it. Your progress is saved in this browser.

Before you start

This challenge uses everything from the Server Scripting module. If a hint mentions something unfamiliar, these lessons explain it:

• What is a Business Rule? and Types of Business Rules, for picking before, and why it needs no current.update().
• Conditions and changes, for changes to instead of is.
• Script Includes and GlideAggregate, for where the counting lives and how it counts.

A PDI’s demo data usually includes a few open Critical incidents, so the count is unlikely to be zero. To check the real number at any time, open Incident > Open and filter on Priority is 1 - Critical.

One thing about incidents trips everyone up the first time: on the standard incident form, Priority is read-only. It is worked out from Impact and Urgency, so to make an incident Critical, set both of them to 1 - High.

The challenge

ChallengeEasyAbout 25 min

Warn about Critical overload

STRY0010042

As a service desk manager, I want a work note added whenever an incident becomes 1 - Critical, saying how many other Critical incidents are already open, so that the team can see at a glance when we are overloaded and need to call in more people.

Acceptance criteria

1. When an incident's Priority changes to 1 - Critical, a work note is added saying how many other open Critical incidents there are.
2. The count includes only active incidents with Priority 1 - Critical, and never counts the incident itself.
3. Saving an incident that is already Critical, for example after changing only its short description, does not add another note.
4. Changing Priority to anything other than 1 - Critical adds no note.
5. The counting lives in a Script Include that uses GlideAggregate. The Business Rule only calls it.
6. The Business Rule never calls current.update().

Now build it in your PDI

Open your PDI in another tab and build it yourself. Stuck? Take a hint, one at a time.

Hint 1

Two questions decide the Business Rule. Which type lets you add a work note without saving the record a second time? And which condition fires only when the priority changes to Critical, rather than every time a Critical incident is saved?

Hint 2

Put the counting in a Script Include with one function that takes the sys_id of the incident to leave out. Inside it, use GlideAggregate on incident with addActiveQuery(), a query for priority 1, a query for sys_id not equal to that sys_id, and a COUNT aggregate.

Hint 3

Use a before Business Rule on Incident with the condition Priority changes to 1 - Critical. In its script, call your Script Include with current.getUniqueValue() and set current.work_notes to your message. A before rule saves the note together with the record, so no current.update() is needed.

Show the full solution

1. Create an update set

   In your PDI, open System Update Sets > Local Update Sets and select New. Name it GlideNest - CORE-2.6 - Warn about Critical overload, then select Submit and Make Current. Everything you build next is captured in it.

2. Create the Script Include

   Open System Definition > Script Includes and select New. Set Name to CriticalIncidentUtils and leave Glide AJAX enabled unticked, because only server code calls it. Replace the script with the code below. The function counts active Critical incidents with one GlideAggregate query, leaving out the incident whose sys_id it is given. Select Submit.

   var CriticalIncidentUtils = Class.create();
   CriticalIncidentUtils.prototype = {
       initialize: function() {},
   
       // How many active 1 - Critical incidents are open,
       // not counting the one with this sys_id.
       countOtherOpenCritical: function(excludeSysId) {
           var ga = new GlideAggregate('incident');
           ga.addActiveQuery();
           ga.addQuery('priority', 1);
           ga.addQuery('sys_id', '!=', excludeSysId);
           ga.addAggregate('COUNT');
           ga.query();
   
           if (ga.next()) {
               return parseInt(ga.getAggregate('COUNT'), 10);
           }
           return 0;
       },
   
       type: 'CriticalIncidentUtils'
   };

3. Create the Business Rule

   Open System Definition > Business Rules and select New. Set Name to Warn about Critical overload, Table to Incident [incident], and tick Advanced. On the When to run tab, set When to before, tick Insert and Update, and add the filter condition Priority changes to 1 - Critical.

4. Add the script

   On the Advanced tab, replace the script with the code below. It asks the Script Include for the count and writes the work note. Because this is a before rule, the note is saved together with the record, so there is no current.update(). Select Submit.

   (function executeRule(current, previous /*null when async*/) {
   
       var others = new CriticalIncidentUtils().countOtherOpenCritical(current.getUniqueValue());
   
       current.work_notes = 'Critical overload check: ' + others +
           ' other open Critical incident(s) right now.';
   
   })(current, previous);

5. Test every criterion

   Open an incident that is not Critical. Priority is worked out from Impact and Urgency, so set both to 1 - High and Save: a work note with the count appears in the activity. Change only the short description and save again: no new note. Set Impact back to 2 - Medium and save: no note. Finally, check the number against Incident > Open filtered on Priority 1 - Critical, minus the incident you are testing.

Import the solution into your PDI

The update set contains two records: the CriticalIncidentUtils Script Include and the Warn about Critical overload Business Rule, exactly as above.

If you already built your own, deactivate or delete it before importing. Otherwise two Business Rules run and every Critical incident gets two notes.

Download the solution update set

1. In your PDI, go to System Update Sets > Retrieved Update Sets.
2. Click the related link Import Update Set from XML and upload the file you downloaded.
3. Open the imported update set, click Preview Update Set, then Commit Update Set.
4. Open the finished page, then open it in UI Builder to see exactly how it is built.

Check your build

Test your page against each criterion, then tick it.

• When an incident's Priority changes to 1 - Critical, a work note is added saying how many other open Critical incidents there are.
• The count includes only active incidents with Priority 1 - Critical, and never counts the incident itself.
• Saving an incident that is already Critical, for example after changing only its short description, does not add another note.
• Changing Priority to anything other than 1 - Critical adds no note.
• The counting lives in a Script Include that uses GlideAggregate. The Business Rule only calls it.
• The Business Rule never calls current.update().

Mark as done

What you just practised

You chose a before Business Rule, so the work note is written onto the record while it is being saved and goes into the database together with it. No second save, and no current.update(), which would run every update rule on the incident again.

You used the condition changes to rather than is. “Priority is 1 - Critical” would add a note every time anyone saves a Critical incident, filling it with noise. “Changes to” fires only at the moment the priority becomes Critical, which is the only moment the ticket asks for.

You kept the logic in a Script Include, so the Business Rule stays a few lines long and the counting can be reused anywhere: another rule, a scheduled job or a UI action can call countOtherOpenCritical() too. And you counted with GlideAggregate, which asks the database for a single number instead of loading every Critical incident one by one with GlideRecord, the way you would on a real instance with thousands of records.

What’s next

You have finished the Server Scripting module. The next module, Client and Server, starts with Client Scripts: code that runs in the user’s browser, so a form can react the moment a field changes, before anything is saved.