cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamic alert assignee dropdown selection

nfrishling
New Contributor II

Hi all,

I'm looking to 

  •  enable assignment of individual users rather than group during transitions in alert workflow.
  • run some validation on selected users or filter available users in drop down by checking alert details. E.g the user in some cases must be different to the user the alert is currently assigned to, ensure that the assignee cannot be the employee that's activity has generated the alert by checking payload details against user drop down details
  • filter available assignee list based on transition/user group such that for a given transition only members of a particular user group show up

 

I can see that for the first point users appear on the dropdown list as long as they are part of a group that has access to the action tracker on top of being members of the group ActionTrackerUsers and that dxATGetFilterAssignees which appears to drive this is only passed the logged in user, so no alert information.
 
However I can't see a way to refine the available lists beyond that. 
 
Does anyone have any idea how this might be achieved?
 
2 ACCEPTED SOLUTIONS

sbruce1
New Contributor

Hi Nina,

Hopefully the following answers your questions:

  1. You're right on the money with individuals being accessible from the dropdown after they've been added to the entitlements of the action tracker and are part of the ActionTrackerUsers. There is another analytic that drives this dropdown called dxATGetUsersForItem which queries either the AT or HDB, running the analytic dxATGetUsersForItemDBWe can add logic to this analytic to filter the list of individual users further.
  2. The dxATGetUsersForItemDB analytic has the itemID as an argument, so information about the alert payload can be interpreted. Hence we can add a simple except statement at the end to remove the sender/recipient from the dropdown.
  3. This issue is slightly more difficult than just modifying the dxATGetUsersForItemDB analytic, as the dxATItemCurrent table doesn't contain information about the transition. However, it does contain information about the queue, so you could filter by the entitlements regarding a queue using the permissions framework. Another solution if filtering on the queue entitlements isn't a suitable alternative, is adjusting the logic in the transition action analytic (screenshot provided). Since this analytic is executed upon transitioning, it will contain more information about which queue it's moving to. So you may be able to reissue the alert if the user isn't entitled to both queues. 

Here's some code that with a bit of adjusting should solve your second point, and implements the first solution for your third point (although commented out). As for your first point of further refining the available list, since I'm not sure what the further refinements will be based on I haven't included code for it. However this analytic would be the place you put in those further refinements.

