You have questions.Answers are here.

The QR is dynamic: the server regenerates it at the interval the lecturer picks, so a shared image expires almost at once. Each student’s phone is registered to the account; a QR scanned from another phone is not accepted, and the device can be changed at most twice a term. Several signatures from one phone are flagged.

Your institution picks the rule: off, advisory or required. Advisory measures the distance but never blocks a signature. In required mode a signature from outside the faculty area is refused on the spot; the area radius is set in the panel. Measured signatures are later compared with the session’s own location cluster.

Student, course and enrolment data are imported from the SIS every day. Signatures are written to the SIS every night. The live connection today works with Proliz OBS.

No. DAS records which class hours a student signed and sends them to the SIS. The attendance decision belongs to the authority set by regulation and to the SIS.

Yes. SAML single sign-on, LDAP and Active Directory are supported. Administrator sign-ins require an extra verification step.

Late-open, make-up and correction requests go to student affairs, and nobody can review their own request. Appeals are tracked with the working-day limits your institution sets. Every correction is written to a ledger with the previous and new record.

Every role sees only its own scope. Audit logs are kept for two years, and irreversible admin actions are confirmed with an e-mail code. Repeated failed sign-ins lock the account for a while.

In dynamic mode the code in a photo works only for the rest of that interval plus 10 seconds, then it is rejected. A signature in that window still faces device binding and your location rule. DAS does not block photos; it keeps them useful for only a few seconds.

The panel accepts a value between 5 and 30 seconds, with 10 as the default. A shorter interval also shortens the time a shared photo stays valid.

No. Everyone in the same roll call sees the same code in a given interval. Who the signature belongs to is set by the student’s signed-in account and registered phone.

The lecturer picks 3, 5, 10 or 15 minutes, 10 by default, and the maximum your institution sets in the panel can never exceed 60 minutes. A lecture roll call does not stay open past the end of the class hour plus your grace period, and it closes at the latest 60 minutes after opening.

Your institution chooses this per education level in the panel: during the class hour only, during the class hour and for a set time after it (0 to 720 minutes, 120 by default), or any time in that week. The default is the narrowest, class hour only.

No. The student sees the time the roll call closed and is asked to tell the lecturer if they were in class. The lecturer can then add them by hand with a written reason.

No. The dialog says “Do not count the class.” The lecturer types the “Participants” number shown on the right, and both the declared and the listed number are kept as evidence.

A “Numbers do not match” dialog opens and the roll call stays open. The lecturer types the number on the list or adds the missing person; there is no option to skip this step.

No. A manual signature goes to the course the student is enrolled in, and an unenrolled student cannot be added unless your institution has turned on the matching exception in the panel. Every add is written to the correction log with its reason and author.

“Pause” stops signing; a student who scans meanwhile is told to scan the new QR once it resumes. “+1 min” and “-1 min” change the time, and an extension can never go beyond the roll call’s latest closing time.

The screen keeps showing the QR code and signatures by refreshing every few seconds. Meanwhile time changes and pause are disabled, while “End Attendance” still works.

Yes. Choose “Outside Class / Event” in the start dialog and enter the event title, type and venue.

No. On a campus network hundreds of students share one IP address, so DAS never looks at IP addresses. It flags only when the phone’s own identity matches.

Not on its own. Siblings sharing a phone or a borrowed phone can trigger it; in the system administrator’s report the flag sits at “needs review”, and the lecturer decides.

They delete the old device under “QR Device” in settings, and the new phone is registered at their next signature. If both changes for the term are used, the course lecturer can grant one more with a reason; no visit to student affairs is needed.

Once per term: on the day course registration opens in the academic calendar, or on the term start date if the calendar has no such day. The counter resets and the student starts again with 2 changes.

Student affairs can grant a change or reset the counter within its own faculty or department, with a separate permission. System administrators can increase, decrease or reset it. Every action needs a reason of at least 5 characters and goes to the same audit log.

Detection relies on the mobile app sending a per-phone identity. Fake or placeholder identities are ignored, and a phone whose identity cannot be read is shown separately as an “Unknown device” on the live screen.

At signing, the distance is measured from the coordinate in the address record of the course’s faculty. If that faculty has no coordinate, the signature is not refused.

By default, yes: a signature with no location or no measurable distance is not refused. If the institution turns on “Do not accept signatures without location”, required mode refuses it and tells the student the lecturer can add them to the roll call by hand.

Not on its own. DAS offers it as decision support; if the student was in class, the lecturer counts the signature as valid with a reason.

Each signature shows its location state, such as “Far from the class location”. If any signature is not counted, a summary arrives on weekdays at 09:00 as an in-app and push notification; students are not notified about it.

The institution picks between 0 and 3650 days, where 0 means no limit. When the period ends only the raw coordinates are deleted; the signature and its distance assessment stay.

Points farther than 2 km are never drawn at their exact spot; they are grouped by direction and distance band, and the distance is rounded to 100 m.

