Attendance tracking

If you’re looking to have it entered by form, the most obvious option is to have fields for each person and duplicate the “reason” single-select field for each person. Each record would be based on the date.
Unfortunately, there isn’t an easy way to do it “properly” within Airtable. Alternatively, you could use Google Sheets for data collection, and just copy it over to Airtable at the end of each day (or use Zapier to automate this).

We run a language school in Spain and we do it like this:
Each Student is a record, each date is a dropdown field. Options are present, absent or late

@Trent_Meekin Does part of your question also include how to automatically register if someone is present? In that case you can scan a QR code into Airtable, and have the exact date and time in the field Created Time.
Based on that you can fill another field by formula with information at your preference.

Trent -

Here you will find a demo attendance tracker base with which I’ve been futzing about for the past week or so. I suspect my experience of this base is much like yours: I can think of a number of ways to organize it — and they all suck. In this demo base, I manage to have it suck several different ways at once.

Clearly, if your staff list is relatively stable, and the only two variables from even to event are (1) the event and (2) the employee’s presence or absence, it only makes sense for your [Attendees] table to be the central one for the base. So that’s how I began: A table of attendees 250-deep, thanks, as always, to FakeNameGenerator.com.

Based on my assumptions as to how you management would most like to see the data presented, my first inclination is to go with what would ordinarily be considered a poor design, in that each event would have a dedicated linked record field defined in [Attendees], as so:

Each link in the preceding table would be a linked record between [Attendees] and [Reasons]; each record of the latter would record a given users’ reason for attending or not attending a specific event.

I played around for a while with these values, trying both an approach where the first character of each link (that is, the first character of the name of that [Reasons] record) was either ‘✅’ or ‘❌’ as well as one where ‘✅/❌’ was displayed in a separate lookup field. In the end, I chose to go with the latter — which meant each link field in the table was now prefaced with an accompanying lookup field:

Probably I am made most disgruntled by this base because of one annoying flaw (design feature?) in Airtable: Namely, that when one adds a new record to the base as a drill-through from another table, Airtable does not honor default values defined for fields in the linked table. For instance, I would like to be able to set the default value for {Reasons::CurrentEvent} to equal 'Event1'. Or, rather, that’s what I have done — yet when I click on the plus sign under {Attendees::Event1} and select ‘+ Add new record’, when the [Reasons] record expands onscreen, {CurrentEvent} remains empty. If it only would self-populate, it would make the work flow so much more friendly.

As an alternative, you can go directly to the [Reasons] table and generate a dozen or so empty records. Then, rather than creating a new record when updating a attendee’s status, you chose the next unallocated record. The only difference is you have to double click on the record rather than single click.

In any case, since {CurrentEvent} refuses to self populate, I couldn’t see any reason to avoid using records link to the [Event] table, as it’s all manual, anyway. So the base I prepared includes both a two-table solution ([Attendees] and [Reasons]) and a three-table one (also includes [Events]). But, as you noted, there aren’t any truly satisfying solutions here, oddly enough. (It seems as if it would be child’s play to put together this app. But, no…)

In any case, here 'tis. Maybe something in it will inspire you more than it did me. Sorry…

Do you think this is a flaw? I hope so, because I run into the same problems with my forms. If it is a flaw, it can be corrected. If it is a new feature, it may take a long time before Airtable has developed it.

Honestly, I don’t know. I’ve not heard anything from anyone at Airtable nor read any general mention indicating which this behavior should be considered. I suspect it’s simply not-well-thought-out intentional behavior; at the same time, though, I would have to think it could be treated as a bug and corrected, as I find it difficult (although not impossible) to conceive of a use case built around the assumption a default value would be ignored when creating a linked record but honored otherwise.

Hmm… I’ve seen it before in postings. More users seem to have similar problems with this issue.
Hopefully Airtable will come up with some statements concerning this topic.

I’m looking into a barcode scanner to solve the same problem. Each student here has an ID badge so if I add a barcode to the back…

We built a barcode scanner for Airtable that would be ideal for tracking attendees. Every time you scan a barcode, it’ll be logged in Airtable.