A leading management consulting firm with over 250,000 employee has used EMS for more than 10 years to schedule and manage Classrooms, Lobby Areas, Meeting and Conference Rooms, Hot Desks, Parking Spaces and Video Conference Rooms. Their EMS implementation manages 330 customer buildings around the world, comprising 33,095 rooms and hot-desks. In 2011, the number of bookings scheduled was 2,234,086.
There is no limit on the amount of data you can pull through the API. The EMS API provide numerous call filters so you can request an efficient and targeted set of data. This helps reduce the workload on the EMS system. It also improves the performance of your solution, so no extraneous data is processed.
EMS APIs provide infinite configurability by enabling you to completely customize your API calls and returns.
You define your organization's EventTypes and Statuses; you can retrieve a list of these calls using the GetEventTypes and GetStatusTypes calls. Status types, for example, are as follows:
- Booked Space —the room is taken out of inventory and cannot be reserved by another booking. (The system prevents the space from being double-booked.)
- Cancel—booking information is retained, but the room is released back into inventory
- Info Only—Booking information is retained, but the space is not taken out of inventory
- Wait—booking information is retained in case the space becomes available prior to the event date
StatusTypeIDs are as follows: -14 = Booked Space, -11 = Info Only, -13 = Wait, -12 = Cancel
The GetEventTypes and GetStatuses calls above both return a field called DisplayOnWeb. You set this field when defining a new EventType or a new Status, to either Yes or No. DisplayOnWeb is the field used in EMS web interfaces, including EMS Web App and EMS Kiosk, to determine whether to display an event. Taken one step further, you can also determine which EventTypes and Statuses may be displayed (DisplayonWeb=Yes). You can use those EventTypes and Statuses as filters on some GetBooking calls; the result is you see just the booking data needed, rather than pulling in all data and then discarding a long list of bookings.