Adding Bulk Incident Acceptan Option

[AromalM]

Hi All,

I was exploring the option of adding an ‘Incident Accept’ button to the dropdown. The idea is that during an outage or major issue, users can simply check the corresponding box and select the ‘Accept’ option from the dropdown for quicker handling.

Before proceeding further, I would like to get your feedback on this approach and check if there are any objections or business rules that might prevent implementing this feature.

Please share your thoughts.

[Ankur Bawiskar · Accepted solution]

@AromalM 

That's fine, but what happens on Click of that Button from list.

Does it change the State field on INC?

There is nothing which stops you from adding that UI action to list view in Native

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Ankur Bawiskar · Accepted solution]

@AromalM 

something like this, but please enhance

function moveIncident() {

    var selectedRecords = g_list.getChecked().toString();
    // use GlideAjax here and pass these sysIds and then update the state

    var ga = new GlideAjax('checkRecords');
    ga.addParam('sysparm_name', "updateIncident");
    ga.addParam('sysparm_records', selectedRecords);
    ga.getXMLAnswer(function(answer) {
        if (answer == 'valid') {
           alert("Total incidents updated" + selectedRecords.split(',').length);
        }
    });
}

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Ankur Bawiskar · Accepted solution]

@AromalM 

something like this, but please enhance

function moveIncident() {

    var selectedRecords = g_list.getChecked().toString();
    // use GlideAjax here and pass these sysIds and then update the state

    var ga = new GlideAjax('checkRecords');
    ga.addParam('sysparm_name', "updateIncident");
    ga.addParam('sysparm_records', selectedRecords);
    ga.getXMLAnswer(function(answer) {
        if (answer == 'valid') {
           alert("Total incidents updated" + selectedRecords.split(',').length);
        }
    });
}

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Tanushree Maiti · Accepted solution]

Hi AromaIM,

 For me , "After selecting “Accept Incident”, the incident state should automatically update from ‘New’ to ‘In‑Progress’ " - its feasible and using UI action and its logic you can achieve it.

For this requirement "we can implement a pop‑up notification showing the total number of incidents included in the bulk acceptance action."  , its not that easy as Confirm() method /alert ( method which showing pop-up) stopped working after Xanadu/Yokohoma version.

So you need to achieve it via GlideModal popup with UI page which needs too much development effort.

[Ankur Bawiskar · Accepted solution]

@AromalM 

That's fine, but what happens on Click of that Button from list.

Does it change the State field on INC?

There is nothing which stops you from adding that UI action to list view in Native

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Dr Atul G- LNG]

Hi @AromalM 

Even though you’ve accepted the solution, I’d like to respond from a process perspective. I work on the platform and BPC side, and I don’t think it’s valid to ask for custom settings similar to what we have on the client side.

Moving the incident from one record to another triggers emails and affects SLAs, and you’re already using the out-of-the-box approach. Instead, why not link all child incidents to the parent incident, so that all updates and state transitions flow from the parent to the children automatically?

Also, when you adopt this approach, you need to update the same user and the same group if you want automation to work correctly. All SLAs will continue to function, and if you need to add future updates, it’s much better to use the parent incident.

While the proposed solution may be technically feasible, it introduces unnecessary technical debt by adding new custom workflows and configurations.