As we established in the ResRequest Architecture and Working in Different Environments tutorials, it is possible to have multiple reservations offices working on different servers. However, only one server should be Master at any one time. You will have to consider this when determining how you want to set up your ResRequest servers and environments for your business. This is only applicable to offline and web servers and does not apply to web property servers.

In order to function fully with multiple offices, there are four options:

1. Work on Web as Master
   1. All offices work on the Web (WB) and it has Master status.
   2. This is by far the “easiest” solution.
   3. One must be careful that 2 people are not editing the same booking (or code table, rate etc) at the same time as this could cause conflict.
   4. If internet speeds are good all offices can work on the web as Master.
   5. An offline RS server can be located as a back-up in the busiest office, or the office with the worst internet connection in case the internet connection goes down. In this case, the RS server can then be set to Master and the below scenario unfolds:
2. Have Web and Reservations servers (e.g. RS) and ‘Time Slice’ between them
   1. One office works on WB, one office works on RS – Master status is shared (at different times).
   2. If one office has good internet speeds you can work on the web and it is not necessary to have a second offline server.
   3. It is necessary to have a timetable for when each server will be Master.
   4. It is imperative to have clear procedures for swapping Master status and for those procedures to be followed otherwise data corruption could occur. The Web should never be forced to Master, Master status should always be given/taken from the RS server, e.g. 1. RS does a Data Transfer 2. RS sets Web to Master – RS works as Slave 3. RS does a Data Transfer 4. RS sets RS to Master – RS works as Master
3. Have multiple Reservation Servers (e.g. RS, RA, RB etc)  and ‘Time Slice’
   1. One office works on RS, one office works on RA – Master status is shared with one environment being Master as any one time.
   2. You can have as many reservations servers in as many places as you wish (RS, RA, RB etc). But because reservations servers and the web make up one environment – only one can ever be Master at a time.
   3. It is necessary to have a timetable for when each serverwill be Master.
   4. It is imperative to have clear procedures for swapping Master status and for those procedures to be followed otherwise data corruption could occur. The Web should never be forced to Master – Master status should always be given/taken from the RS/RA server.: 1. RS does a Data Transfer 2. RS sets Web to Master – RS works as Slave 3. RA does a Data Transfer 4. RA sets RA to Master – RA works as Master 5. RA does a Data Transfer 6. RA sets Web to Master – RA works as Slave 7. RS does a Data Transfer 8. RS sets RS to Master – RS works as Master
4. Use a Property Server
   1. One office works on RS, one office works on PA – each has Master status.
   2. You can install a virtual property server in one office. Because a property server is a secondary environment – both the PA server and the RS server can be Master (of their own data) at the same time. This allows both environments to create and edit bookings.
   3. However – bookings created on a Property Server are only ever updateable on that server. You can never update them from any other location – or the web. So you can only use this option if the bookings created in that office NEVER have to be updated on the Reservations environment (offline or web).