When RITM gets cancelled on Portal, REQ is not getting updated with correct request state of "Closed Cancelled"

[mkader]

Hello,

I am trying to fix a problem a user is currently having but am unable to figure out the issue. When I change the state of a RITM to "Closed Complete", the REQ automatically gets updated to "Closed Complete". When I try to cancel a RITM on the Portal, the REQ state does not change and stays in the "Approved" request state. There is an OOB BR that handles the REQ when the RITM's status gets modified "Close Parent if Required". How can I modify the OOB BR to change the state of the REQ to match the RITM if the RITM been cancelled?

Thanks!

[Allen Andreas]

Hi,

I wouldn't alter or mess with the OOB workflow, especially this one.

I would recommend just simply doing this; either using it as an example...or...create a copy: context menu > Copy.

That way you get an exact copy of it all, then you can alter everything, then just remember to assign this new workflow to the relevant record.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[mkader]

@Allen A - I did a little more digging, and this is happening on a custom workflow. My solution to fix this was to add a Set Value and an If condition to the workflow if state is Cancelled.

My only problem now is that the REQ is updating with the incorrect state. Closed Incomplete. I think this is happening with the OOB BR. Going back to the BR, how can I modify it so that the state is Closed Cancelled?

[Allen Andreas]

Also, if you don't mind...please ensure you mark any other reply of mine above as Helpful, if it was.

You'd need to edit that....and do something like:

closeParentIfRequired();

function closeParentIfRequired() {

    // check to see if any of our peers are currently *not* closed
    var gr = new GlideRecord('sc_req_item');
    gr.addQuery('request', current.request);
    gr.addQuery('stage', '!=', 'complete');
    gr.addQuery('stage', '!=', 'closed_skipped');
    gr.addQuery('stage', '!=', 'closed_incomplete');
    gr.addQuery('stage', '!=', 'Request Cancelled');
    gr.query();
    if (!gr.next()) {
        // no peer task is currently open
        gr.initialize();
        gr.addQuery('request', current.request);
        gr.query();
        var ritmCount = gr.getRowCount();
        var stage = 'closed_complete';
        var incomplete = 0;
        var skipped = 0;
        var cancelled = 0;
        while (gr.next()) {
            if (gr.getValue('stage') == 'closed_incomplete') {
                stage = gr.getValue('stage');
                incomplete++;
                break;
            } else if (gr.getValue('stage') == 'Request Cancelled') {
                cancelled++;
            } else if (gr.getValue('stage') == 'closed_skipped') {
                skipped++;
            }
        }
        var sc_request = new GlideRecord('sc_request');
        sc_request.addQuery('sys_id', current.request);
        sc_request.query();
        sc_request.next();
        gs.debug("SC_REQUEST.STAGE = " + sc_request.stage + " INDEX = " + sc_request.stage.toString().indexOf('closed'));
        if (sc_request.stage.toString().indexOf('closed') == -1) {
            if (incomplete)
                stage = 'closed_incomplete';
            if (skipped == ritmCount)
                stage = 'closed_skipped';
            if (cancelled == ritmCount)
                stage = 'Request Cancelled';
            sc_request.stage = stage;
            sc_request.comments.setJournalEntry("Request Automatically Closed as all Line Items were complete");
            sc_request.update();
        }
    }
}

So I haven't tested that, but that should query through all RITMs associated with that Request and if they are all cancelled...then the Request will be Request Cancelled. So in your workflow...you'd just want to ensure that your cancellation line...gets associated with the stage: Request Cancelled. Then this BR will take care of the REQ.

Please mark reply as Helpful/Correct, if applicable.

[mkader · Accepted solution]

I was able to figure out what was going on. I soon found out that we did not want to modify the OOB functionality of the BR's or workflows, so I modified our custom workflow. The code you provided fixed the issue with the addition of modifying another OOB BR on the request table. THanks!

[Allen Andreas]

Hi,

That's great. If you don't mind...please mark my reply as Correct (the one with the code you used) and please also go through this thread and mark any other reply as Helpful, if it was.

There was a lot of work done on this thread.

Thank you!