Automatic check-in

With the manual check-in functionality, attendance data is more reliable than ever. Read all about the manual check-in in this article. The manual check-in is a great option to increase attendance reliability in the office, but you are still dependent on the users taking manual action. With automatic check-in, Mapiq can automate this process and remove the reliance on manual actions.

What can you do?

  • Call upon two API data endpoints to retrieve individual check-in events and currently checked-in users.
  • Locate end-users through your desired attendance system.
  • Users can check out of the office. 
  • Admins can view who has checked in through the admin portal. 
  • Admins can view check-in analytics available through the Analytics dashboard. 
  • Check-in is flagged in the API. 
  • The checked-in status is visualized among connections. 

Accessing the admin portal and log in with your company account. If you receive a message informing you that you don't have the right to access it, get in touch with your Subscription administrator. They can set the proper permissions for your account. Not sure who to contact? Go to Your Profile in the top right corner, and a contact e-mail address will be shown under Questions (if properly configured by your company). Not sure what permission level you need to adjust/configure your building? Check out this article to learn more about permissions. 

Enabling automatic check-in

In contrast to manual check-in, a clickable toggle button is not used for automatic check-in. Automatic check-in requires that customers collaborate with Mapiq's Solutions team and partners to build a custom check-in solution. Since each company can have a different way of integrating their attendance tracking systems (e.g., Wi-Fi, access gates, localization systems), tailor-made solutions are necessary. Assuming the requirements are gathered, customers can then link their attendance tracking system to Mapiq by sending a POST call to the Mapiq API.

If you are unaware of APIs or different types of calls (e.g., GET, POST, PATCH, DELETE) please reach out internally to someone with this knowledge. Alternatively, there is plenty of information to be found online.
For more information on the Mapiq API, please view following articles:

The POST call ensures that the data is sent from the attendance tracking system to the Mapiq API, enriching Mapiq's database with the check-in/check-out events. To successfully make a POST to the Mapiq API, the following body is expected by the Mapiq API.

Which user checked in/out.
In which building the user checked in/out.
Gets or sets the type of event (check-in or out).
  • AtTheOffice: check-in event.
  • NotAtTheOffce: check out event.
Through which source was the user checked in/out.
  • Wifi: Used when the check-in event is sent through a Wi-Fi integration.
  • accessGate: Used for checking in with an access gate at the office.
  • sensor: Used for checking in using sensors at the office.

Once the data is sent, Mapiq captures the event data in their database, and the Automatic check-in button is enabled automatically. After four days of inactivity through the API connection, the Subscription Administrator will receive a notification that something might be going wrong. After a certain amount of time of inactivity, the button goes back to Disabled.

Check-in events (both check-in and check out) can not be posted in rapid succession, per individual user. If consecutive check-in events are detected, the API call fails. A 15-second period is required between every check-in event.

Viewing and retrieving automatic check-in data

After data has been sent to the Mapiq API, the check-in data becomes available in both the admin portal and on two API endpoints, again accessible through the Mapiq API.

Check-in data is visualized in the admin portal and on the end-user side. Below are a few situations that impact the visualization of check-in data. For the end-user view, please refer to this article. In the admin portal, the data is visualized on the Shifts tab and an Analytics report is made available. A new column is visible after the solution is enabled called Checked-in, containing either a Yes or a No value depending on whether the user has manually checked in. On the Analytics dashboard go to the Check-in tab.

The check-in status will remain Yes when a user is checked-out. Additionally, check-in data is visible in the export of the shifts selection, and remains visible in the shift history for as long as the retention period allows (see chapter Data & privacy).

For access through the API endpoints two different endpoints have been created:

  • An end-point to retrieve all individual check-in events, including the following data: 
    • The checked-in/out date 
    • The checked-in/out user 
    • Checked-in/out location 
    • Checked in/out source (API, manual, ...) 
  • An end-point to retrieve currently checked-in users, including the following data: 
    • The user 
    • Their current check-in status (including the building)
    • How this was last updated

Check-in source

For the end-user, the check-in source is displayed. Users can be automatically checked in without them knowing this. Therefore, Mapiq indicates how the user was checked in: automatically (API) or manually.

Manual check-in
Automatic check-in
Manual check-out
Automatic check-out

No booked shift

It can occur that a user has not booked a shift but ends up going to the office. Based on the integrated attendance solution, users can be automatically marked as being in the office and thus checked-in in Mapiq. When a user opens Mapiq, the At the office message is shown with an orange circle. The orange circle indicates that something amiss regarding their presence at the office. Clicking on the status will reveal the option to book a shift at the office (depending on the active booking policy, read more about how booking policies can impact check-in shifts in this article). 

In case a user is allowed to book a shift on the same day, the option will be presented to the user, and the building where the user is located is preselected. The user does have the power to adjust this preselection and book a shift in another building.

Located at another office

A user may decide to go to another office other than the building where they booked a shift. Mapiq will indicate this by presenting the status At another office. In this scenario, end-users can change their shifts (if the booking policy allows) by clicking on the status and clicking the Change shift button.

Data & privacy

For every check-in and check-out event, Mapiq stores the following information: 

When the user checked in/out 
Which user checked in/out 
In which building the user checked in/out 
Gets or sets the type of event (check-in or out). 
Whether this check-in/out event was logged manually or via the API

Mapiq uses these events to determine which users checked in at the office, and which users have or have not checked in during their shift. 

This data is stored for as long as the retention period dictates, as available in the Settings tab of the admin portal. 

If Mapiq does not receive any check-in data from the automatic check-in feature, it will appear as disabled in the admin portal.

The data stored is reflected in the applications in multiple ways:

  • End-users can view their own check-in status, when this was last changed, and how (via the API or manually).  
  • Connections can see when their connections are checked in. This is indicated by a 'green dot' next to a connection's avatar. This is only available after a connection request has been completed.  
  • Administrators with access to the 'shifts tab' in the admin portal can see all shifts, both on the day and in the past. They can also see which users were/weren't checked in for those buildings' shifts.  
  • Administrators with access to the analytics report can see anonymized reports about check-in.  
  • Users with an API service account can retrieve all individual check-in events for all users within their subscription via the API.  

Regarding personal data, Mapiq is the processor, whereas our client is the controller. Mapiq is not responsible for what customers do with the data.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.