dxATGetUsersForItemDB:{[itemID;dt]
  isHDB:not null dt;
  itemID:"j"$itemID;

  alert:$[isHDB;
    value last select from dxATItemCurrent where date=dt, dItemID=itemID;
    last select from dxATItemCurrent where dItemID=itemID
  ];

  AT:alert`actionName;
  ATQ:alert`queue;

  // POINT 2
  // Error trapped as keys for sender/receiver may differ, also this analytic is used in the financial AT  
  users_to_exclude:$[all null ue:raze alert[`data]`sender`receiver;`;ue];
  // Get users permissioned on the action tracker
  permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[AT; `actiontracker]; `select];
  // POINT 3
  // Get users permissioned for the current queue
  //permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[ATQ; `actionqueue]; `select];  
  :permissioned_users except users_to_exclude
 }

 Please let me know if you have any follow up questions to this.

Regards,

Sam B

View solution in original post

Hi Nina, 

Regarding your first point, I think it would be possible, however there are some problems you may need to consider. Revisiting the dxATGetUsersForItemDB analytic which drives the elements of the dropdown, it would be possible to do a lookup based on a config that links the username to display name and return the display name for the dropdown. Something like this:

dxATGetUsersForItemDB:{[itemID;dt]
  isHDB:not null dt;
  itemID:"j"$itemID;

  alert:$[isHDB;
    value last select from dxATItemCurrent where date=dt, dItemID=itemID;
    last select from dxATItemCurrent where dItemID=itemID
  ];

  AT:alert`actionName;
  ATQ:alert`queue;

  // POINT 2
  // Error trapped as keys for sender/receiver may differ, also this analytic is used in the financial AT  
  users_to_exclude:$[all null ue:raze alert[`data]`sender`receiver;`;ue];
  // Get users permissioned on the action tracker
  permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[AT; `actiontracker]; `select];
  // POINT 3
  // Get users permissioned for the current queue
  //permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[ATQ; `actionqueue]; `select];  
  permissioned_users:permissioned_users except users_to_exclude;
  username_displayName:.uc.getActiveParamValue[`USERNAME_DISPLAYNAME;`];
  :raze exec displayName from username_displayName where like[username;]each permissioned_users
 }

You would need to consider that upon selecting this from the dropdown, the logic that follows is expecting a username. So you would have to map back to the username after the dropdown is selected in one of  (if not all) the dxATTransition* analytics - and potentially more. 

Regarding your next point I'm not sure if there is a way to disable the assign to dropdowns and retain the commenting. I'll look into this further and reach out internally. A possible solution in the interim could be to create groups for the transition endpoints. For example, create a group called Escalated for users who are able to transition the alert from the Escalated queue, and do the same for Closed etc. Then have these groups available in the dropdown, so that a user could simply assign the problem to the group corresponding to the transition's endpoint. 

Alternatively, the option of configuring the "transition analytic to automatically reassign this item to a group or user in the correct group in the event that a user has made an invalid selection from the dropdown" does seem to be a good solution still, in the absence of being able to disable the dropdown while maintaining the comments.

Regards, 
Sam B

View solution in original post

5 REPLIES 5

davidcrossey
Moderator Moderator
Moderator

Hi Nina,

Welcome to the KX Community 👋🏻

Interesting query! As far as I'm aware there isn't that level of filtering out of the box, but I'm keen to see if others have come up with solutions for your use case.

Best regards,

David

David

nfrishling
New Contributor II

Thanks David!

So am I 🙂

sbruce1
New Contributor

Hi Nina,

Hopefully the following answers your questions:

  1. You're right on the money with individuals being accessible from the dropdown after they've been added to the entitlements of the action tracker and are part of the ActionTrackerUsers. There is another analytic that drives this dropdown called dxATGetUsersForItem which queries either the AT or HDB, running the analytic dxATGetUsersForItemDBWe can add logic to this analytic to filter the list of individual users further.
  2. The dxATGetUsersForItemDB analytic has the itemID as an argument, so information about the alert payload can be interpreted. Hence we can add a simple except statement at the end to remove the sender/recipient from the dropdown.
  3. This issue is slightly more difficult than just modifying the dxATGetUsersForItemDB analytic, as the dxATItemCurrent table doesn't contain information about the transition. However, it does contain information about the queue, so you could filter by the entitlements regarding a queue using the permissions framework. Another solution if filtering on the queue entitlements isn't a suitable alternative, is adjusting the logic in the transition action analytic (screenshot provided). Since this analytic is executed upon transitioning, it will contain more information about which queue it's moving to. So you may be able to reissue the alert if the user isn't entitled to both queues. 

Here's some code that with a bit of adjusting should solve your second point, and implements the first solution for your third point (although commented out). As for your first point of further refining the available list, since I'm not sure what the further refinements will be based on I haven't included code for it. However this analytic would be the place you put in those further refinements.

dxATGetUsersForItemDB:{[itemID;dt]
  isHDB:not null dt;
  itemID:"j"$itemID;

  alert:$[isHDB;
    value last select from dxATItemCurrent where date=dt, dItemID=itemID;
    last select from dxATItemCurrent where dItemID=itemID
  ];

  AT:alert`actionName;
  ATQ:alert`queue;

  // POINT 2
  // Error trapped as keys for sender/receiver may differ, also this analytic is used in the financial AT  
  users_to_exclude:$[all null ue:raze alert[`data]`sender`receiver;`;ue];
  // Get users permissioned on the action tracker
  permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[AT; `actiontracker]; `select];
  // POINT 3
  // Get users permissioned for the current queue
  //permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[ATQ; `actionqueue]; `select];  
  :permissioned_users except users_to_exclude
 }

 Please let me know if you have any follow up questions to this.

Regards,

Sam B

nfrishling
New Contributor II

Thanks for your response Sam, that’s very helpful.

 

A further question for point 1 – Ideally we would also like to have the names available in the dropdown appear as full names rather than just a login.

Assuming we had the user details relating to each login stored somewhere would it be possible to use this in the dropdown display when transitioning/reassigning?

 

To point 3 -The dropdown lists may vary depending on which transition is selected, or if reassign is selected, so just the current queue information would not be enough to correctly filter the list. As you suggested I could use the configured transition analytic to automatically reassign this item to a group or user in the correct group in the event that a user has made an invalid selection from the dropdown.

If there is no way to ensure the dropdown list contains only valid selections or a validation failure message provided to the user so they can select a different option it seems that in this case it might be better to simply automatically assign to the desired group rather than provide dropdown options at all.

With the transition popup, is there any way to disable the assign to drop down and/or assign to me  checkbox but to retain the pop up so that users may input comments relating to the transition?

Hi Nina, 

Regarding your first point, I think it would be possible, however there are some problems you may need to consider. Revisiting the dxATGetUsersForItemDB analytic which drives the elements of the dropdown, it would be possible to do a lookup based on a config that links the username to display name and return the display name for the dropdown. Something like this:

dxATGetUsersForItemDB:{[itemID;dt]
  isHDB:not null dt;
  itemID:"j"$itemID;

  alert:$[isHDB;
    value last select from dxATItemCurrent where date=dt, dItemID=itemID;
    last select from dxATItemCurrent where dItemID=itemID
  ];

  AT:alert`actionName;
  ATQ:alert`queue;

  // POINT 2
  // Error trapped as keys for sender/receiver may differ, also this analytic is used in the financial AT  
  users_to_exclude:$[all null ue:raze alert[`data]`sender`receiver;`;ue];
  // Get users permissioned on the action tracker
  permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[AT; `actiontracker]; `select];
  // POINT 3
  // Get users permissioned for the current queue
  //permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[ATQ; `actionqueue]; `select];  
  permissioned_users:permissioned_users except users_to_exclude;
  username_displayName:.uc.getActiveParamValue[`USERNAME_DISPLAYNAME;`];
  :raze exec displayName from username_displayName where like[username;]each permissioned_users
 }

You would need to consider that upon selecting this from the dropdown, the logic that follows is expecting a username. So you would have to map back to the username after the dropdown is selected in one of  (if not all) the dxATTransition* analytics - and potentially more. 

Regarding your next point I'm not sure if there is a way to disable the assign to dropdowns and retain the commenting. I'll look into this further and reach out internally. A possible solution in the interim could be to create groups for the transition endpoints. For example, create a group called Escalated for users who are able to transition the alert from the Escalated queue, and do the same for Closed etc. Then have these groups available in the dropdown, so that a user could simply assign the problem to the group corresponding to the transition's endpoint. 

Alternatively, the option of configuring the "transition analytic to automatically reassign this item to a group or user in the correct group in the event that a user has made an invalid selection from the dropdown" does seem to be a good solution still, in the absence of being able to disable the dropdown while maintaining the comments.

Regards, 
Sam B