Microsoft Places
Microsoft Places Resource Naming Tips
At Essential, we’re continually exploring practical ways to ease both the migration of resources into Places and the day-to-day experience of booking and managing spaces.
I recently came across a couple of queries around handling user interaction with resources in Microsoft Places.
They were proving to be tricky to address using default Places functionality, but ‘the fix’ ended up having some simple workarounds.
Coping With Booking Policies on Places Resources
The first scenario involved a set of resources that were restricted for use by senior staff only.
‘Regular’ users were trying to book these specific desks and not understanding why their booking was being declined.
These desks were blocked using a Book-In Policy that limited bookings to specific users.
The challenge with this, however is that a Book-in Policy won’t stop a resource from being listed in Microsoft Places. It just controls who can book it, when, and under what conditions.
So if the policy effectively blocks a booking, attempts to reserve it will fail.
As you can imagine, this can be a bit frustrating: You see a resource, you book it, and you get a decline.
Here’s my top tip to stop this happening – sorry – it’s not rocket science, but it works.
An easy workaround is just to rename the desks. From something like ‘Desk 01’ to ‘Desk 01 – Reserved for Accounts’.
This makes the restriction clear at a glance, both on the listing and map view.
You can also set tags against resources in Places, but it can need a more immediate (obvious) way to inform staff about what these tags mean.
As an alternative or in additional, you could also include descriptive text on your Places maps – e.g. as part of the Furniture/Fixtures IMDF layer.
This may be a practical option if the booking requirements aren’t likely to change that often (as it would be painful to have to keep making changes to your maps) and there’s appropriate space on the map area.
Hiding Places Resources from Regular ‘Room Finder’ Users
The second scenario was where an organisation wanted to hide some new meeting and desk spaces whilst it was embedding Places.
The new spaces were associated with a newly commissioned floor, and would only be bookable by a pilot group of Microsoft Places users (and not to be exposed to non-Places users that were still using Room Finder to book existing workspaces).
To make these rooms and desks available in Places, the resources first had to be created as resource mailboxes in Exchange Online.
By design, these mailboxes are automatically published to the Global Address List (GAL), which means they will also appear in Outlook and Room Finder.
So again, in this situation a tactical renaming can help, by either renaming it to something like Places-Only-Desk-01, or even a name like zzPlaces-Desk-01 (where the zz would put this resource right at the end of the list, so they’re less prominent to non-Places users but still technically available).
You can of course use booking policies to restrict booking if needed.
Conclusion
Sometimes a simple naming change can fix a complicated issue.
