Month: July 2019

I recently ran into a problem. I had a workflow that did a number of things and then had a wait condition that was supposed to wait for a variable to change to a specific value before creating another task and moving on.

I had created a business rule that changed the variable on the catalog task that the workflow was attached to.

I’d tested all of the components and they were working correctly, but the workflow was getting hung up on the wait condition, refusing to move forward even after the business rule had changed the value of the variable.

As it turns out, the problem is that workflows aren’t constantly looking to see if the wait conditions have been satisfied. Instead, you have to nudge the workflow into re-evaluating the condition so that it can see that it’s time to move on.

First you need to create a new Workflow() object.

var wkfw = new Workflow();

Then you need to call the runFlows method on the workflow object. As far as arguments, the first argument needs to be the GlideRecord object for the RITM of the workflow you want to nudge. The second argument should be ‘update’.

All told, you would expect to do something like this:

// Grab the RITM object
var gr = new GlideRecord(‘sc_req_item’);
gr.get(ritmSysID);

// Refresh the workflow attached to that RITM
var wkfw = new Workflow();
wkfw.runFlows(gr, ‘update’);

One of the things that I learned during the process of rolling out that translation project is that when you add a variable to a catalog item, ServiceNow doesn’t go back through and retroactively add the new variable to existing RITMS.

In hindsight, that makes a lot of sense. The new variable might be mandatory on new RITMS, so if you were to add it to old RITMS, you’d have to either gather that new information for all old RITMS relating to that catalog item (likely time intensive, and potentially impossible), or you’d risk some of the core logic falling over when it came across mandatory variables an a RITM that hadn’t ever been filled out.

Unfortunately, not operating with the benefit of hindsight, I initially had thought that the lack of a link on old RITMS to the variables I’d created meant that the new RITMS would likewise not have a link between the RITM and the variable until I populated the variable.

Since that wasn’t the case, I ended up having to re-tool a couple of aspects of the translation logic as it related to translating variables.

Now I know better.

In a past position, I went to the effort of hunting down and documenting the underlying tables that support catalog items, requests, request items, tasks, and the variables.

I’ve moved on from that position though, and no longer have access to those notes. As I started to re-pull that information, I found this graphic, which shows how that tables are related to each other.

I found it originally on this post, and it was originally created by Julian Hoch.

I thought I would pass it along in case any of my readers found themselves needing to know what tables to reference when coding against that area of ServiceNow.

In other news, the guided tour bug that I reached out to HI Support about has been turned into a problem so that they can get the right group working on resolving it.

 

A quick update on the guided tour bug that I reported a while ago. I’ve been back and forth with HI support several times, and during my last call with them we got them to the point of being able to re-create the bug on a consistent basis.

It appears that the bug (callouts not working on the submit button) only kicks in if you populate an intro and conclusion to the tour. It’s possible that just one of those two (intro & conclusion) is the issue. I didn’t test beyond that.

I found what feels like a bug, but which could just be me trying to use the system in a way that it wasn’t designed to be used.

If you go into a catalog UI policy, it gives you the option to change the catalog item that the UI policy applies to. I did an insert and stay on several UI policies, copying them from one catalog item to another catalog item that had the same variables.

I thought I was being clever and saving myself a bunch of time, but after doing that, none of the catalog UI policies (the UI actions) worked.

My best guess is that the variables on the two different catalog items had the same names, but different sys ID’s. So they look like the same variables, but aren’t actually the same variables. I haven’t had a chance to test that though so I’m not 100% sure that’s the cause.