There are a variety of considerations for use and best practices for OnBoard for Exchange. Please take a look at our "considerations for use" document for further insight
CONSIDERATIONS FOR USE
- We recommend that customers use OnBoard for Exchange for conference rooms rather than
- If a room is going to be used with OnBoard for Exchange and will require check in, users should
understand that they will need to use an OnBoard interface to check in. There is no mechanism in
Outlook to check in.
- Reservations that are created from Outlook are made in OnBoard by the service account, which is
similar to having a concierge create a reservation for the user; the concierge is the reservation
creator but the user is the reservation owner. The service account is able to override all OnBoard
business rules including (but not limited to) maximum days in advance for a reservation, lead time
for a reservation and cancellation lead time. (R1)
- End users will receive several emails from both Exchange and OnBoard for each reservation. Users
may opt to create rules in Outlook for automatically moving the emails to a special folder created
for reservation emails.
- A user who expects to be making OnBoard reservations primarily in Outlook may opt to turn off his
OnBoard reservation emails. He must go to his user profile in OnBoard Mobile and choose No for
the question about receiving email notifications/confirmations. Note that this will not affect
reminder emails if those are turned on for the customer.
- If the subject line for an appointment is left empty in Exchange, the room name will be used as the
reservation name in OnBoard.
- In R1, all text in the Comments field will not be synced with the other application. Comment field
contents that are added in Outlook are not sent to OnBoard and vice versa.
- If a user modifies the attendees on an Outlook appointment, the user must choose "Send update to
all attendees" option before sending the update. If the user chooses "Send updates only to added or
deleted attendees," the room on the appointment isn't notified of the change so the user would
remain on the transattendee table in the OnBoard database.
- When a user is making a reservation via Exchange and a room is not available:
o in Exchange, the room is removed from the appointment but the user keeps the
appointment so he doesn’t lose all of the information. He will receive an email from
Exchange to let him know the appointment was declined.
o in OnBoard, the reservation is cancelled because you can’t have a reservation without a
room. In this case, the concierge or OnBoard admin could copy the cancelled reservation in
Navigator and move it to a better time.
- A user can leave an invitee's email address blank when making a reservation from OnBoard. When
the user is only working in OnBoard, this doesn't impact the reservation. However, with the
Exchange integration, an invitee must have an email address. If a reservation creator leaves an
invitee's email address blank, the reservation creator will get an email that directs him to correct
the email address. If the reservation creator doesn't know the invitee's email address, he can use a
placeholder email address as long as it's in the standard email format.
- If the reservation owner does not have the allocations for a room in OnBoard, generally, he will be
able to create/modify a reservation in Exchange for that room but will not be able to create/modify
a reservation for the same room in OnBoard. The reservation from Exchange is created by the
service account and that account will be able to make reservations for all rooms. In OnBoard,
however, the user will be dependent on the allocations on his user profile. Allocations should be
aligned with security groups from Active Directory.
- A single instance of a recurring reservation may not be changed from not private to private or vice
versa. The user must change the status of the entire series.
- In OnBoard, a user creating a recurring reservation is limited by both the maximum days in advance
business rule and the maximum instances property. In R1, when a user creates a recurring
reservation in Outlook with OnBoard for Exchange, he is no longer bound by the limits of the
maximum days in advance due to the reservation being made by the service account, but the
maximum instances property will be adhered to. The reservation instances that match the number
set by that property will be created; any reservation instances that exceed the value of the property
will have tasks created to make the reservation instances as the current instances expire.
Additionally, limits can be set in Exchange for recurring appointments. In R2, the user will be bound
by the maximum days in advance for a reservation in OnBoard as well as the maximum instance
property and the limit set in Exchange.
- When making or modifying a recurring reservation, if there is a blocking reservation, the behavior
the user sees will depends on which reservation is written to the OnBoard database.
o If the blocking reservation is made in Outlook and is made with sufficient time for it to be
populated to the OnBoard database, when the user attempts to commit the make/modify,
an error will appear to tell the user the resource is not available.
o If the blocking reservation is made in Outlook and is not made with sufficient time for it to
be populated to the OnBoard database, the outcome depends on whether the blocking
reservation or the make/modify of the recurring are populated to the database first. This
seems to be wholly dependent on the network.
If the blocking reservation is populated to the database first and the recurring
reservation is being created, in Outlook, the appointments for the recurring will be
created with the room information but the user will receive a decline from Exchange
because of the conflict on the room. In OnBoard, the entire recurring reservation is
If the blocking reservation is populated to the database first and an instance of the
recurring reservation is being modified, in Outlook, the appointment for the
recurring instance will be changed to reflect the modification but the user will
receive a decline from Exchange for that one instance. In OnBoard, that single
instance of the recurring is cancelled.
If the recurring reservation or instance of the recurring reservation is populated to
the database first, in Outlook, the blocking reservation has the resource removed
from the appointment window and the user will receive a decline from Exchange. In
OnBoard, the blocking reservation is cancelled.
- A customer using cloud based Office 365 may find that their users don’t receive Exchange emails at
times because an event is not sent out from Exchange. This is a documented defect from Microsoft.
To avoid issues for the OnBoard for Exchange users, OnBoard for Exchange will poll Exchange on a
regular basis to capture events that may have been missed otherwise.
BEST PRACTICES -- USERS
- When creating an Outlook appointment, a user should use the scheduling assistant and room finder.
The room finder will show which rooms are available during the time selected so the user can be
sure he's choosing a room he'll actually be able to use. If he just adds the room through the To: or
Location: lines in the appointment window, there's no way for him to check availability of the
resource before he sends the meeting request and he would have to wait for the decline message
from Exchange to know that the room he selected isn't available.
- The room finder does not work for recurring reservations.
- If a room requires manual approval in OnBoard, the user should create an appointment with no
invitees to reserve room first. After the user receives the email notification to tell him that his
request for the room has been approved, he should re-open the Outlook appointment and add
BEST PRACTICES -- CONFIGURATION
- Reservations made from Exchange are made by a service account for the reservation owner. An
OnBoard user profile must be created for the service account and the user profile must be an
administrator level account with all rights, including the right to override all rules and the right to
manage own requests. (R1)
- At the facility level, the maximum days in advance should be set to 365.
- At the resource level, the business rule settings will be overruled by the service account in R1.
- Two properties in the OnBoard databases need to be set to true (exchange.push.enabled and
exchange.pull.enabled). Both of these properties are for whether the type of notifications (push or
pull) are enabled. If either of these is set to false, Exchange notifications will not be sent for that
- If a potential client’s servers can’t talk to each other, the client may not be able to implement
OnBoard for Exchange. When a client doesn’t want to expose the Connector (such as with Office
365), they could only do a pull every 5 minutes or so, which would not be recommended.
- The rooms that will be available for use with OnBoard for Exchange must have OnBoard resource
profiles created. The same names should be used in Exchange and OnBoard to avoid confusion.
- Rooms that require manual approval in onboard should be set to be automatically approved in