Custom Drop down for NFAR resolution for every alert instance

[leahs]

Hello @naraink,

Reverting with feedback provided by our core team:

This is currently not possible. However, it will be presented internally for consideration in a future release.

Thanks very much for sharing with us!

Kind regards, 

Leah 

[naraink]

Thanks for your response, please note the context of the request is that both regulators and senior management are seeking deeper understanding why alerts are closed with no action required. By customising the alert closure options per alert, it provides improved alert closure categorisation that will be used to further enhance the management information statistics and allow Client to reduce false positives

[nfrishling]

Hi  Leah,

Narain and I work on the same team and just thought Id add my findings.

Ive noticed that adding some logic in dxATGetItemResolutionsDB to get resolutions from, for example, a configuration seems to work.

Sample configuration:

 

 

Sample code update:

 

 

dxATGetItemResolutionsDB:{[itemID;transition] / lookup transition info 
                              trns:.at.transitions[transition]; / lookup the resolutions for this queue (empty if queue isn't final) 
                              queue:trns[`to]; 
                              queueInfo:.at.queue[queue]; 
                              isFinal:queueInfo[`statetype]=`final; 
                              resolutions:`isDefault xdesc `name xasc select from .at.resolutions where queueName=queue, enabled; 
                              alertName:first exec alert from dxATItemCurrent where dItemID=first itemID; 
                              resolutionOverride:select from .uc.getActiveParamValue[`AT_RESOLUTION_ALERT;`] where ATName=trns[`actionName],queueName=queue,alertTypeName=alertName ,enable; : $[all(isFinal ;queueInfo`showResolution;count resolutionOverride) ; 
                              select name,displayName from resolutionOverride; isFinal & queueInfo`showResolution; 
                              select name, displayName from resolutions; 
                              ([]name:"s"$();displayName:()) ] }

 

 

 

Outcome in the dashboard for alert1 and alert2 respectively, while other alerts that are not configured have the same dropdown as before.

 

Exported activity log after submitting custom resolution

 

 

Note on the above when selecting multiple items to transition. Different alerts for  the same queue/actionTracker can be selected and  transitioned at once. In this event dxATGetItemResolutionsDB is passed the itemID associated with the first alert selected and will display the dropdown relevant to that specific alert.

 

In a similar manner Ive also managed to

• Get resolutions to appear on non-final states by adding a condition where isFinal and queueInfo`showResolution (appears that show resolution cannot be saved for queues which are not final) are not required to be true
  • Resolutions on non-final states appear to not show in the activity log on the alert due to having actionType =`transition dxATActivityLog. Updating this value in dxATGetItemHistoryDB to `resolution where a resolution is populated makes it appear in the UI. This was done to display the resolution for the earlier non final transition in the activity log export above.
• Have the transition from state to also be considered. E.g New ->InProgress to offer different resolutions compared to Referred-> InProgress

The above two related points are also something we are interested in for a different piece of work.

Could the above config override type of solution be ok until a change is released?

 

[leahs]

Hello all,

Thanks very much for presenting your findings.

After discussing, we are reverting with some feedback:

The latter solution presented by @nfrishling appears to be the most suitable approach and should work given the evidence provided – until this functionality is officially released by the KX core platform team. Based on the changes made, this solution in question seems solid.

One caveat to highlight is that that function may be updated by our core platform team in a future release and therefore, our advice would be to do a comparison on every occasion that you attempt an upgrade of your KX platform, until of course this functionality is added by the KX core team. This comparative check is encouraged in order to ensure that you don’t overwrite any critical additions to the function, whilst maintaining your custom code.

Thanks to @gdickson for analysing this thread and providing such feedback.

We hope this information helps.

Kind regards,

Leah