Has Anyone Figured Out Reservations From External Employees?

[Casey23]

Before getting into it, I will say that we have a case open with HI on this issue, but am curious if anyone has gone through this as part of the implementation for Workplace Service Delivery, specifically in the Reservation Management module and what you did to solve it (customization or not).

The short story is that we have users in our ServiceNow instance and in our Exchange GAL who work for other organizations. Because of that, they have an email domain that is different from ours. When they try to reserve a room in reservation management, Exchange is rejecting the request. We can see the error "Provided User ID is invalid"  in the calendar sync events.

We have confirmed that if we use an external Gmail account and send the meeting request to the room, Exchange will allow the room to be booked. 

So something that ServiceNow is doing, or something in the API isn't allowing these rooms to be booked because of the email domain issue. This also creates a problem where you can't book on behalf of another user if they also don't have an email with the organizations domain because it will fail with the same error.

Has anyone else experienced this during their implementation, and if so, how are you working around it?

[jon_h]

I realize this is an older thread, but I am having the same issue. Were you able to resolve this issue? Or is this a limitation of the platform?

[Casey23 · Accepted solution]

My apologies, I should have added details to this post after we went through this process with support.

The short answer is that the only way to allow users outside the organization to utilize reservation management, is to give them an email address from your organization.

The long answer is that this was the response that we got from the Product Team after escalating this issue. They also brought in Microsoft and it turns out that this is a limitation of the Graph API that ServiceNow uses for this application. We asked if there were any intentions of expanding the Graph API functionality to include this use case and Microsoft stated that there was no intention of doing this. 

We didn't want to give those users another email address because it presents some issues with duplicates in the GAL, goes against our standards that we have in place, and also forces the user to be constantly vigilant to ensure that they are managing emails with the correct email address to avoid issues with their reservations. We are actually going to be decommissioning the application and moving directly to Exchange. Obviously we lose functionality, but since we already have Exchange, there isn't an additional fee to use it and everyone can use it regardless of which organization they are with. 

[jon_h]

Thank you so much for the response! We were thinking that it was a limitation of the Graph API and this confirms it.