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:
| Name |
Event1 |
Event2 |
Event3 |
Event4 |
| Name1 |
link |
link |
link |
link |
| Name2 |
link |
link |
link |
link |
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:
| Name |
P |
Event1 |
P |
Event2 |
P |
Event3 |
P |
Event4 |
| Name1 |
:white_check_mark: |
link |
:x: |
link |
|
link |
|
link |
| Name2 |
:x: |
link |
:white_check_mark: |
link |
|
link |
|
link |
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…
