Why are unregistered attendees moved to Denied/Blocked list?

[LisaSp]

We have discovered that unregistering an attendee actually moves them to the denied/blocked list, which prevents them from re-registering themselves again if they decide they can attend after all.  Why in the world would Zoom move an unregistered attendee to the denied/blocked list, simply because they have canceled their registration? 

If someone cannot attend a live webinar that has limited capacity, we want them to free up their seat for someone else. This doesn't mean we want to deny/block them. 

Additionally, because we have an integration with Zoom from our learning management system (LMS), this causes loads of issues for us and our thousands upon thousands of customer-learners. If an unenrolled learner decides they can attend after all and re-enrolls, our LMS sends the enrollment data, but Zoom blocks the re-enrollment. This results in a disconnect in enrollment status between the LMS and Zoom.  The learner thinks they're enrolled because they see that status in the LMS, but no one knows the enrollment has actually been blocked/denied by Zoom until the learner realizes they haven't been getting confirmation emails or tries to access the webinar using a link from a confirmation they received before they unenrolled. Zoom needs to treat unregistered (unenrolled) users and denied/blocked users differently. Yes, denied/blocked users should be unregistered, but not all unregistered users should be denied/blocked. 

Finally, this causes privacy issues for us and our customers. Our company has strict security and privacy policies around protecting customer data, but once a learner registers for a webinar, their data is held in Zoom's system forever, apparently, even if the learner cancels their registration.  With Zoom moving the learner to the denied/blocked list,  the learner's data persists in Zoom's system ad infinitum, and there's no way for us to remove it. This violates our privacy policies! A learner who cancels their registration but is not blocked/denied should have their data simply purged from Zoom's system, as if they had never registered. 

We host dozens of webinars a months with up to 600 to 1,000 attendees per webinar. Zoom needs to fix this issue!

[YaBoiB]

Hello @LisaSp, 

 Are you stating that the host is unregistering the attendees, or the attendees are unregistering themselves? 

Is this a manual registration approval or an automated approval situation? 

This issue is going to take some looking into. Where we look at a Sample Webinar from your account and we cannot divulge meeting IDs in the Zoom Community, so I recommend that we take this up to Support. Can you or have you already submitted a support ticket related to this issue? 

Thanks, 

Brandon

[LisaSp]

Hi Brandon,

Here's the typical workflow:

• Learner registers for a Zoom webinar in our LMS, which is integrated with Zoom. Our LMS sends data to Zoom  and Zoom (correctly) registers and approves the learner.
• If the learner decides they cannot attend the webinar, the can do one of two things:
  • They can unenroll themselves in the LMS, but it appears the data is not being sent to Zoom. This means they are unenrolled in the LMS but still enrolled in Zoom. They still get confirmation emails from Zoom, even though they think they unenrolled. 
    OR
  • They can contact us, and we'll unenroll them. Historically, before we realized that the unenrollment isn't transferred from the LMS to Zoom, we would just unenroll them in the LMS. Now, we'll have to unenroll them manually in both the LMS and Zoom, except doing this in Zoom moves them to the denied/blocked list.
    
    If the learner changes their mind and re-enrolls themselves via the LMS, the LMS now says they're enrolled, but Zoom still has them as denied/blocked because the data sent from the LMS does not override that status or reapprove them.

Again, the integration with the LMS should be sending unenrollment data, but that's only part of the issue. Zoom should not be conflating a simply unregistering someone with the extra step of denying /blocking them. These are two different statuses.

Thank you for looking into this.

Lisa

[YaBoiB]

Hi @LisaSp, 

 Okay, I understand the issue; the API call between the LMS and Zoom is either not happening or failing at some level within the application. Zooms Technical Support Engineers will know what to do with this and who to talk to or engage within our company. That is why I asked if you had submitted a support ticket then. We cannot troubleshoot this in this forum because I need PII data from your LMS or Account that we want to keep private. 

We have an article in our support documentation on how to reach out to our TSE https://support.zoom.us/hc/en-us/articles/201362003-Contact-Zoom-Support 

