Out-of-Bounds threshold alerting and notification triggers
Recently we had an INC where a user tripped our 50% circuit breaker on the Out-of-Bounds Threshold. However we were not made aware of this situation until a later date due to the fact that there are not separate notifications for when this circuit breaker has been triggered. GroupID will not send notifications if you have selected only "When the job fails" AND the threshold limit is reached because the job is executed but it won't update a single group in the dynasty, So in our case we have to choose the "Always send the report" and manually check this on our end. This is not feasible to check a report every 4 hours as the damage would have already occurred. We would like to have it set up to where you can choose this at a granular level for individual groups as well as to possibly have the logs turned on to automatically alert our team. We have worked with Ali Qasim, Technical Imanami Resource on this issue. Thanks, Nick
-
+1 for this.
I too am currently using the Always receive reports for all dynasties to see the out of bounds groups. Also as check to have a record the dynasty complete, on rare occasions a dynasty gets stuck in a running state.
Even with a separate report i think the existing Always report format can be updated for improved readability.
For example, I have a dynasty that controls over 1000 groups.
I have to scroll somewhere in the middle between the 'status' confirmation and the summary of changes to find the "Result:" line This can take time or I can do a Control F to find that line but its just adds more seconds to validate and when you multiply that against every dynasty report it adds up.
Suggestion is to move this Result line to the top of report so its one of the first things you see.
Also instead of providing a generic message "Successfully processed group(s).One or more errors occurred while processing the group(s)" - Include the exact number/count of groups that failed.
Also if possible, move the status and summaries of all the failures/errors/out of bounds to the top of the sections to group them all together and avoid having the scroll through or control F to find each.
----
Then this might be a separate idea but now that you know the threshold has been reached, build in a GroupID feature to help you analyze what the changes are. Right now you have to review the existing group and do an export or similar if it's big, then you have to run a preview in the management console to see what the changes would be. This is a manual task.
What I would like is a way to generate a report to show me the differences. For example, these 10 users will be added, these 20 will be removed. It would also be good to have additional attributes viewable or at least the one the dynasty is based on. Such as if its a manager dynasty then, show me the value for manager so i can visually confirm that the user has a different manager.
Please sign in to leave a comment.
Comments
3 comments