Faculty student affairs approves requests for courses in its own unit. A system administrator can also decide; that decision is marked as made under system administrator authority and student affairs is notified.

Draft, awaiting student affairs, returned to the lecturer, approved, rejected and applied. An applied request can be revoked with a reason, and open requests close on their own when the term ends.

Student affairs is notified when a request is submitted; the lecturer is notified when it is returned, approved, rejected, applied or revoked. Notifications are in-app and push, and returns and rejections include the reason.

Your institution chooses: the lecturer opens it directly, only student affairs opens it, or it opens through request and approval. Request and approval is the default.

Only one request can be open at a time for the same course, type and target. The request list can be exported to Excel.

Filing is within 3 working days of the roll call in question and resolution within 5 working days of filing. The deadlines are stamped on the record when it is filed and never recalculated. If resolution runs late, the reviewer must explain the delay.

Not alone. Student affairs or a system administrator resolves the appeal; the lecturer is notified only when information is requested from them.

No. An exemption belongs to a student and covers the days they were on duty or administrative leave. An excluded course is a course kept out of the attendance system.

System administrators and authorised student affairs staff, within their own scope; both sign in with two-step verification. Only the active term can be changed, and past terms are read-only.

A system administrator edits the list, uploads it with the Excel template or copies it from the previous term. Student affairs opens requests that the administrator approves or rejects, and each bulk change can be undone in one click.

The old and new signature record, the action, its reason, who did it and in which role, and when. Student affairs sees these entries in the “History” area of the student detail page.

Today DAS runs with the Proliz SIS. If your institution uses another student information system, we can look at your needs together in a demo call.

The change arrives with the next data package. A student who leaves a course list is not deleted but marked as dropped; they can no longer sign, and their earlier records stay in place.

A record that got no answer stays pending and is tried again on the next send. A record the SIS rejects is marked failed; the “Why was it not sent?” screen shows what is missing in DAS and what the SIS rejected, each with its reason.

The SIS offers no delete call. The course is marked for withdrawal, its records are listed for student affairs to remove in the SIS, and the fix is confirmed afterwards.

The transfer screens are open to system administrators only and need a session with two-step verification. The SIS key stays on the server and is never shown on any screen or log.

No. The password is checked by the university’s identity service at every sign-in and is not kept in DAS. Password changes happen on the university’s account page.

SAML single sign-on and LDAP / Active Directory. For a new institution the connection is adapted to its identity system.

System administrators, student affairs, system observers and mobile administrators. The step uses the institution’s SSO verification or an e-mail code; if the institution turns it on, system administrators and student affairs can also approve on a paired phone.

No separate role exists. Top management uses a university-wide view-only template, while faculty student affairs and department heads use templates limited to their own unit, all in the same panel.

They do not. Once the student is registered in the SIS, they arrive in DAS with the next data import and sign in with their institutional account.

By default a web session closes after 20 minutes without activity. System administrators can set this between 5 and 120 minutes in the panel.

Excel, PDF and CSV. Lecturers get the course report as Excel or PDF on the web and as CSV or PDF in the mobile app; system administrators download lecturer reports as Excel and activity records as CSV.

No. Exported documents print no attendance rates or percentages; they give signed and unsigned class hours as counts.

Yes. The “Email Reports” screen sends Excel or PDF reports to lecturers right away or on a schedule, with recipients chosen by faculty, department or person. A bulk send needs an extra e-mail code from the system administrator.

System administrators in a two-step session and read-only system observers. Records can be filtered and exported as CSV, and the export itself is recorded too.

Two years by default; the period can be changed in the installation settings. Failed request records are kept separately for 30 days.

In-app notifications, push notifications to the phone and e-mail. There is no SMS delivery.

Lecturers see only their own courses, students only their own record, and student affairs only their assigned scope; system administrators manage the whole system and system observers view it read-only. A signature’s location and device details are visible to that course’s lecturer, and national ID numbers are masked in the lecturer’s signature list.

Push notifications to phones pass through Google’s Firebase service, which receives the notification title and text. E-mails go through the e-mail delivery service set up in the installation; maps use Google or Apple in the mobile app and OpenStreetMap on the web panel. In the current installation the web panel also loads Google Analytics to measure visits. If the institution turns on the foreign and VPN block, the sign-in IP address is sent to an external IP location service; Google Places is used when an event location is entered, and Open-Meteo for the weather in the mobile app.

In the current installation DAS runs on the university’s own server, and the database and uploaded documents live there too. The panel and the mobile app connect to the server over HTTPS.

Only while the app is open and the student joins a roll call. If the institution sets a retention period, raw coordinates on class signatures are deleted when it ends and only the near or far result remains; without a period, coordinates stay stored.

No. Signing involves no biometric check. The mobile app offers an optional app lock; the phone’s operating system does the check, and no biometric data reaches the app or the server.

Yes. Sessions live on the server and can be closed centrally. Users see and close their own active devices; system administrators can close a user’s sessions or lock the account with a written reason.