Mobile Apps

Shared Mobile Devices and Multiple Devices per User

Archibus support a flexible assignment of mobile devices.

• sharing the same device between multiple users. For instance, a site may have a limited number of corporate-owned devices that are shared between shifts. When workers finish their shift, they sign out of their device and it is used by the next worker.
• multiple devices per user. For example, a user might switch between a tablet and a phone for various tasks.

• employees consuming workplace services (such as booking meeting rooms, requesting services, and so on) from their own personal devices. This is known as BYOD / BYOT-- "Bring Your Own Device / Technology." For information, see https://en.wikipedia.org/wiki/Bring_your_own_device

You can mix the above approaches. For example, a maintenance craftsperson prefers to use their own personal phone to execute standard work orders because it is easy to carry to the work site. However, the craftsperson also has a company-issued iPAD for reading maintenance documents, reading large complex work orders, and looking up the work location on the floor plan . Furthermore, the craftsperson shares the iPAD with a co-worker on another shift.

Mobile managers can check the devices registered to a user and a history of device registrations with the System / Mobile Apps Manager / Track Mobile Device Registration task

Note: Sharing devices between users and allowing one user to work with multiple devices does not apply to: 
-- running the mobile apps in a Web browser.
-- the mobile SSO configuration. The SSO configuration maps a single device to a single user using the user's personal authentication certificate.

Sharing one device between multiple users

Sites will often share mobile devices between a set of colleagues, particularly if they work on separate shifts. For example, consider the following scenario is which craftspersons Will Tram and Chris Ridder share the same tablet.

1. Craftsperson Will Tram works on a service request that he is not be able to finish by the end of his shift.
2. At the end of his shift, he syncs his works and logs out before giving his tablet to his colleague, Chris Ridder, who has other maintenance requests to work on. The device is still registered to Will Tram and the next morning Tram will be able to log in and pick up from where he left.
3. Chris Ridder logs on to the device. Since it's his first time using the tablet, the Archibus mobile app registers the new device to him, without removing the registration for Will Tram. Ridder is a locksmith so even though he will be using the same tablet as Tram, he does not work on the same requests and will access only his maintenance requests (maintenance requests assigned to him). He will not access Tram's data, which may be confidential.
4. At the end of the shift, Ridder logs out of the Archibus mobile apps and hands the tablet back to Tram.
5. Tram logs in. He does not need to re-download background data since the device is still registered to him.
6. After re-assessing the repairs needed, Tram decides that he needs additional parts and adds them to the request.

7. After Tram fixed the plumbing problem, he updates the maintenance request as completed and syncs. In doing so, he synchronizes only the data associated with his user account.

To support sharing devices such as in the above scenario, the system segregates the user data on the client device. Each user has a separate client database. The data contained in the user database is not deleted or modified when a user unregisters the device or another user registers the device. This means:

• when you sync, you upload and download only that data that is associated with your user account. If other colleagues are using this device, you will not upload the data associated with their account.
• the system maintains the background data between log-ins by the same user, so that the user is not forced to download the entire set of background data each time they log into a device.

One user with multiple devices

A user can use multiple devices, such as a personal iPhone and a company iPad. However, the user can work with only one device at a time. They must log out of the previous device; if they fail to log out and then register a new device, the system automatically unregisters any devices currently registered to this user.

The afm_mob_dev_reg_log table stores a log of the registrations. Below, you can see that user Tram has three devices, but only the iPad is currently registered. On 02-04-2016, Tram unregistered the iPhone and registered the Android. Similarly, on 03-07-2016, he unregistered the Android and registered the iPad.

Registering a device and logging out

When you register a device, the system does the following.

• generates a unique device identifier (the first time that you register the device)

  • The device ID is always the same for Windows and Android devices.
  • The device ID for iOS devices remains unchanged unless you delete the Mobile Client app and re-installs it.
• in your record in the afm_users table, updates the Device ID field with the ID of your device.
• creates a record in the afm_mob_dev_reg_log table for you for this device and completes the Date Registered and Time Registered fields.

Logging out (unregistering)

When devices are shared between users, users must log out of the device before handing it off to the next worker. Similarly, if a user is working with multiple devices, they must log out of a previous device before they can register a new device.

When you log out of a device, the system does the following:

• In the afm_users tables, sets the mob_device_id field to NULL.
• Enters the event in the afm_mob_dev_reg_log table.
• If the user has a registered device, unregisters this device by updating the Date Unregistered and Time Unregistered fields for this device.

Changing the Web Central project configuration

When sharing devices, you can have inconsistencies in the data if you change the Web Central mobile project configuration is changed after the client syncs.

The following scenario can cause this issue.

1. Web Central mobile project setting is configured to use Project A
2. User TRAM syncs his device and loads data for Project A on the device.
3. The Web Central Administrator changes the mobile project configuration to use Project B
4. User TRAM starts an app. The device is not registered. User TRAM registers the device.
5. User TRAM's device now contains data for Project A, but is connected to Project B on the Web Central Server.
6. User TRAM's sync history is no longer valid, subsequent syncs may not sync the correct data.

To avoid this issue, be sure to have the user run the Clear Data action before connecting to a different project on the same Web Central server.

However, if the user did not clear data, the System Administrator can resolve this issue by clearing the sync history for all users.

To clear the sync history the administrator can perform either of these actions. Each requires that you load the afm_mobile_sync_history table in Smart Client.

• Set the afm_mobile_sync_history.last_download_timestamp value to 0 for all entries.
• Delete records from the afm_mobile_sync_history table for all users.