Array
(
    [post_type] => post
    [posts_per_page] => 6
    [order] => DESC
    [orderby] => date
    [ignore_sticky_posts] => 1
    [post__not_in] => Array
        (
            [0] => 43740
        )

    [category__in] => Array
        (
        )

    [tax_query] => Array
        (
            [relation] => OR
            [0] => Array
                (
                    [taxonomy] => category
                    [field] => slug
                    [terms] => Array
                        (
                            [0] => microsoft-places
                        )

                    [operator] => IN
                )

        )

)

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 workspaces that were restricted for use by senior staff only.

‘Regular’ users were trying to book these specific resources and not understanding why their booking was being declined.

‘Behind the scenes’ these resources had a Book-In Policy associated to them that limited bookings to specific users – i.e. senior staff. 

The challenge with this scenario, however, is that a Book-in Policy associated with a resource won’t stop a resource from being listed in Microsoft Places (or for that matter, Resource Finder). The listing only shows free/busy status.

Any policies associated with a resource only comes into play at the point of booking. So if someone outside the allowed group tries to reserve the desk, the system processes the request, then rejects it.

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.

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.