Once testing of LiftOff is complete, the product should then be "turned-over" to the property management team. This entails a number of check-list tasks that should occur before leaving the property:

The first task of the turnover process is to ensure that members of the property management staff have been enrolled in the building with at least one staff member having been granted the Administrator role and at least one staff member (possibly the same one) having been granted the Approver role. This is important, so that the property can now own the role delegation process to other staff members, manage user enrollment, and own the activity of approving requests for access. Without this activity having been performed, new users making requests for access at the building may find their requests going unprocessed, creating a negative impression on their first use of LiftOff.

The second task of the turnover process is the reduction in Elevator Mechanic privileges. In order to facilitate the testing and demonstration of LiftOff to the property management team, Administrator and Approver roles will have been granted to the lead Elevator Mechanic at the property. It is very important that, following the Administrator/Approver Enrollment activity, either the new property Administrator or the Elevator Mechanic removes any non-Deployer role granted to the Elevator Mechanic. This serves two purposes:

A number of artifacts should be shared by the Elevator Mechanic with the property management team:

Putting the property management team in a position to reference these items allows the team to answer their own questions, and plan the rollout of LiftOff successfully.

After the installation and configuration of LiftOff, the first question from property management is almost always around how users will become enrolled at the building. The Elevator Mechanic should demonstrate the Request for Access process with the property management staff when enrolling the first Administrator and first Approver. Following that enrollment, the Elevator Mechanic should edcuate the property on additional options:

While braXos is solely responsibile for facilitating the Access Control System synchronization process, the Elevator Mechanic can put the property in a good position to understand what is required to enable an ACS sync, both from the access control system side of the synchronization as well as from the Commander side of the synchronization. The key items requiring discussion are:

As noted in the document shared with the property, ACS to LiftOff Sync, the key data element required in the access control system to allow for a synchronization is the email address of the user being synchronized. This value is used to send the user an Email Code, which the user will enter into the LiftOff. Once entered, the ACS profile will be "linked" to their user profile, and membership both in the building generally, and in floor access groups will be managed by the synchronization.

While the source system requires an email address, the destination of the synchronization, Commander, needs the property management staff to create the Floor Access Groups into which the synchronization would automatically manage membership. This task should be owned by the property management staff, as the destinations accessible to each group will change over time, and the Deployer role does not grant the Elevator Mechanic the authority to add, edit, or delete Floor Access Group definitions. Floor access groups can be created via the CSV upload mechanism, or by utilizing the many tools within Commander to create groups from ACS data.