campusM Attendance FAQ
Notifications
How many notifications can I configure?
You can configure up to 3 notifications per event. The timing of these notifications can be configured before or after the event start time.
What happens if a student checks in before a reminder notification is due to fire?
When a student checks in to an event, any outstanding reminder notifications for that event are deleted, so the student is not unnecessarily asked to check-in.
Are these notifications app notifications or SMS messages?
The Attendance notifications are local push notifications created by the campusM app. They are created and refreshed each time the timetable is updated on the student’s device. They are not sent using over-the-air notification delivery methods, rather they are created locally on the device. This has the advantage of firing even if the student is offline and unable to receive traditional SMS messages or over-the-wire notifications. It is also free of charge.
Student and Lecturer Check-in
Can a student check in if they arrive late to an event?
The student can check in to an event if they are within the check-in window. (This is the padding around the event start and end time that the institution can set that defines the check in period). If they arrive after the check in window, they have the option to consult with their lecturer, who can check them in through the lecturer check-in interface up to 7 days after the event (if this has been enabled by the institution).
Can a student check-in without a mobile device?
Students can use the Web app as well as the campusM native app to check in to an event, unless the institution selected Crowd Source Validation as the only validation mechanism. In this situation, students are asked to download the native app due to the requirement for Bluetooth and iBeacon visibility.
Can students mark themselves as absent from an event?
If the institution has enabled absence reasons within its attendance configuration, students have the ability to select from a predefined list of reasons for their absence. This is recorded and available through the checkInReport API.
Can lecturers mark students as absent from an event?
If the institution has enabled absence reasons within their attendance configuration, lecturers have the ability to go into the event and select from a predefined list of reasons for absence for individual students. This is recorded and available through the checkInReport API.
Validation Mechanisms
What validation mechanisms are compatible with what platform?
See the following compatibility matrix:
| Mechanism | Platform | |
| Web | Native | |
| One Time Code | Yes | Yes |
| QR Code | No | Yes |
| Geolocation | Yes | Yes |
| Crowd-source | No | Yes |
| IP Validation | Yes | Yes |
Depending on what other mechanisms have been enabled, the web app prompts the user to use the native app where no other compatible validation method is enabled.
How does QR code validation work?
If enabled, when a student attempts to check in on their mobile device, the check-in button appears as a Scan Code and opens a live camera feed read for the code to be scanned. The user scans the location QR code to be checked into the venue.
The QR code presented to the student must be a text encoding of the location code returned by the timetable for the event requiring validation. It can be used in conjunction with the One Time Code validation as an either-or option for checking into a class.
Like the One Time Code, QR code validation is a client-side validation and has an AND logic relationship with selected cloud-side validation.
How does geolocation validation work?
We use HTML5 geolocation services (campusM Web App) or device GPS (campusM Native App) to determine users' positions when they make a check-in. This is then compared to the known position of the event venue to determine the distance users were from the known location at the time the check-in was made. If this distance is within the defined tolerated range, the check-in is considered valid. If the check-in was made outside of the tolerated range, it is considered invalid.
The QR code for each location must be based on a text encoding with the following format:
{locationRef:"LOCATIONREFERENCE"}
Where the LOCATIONREFERENCE is the customer loc code parsed in the timetable integration feed. The QR check-in type validation is considered valid if the scanned LOCATIONREFERENCE matches that for the class in the timetable. If not, it is invalid.
What are the default tolerance distances?
The default distances for the geolocation validation tolerances are:
- Low - 50m
- Medium - 250m
- High - 500m
These are distances from the latitude and longitude coordinates for the position defined in the app (and as such describe a radius around which a check-in would be considered valid).
On the client, when is the status changed from Pending to the actual outcome for that check-in transaction?
Pending is displayed until the processing is completed, which is approximately 15 minutes after the end time of the event. This is because the batch process is completed after the event close when the majority of the check-ins are made.
Do we need GPS active for crowdsourcing?
Yes. Location services cover all location-based technologies, micro (iBeacons), and Macro (GPS, HTML5 Geolocation), so by switching on permissions for this service, we can then access one or more of these location technologies. For iBeacons, Bluetooth is also required.
Do we need Bluetooth active for crowdsourcing?
Yes, the micro-location technology we use for crowdsource validation (iBeacons) is a Bluetooth-based technology. We therefore need Bluetooth enabled on the device in order to be able to capture the visible beacons at the point of check-in.
Do we track the students' locations?
No. We only capture students' locations if Geolocation Validation is enabled, if the relevant permissions are enabled on the device, and only at the point of check-in. We do not constantly monitor or capture students' locations within the app.
How does crowdsource validation work?
Crowdsource Validation uses iBeacons micro-location technologies to identify if students scheduled for an event are collocated with others in attendance. When the student checks in to the event, the device captures the beacons that are visible with the defined UUIDs. This is uploaded to the cloud ready for processing.
The event is processed within 15 minutes of the close of the check-in window for the event. At this stage, the crowdsourcing algorithm compares the beacons visible for each of the students who checked in to the event. It then identifies valid beacons for the event based on the number of students who collectively saw each beacon. The validity level is based on consensus – that is, the percentage of students who checked in who could see a particular beacon. This percentage level is set on the configuration page.
Note that whilst the check-in window is open and pre-processing, the status of the event will be shown as the status set for 'Processing'. The terminology can be modified in the check-in history configuration.
| For a class of 100 Students, Where the Valid Percentage is Set to 50 | Number of Students Who Captured each Beacon | Proportion who Captured Each Beacon | Validation Status |
|---|---|---|---|
 |
