Please confirm:
Problem Statement
When the False Positive Webhook is triggered, the information delivered has nothing to help us immediately identify the user raising the report.
The other Webhook triggers include a "User" object that includes the email address. That would be very helpful with false positives as well.
Benefits for MSPs
This would give us a means to know who is trying to tell us about a false positive so we can focus efforts on getting the URL checked and approved for them, before rolling it out more broadly.
Value or Importance
From the screens the end-user sees, it's safe that they would assume that we should know that it was them that raised the False Positive report. As such, they're expecting us to respond to them (and specifically them).
Generally these things happen when someone needs to get something done quickly, so reducing the interruption to them would be a benefit.
Please confirm:
Problem Statement
When the False Positive Webhook is triggered, the information delivered has nothing to help us immediately identify the user raising the report.
The other Webhook triggers include a "User" object that includes the email address. That would be very helpful with false positives as well.
Benefits for MSPs
This would give us a means to know who is trying to tell us about a false positive so we can focus efforts on getting the URL checked and approved for them, before rolling it out more broadly.
Value or Importance
From the screens the end-user sees, it's safe that they would assume that we should know that it was them that raised the False Positive report. As such, they're expecting us to respond to them (and specifically them).
Generally these things happen when someone needs to get something done quickly, so reducing the interruption to them would be a benefit.