I know that they are a great group because that is where I started my journey here at Zoom. Please, reach out to them and be as specific about what LMS you are utilizing and provide an example of one of the learners who unenrolled and the information did not pass to Zoom from the LMS. Our team will be able to give you the correct information to resolve this issue. I am sorry that you are going through this, and I hope we can give you the support you need. 

Thanks,

Brandon 

[LisaSp]

Hello Brandon,

Thank you for your response. The LMS is a third-party system. I am just a client of theirs. I will need to refer their technical support team to your latest post and ask them to contact Zoom Support as you have described. 

Thank you, 
Lisa

[YaBoiB]

Hello Lisa, 

 No worries I took off the solution for you. I figured you did that by mistake. Yes, the best bet is to get the technical teams together so that we can check on our backend and see where the failure is. I am not an integrations specialist but I used to work in Support and I know that they have the correct resources to assist in this case. 

Let me know if you hit any roadblocks and I will assist in getting this resolved. 

Regards,

Brandon

[LisaSp]

Brandon,

Of course, if you refer to my original post again, the LMS-to-Zoom API call is only part of the problem described in this post. The other problem is that when we manually unregister a learner in Zoom, Zoom moves them to the denied/blocked list. This is independent of the LMS issue and should not be happening unless we click an option that specifically says we want to deny/block them.

I should not have accepted your last post as the solution, as that's only one angle of the problem.

Thanks,

Lisa

[LisaSp]

Sorry, I missed the rest of your message. How do I submit a support ticket? 

[KellyZ]

I am having this same issue. When someone unregisters on the webinar report is shows as cancelled by host but this isn't correct, they have unregistered themselves.

There should be the correct information on the report.

If they try to join the meeting they get a message saying "The host has removed you from the meeting."  which is incorrect. Our clients are saying we have removed them from webinars when that is not the case.

[cksteiner]

I completely agree about putting people in Zoom jail (block/deny) just because they registered and now cannot attend. A bit harsh/extreme/unnecessary... makes no sense. I want to be able to either 1.) remove them completely from the event (as if they never registered)... or 2.) have a Cancelled option that keeps their information with the webinar, but allows them to re-register. The fact that they cannot re-register is about the worst user experience I can think of and it's a huge problem for us.

AND from a webinar host/manager perspective, sometimes I need to test the administrative things to make sure they're working... we do not use Zoom's emails, so that requires extra testing before invitations go out...  I end up with 4-5 people registered for testing purposes only and I'd like to clean that up and start fresh. These 4-5 people may want to attend or may not... so I'd like them to be able to delete them, start fresh and then let them re-register when I have the final invitation email ready to go. 

[philvdb]

I also have the exact same problem, with the difference that I developed the API integration with Zoom myself, @LisaSp . Still to this day I am having issues with Zoom being unable to differentiate between cancellation and blocking of registrations.

Zoom API documentation here lists three possible actions that can be taken with webinar registrants:

https://developers.zoom.us/docs/api/rest/reference/zoom-api/methods/#operation/webinarRegistrantStat...

`approve`, `cancel` and `deny`.

All I have ever called with the API is `cancel`, never `deny`. Expected behavior (IMHO) should be that `cancel` will reverse approval for webinar participation but not place user's e-mail addresses on a blocklist. But it does. From the outside world, the API's response to `cancel` seems indistinguishable from `deny`, which I presume cannot be intended but simply seems a mistake that has gone uncorrected for years.

The other issue you raise with Zoom keeping user's personal data ad infinitum in violation of GDPR is also correct. I have raised this issue with them a couple of years ago (I believe around 2021, could look it up), they said they would escalate my concerns but nothing came of it. My (forced) workaround for this issue has been to deliver nothing but mock e-mail addresses to the zoom API for our platform's users since after all, my clients and I are responsible for the safekeeping of our users' data and if I want to use Zoom's services, I had to work around their disregard for privacy regulations.

So I believe the two issues you are raising and we all are experiencing are a) a bug (lack of differentiation between `cancel` and `deny` actions) and b) bad design (non-adherence to GDPR).

By the way, this is so easily reproducible that it really shouldn't be necessary to ask for specific webinars this happens with. Create any webinar. Register a participant. Approve them. Then cancel (not deny!) them through the API. Then look at the blocked addresses for said webinar. Bingo.