70 | 70% | Valid Beacon – ANY student who sees this beacon is considered valid. |
| 25 | 25% | Invalid Beacon – Any student who ONLY sees this beacon is consider invalid. |
Services
Why does the EventID have to be unique?
The Event ID is the shared key used to link event instances between the student and the lecturer. It is also an invaluable reference key when combining the captured data from our CheckInReport API and your timetable data to develop the overall picture for attendance monitoring.
The eventID is used on the client to identify each instance of the event from other instances of the same class in the following weeks. It links the event to the students in the class and the lecturer delivering the class, so that lecturer check-in page retrieves the right students for the event and that any check-ins made against the event are shown for both student and staff interfaces.
How does the app know what location to check against for geolocation validation?
For Geolocation Validation, we require that the timetable service return a location reference. This location reference is a unique identification that should also be found with the app position, along with the positions' known latitude and longitude.
When the student checks in, the device captures the current latitude and longitude and provides it as part of the check-in transaction, along with the events location reference. A check-in validation algorithm then compares the captured location with the location of the positions referenced by the location reference and identifies whether the check-in was made within tolerance or not.
What does the attendanceExclude flag do?
The attendanceExclude flag is an optional field within the timetable service that identifies if a particular event should be considered optional (if TRUE). You can then configure the behaviour in the Attendance Configuration as to whether to consider the event as optional, or to exclude it completely from the Check-in process.
The Suppress Attendance Excluded Events check box enables you to remove the events completely from the check-in screen and process for events where the attendanceExclude flag is TRUE.
Left unchecked, and the attendanceExclude flag is True, the class appears on the students' check-in page and they are able to check in to the class, but they do not receive the reminder notification and the event has the status of Check-in not required on the check-in history page (unless the student checked in, in which case they see the check-in outcomes as per other (mandatory) event.
Is it possible to assign more than one location to an event if the Geolocation Validation is selected?
No. Each location must have a separate row returned by the service if the location is to be used for validation purposes. Only one location reference can be returned per event listing.
Is it possible to assign more than one lecturer to an event?
No. Like student timetables, each lecturer must receive an individual timetable list and therefore the service must return the event for each lecturer who is scheduled for the class.
How can I differentiate students in the lecturer’s attendee list if they have the same name?
We suggest that customers append a student ID number or some other unique reference data item in either the Given Name or Surname fields of the Retrieve Attendee service. For more information about the Retrieve Attendee service, see Retrieve Attendees for Events.
What do the various statuses mean for the checkInStatus field returned by the Check-in Report API?
The following Check-in status and their definition can be returned for the checkinStatus in the checkInReport API:
| Status Returned | Definition |
|---|---|
| Validated | Selected validation mechanisms were assessed and the outcome of the check-in was considered valid. |
| Invalid | Selected validation mechanisms were assessed and the outcome of the check-in was considered invalid. |
| Synced | The user’s device was unable to provide the required validation data so we were unable to assess the outcome for the selected validation mechanism. |
| Unvalidated | Assessment of the validation outcomes has yet to be processed for this check-in transaction. Note that the batch assessment process that evaluates if the students were valid or not when crowdsource validation has been enabled will occur only within 15 minutes of the close of the check-in window. |
| StudentAbsent | Student has marked themselves as absent for the event. |
| LecturerAbsent | Lecturer has marked the defined student as absent for the event. |
How do we use the resumption token to extract data from the CheckInReport API?
In order to provide a responsive API service for retrieving large data sets, for example, attendance check-ins over 7 days or Insight data for 7 days, we paginate the response, sending 50 check-in transactions per request.
This means that customers will need to script the extraction of data, to call the API repeatedly to retrieve the check-in data in batches of 50 transactions.
If there are more than 50 transactions, the response will include:
<ns1:isFinished>false</ns1:isFinished>
Followed by a resumption token that then needs to be added to the next request to retrieve the next 50 records.
<ns1:resumptionToken>NzkxMSQxNjg4MzQyNDAdwedewfi7uhwefiuhgwefgyMDAwMDAkbnVsbCRudWxsfDEwMA==</ns1:resumptionToken>
This should be repeated until the isFinished flag returned true, indicating that all records have been retrieved.
<ns1:isFinished>true</ns1:isFinished>
Other
Can I configure different validation mechanisms for different classes?
This is currently not possible. All events will have the same attendance configuration applied to them. The setup is universal for all events (though note the attendanceExclude flag does enable an event to be flagged as non-mandatory.