LinkedIn
Twitter
Here is a prototype app to continue this conversation. (I’ve been meaning to take a stab at the school situation for awhile now). It is not meant to be a complete app but rather a starting point to continue this conversation! 
Armed with the above data model and app, someone could now create:
- actions to help ease the navigation and creation of records
- workflows to observe the creation of records, and auto-create additional data as needed
- security filters to enforce things like
a. a teacher should only see their own classes and students (in america this falls under FERPA laws)
b. same as “a” but for parents and students.
Hi, @Instituto_San_Pedro, I went ahead and added basic support for “Grades” as follows:
-
Some additions:
added “semester” to the class table. In this example, “classes” should be unique per semester, so you would want one row for “German Spring 2020” and a second row for “German Fall 2020” and so on (this is similar to real life and existing school data systems, btw) -
added images and icons to everything (that is not pertinent to the below info, just FYI)
-
added a new sheet called “Grades” with references to students and classes.
Interesting trick:
when you create a new “grade record” you first select the class. Then, the system should be smart enough to only show students in that class. To do this in AppSheet, for table “grades” and column “StudentID” we use a valid if statement as follows:
`select(studentsclasses[StudentID], [ClassID] = [_THISROW].[ClassID])`
(you will note in my example app that only two students are taking the german Spring 2020 class, the above statement returns only those two students)
Because we started this experiment with a proper data model using bridge tables, we can now start to reap the benefits of our original efforts by putting in clever calculations like the one above with a minimum of effort.
Best, -Ty
Hello again,
Please copy the app one more time (same link above). There are changes, including:
*data model changes to existing tables
*new table “emails”, new view on the upper left menu for “emails”
*actions created, new buttons created
*three example workflows created
*workflow google doc templates created
*Some expressions and calculations created
All of these changes highlight the various declarative syntax of the AppSheet platform, for example, to get started with expressions take a look at
or
for workflows:
for actions:
And so on and so forth. Please note that this is just one way to create functionality like this in AppSheet. There could be other design patterns that make more sense, or, someone else could chime in here with alternative ideas.
At a high level, this email solution is based upon a) creating new email records in an email table using AppSheet “actions”, and then b) observing changes to this email data table using AppSheet “workflows”.
Instead of providing you with a detailed lengthy document or write-up, I would like you to study what I have done and see if you can independently understand it.
In an American college, the professor might say that this work “is left as an exercise for the reader” But please do let us know, here, if you have questions or something does not make sense to your team.
Best, -Ty
@Instituto_San_Pedro can we arbitrarily enforce a rule like “all assignments will have 8 (or 12) check list items” - if yes, we could simply create 8 or 12 hidden actions. If on the other hand we need a variable NN amount of checklist items and this varies per assignment, that is harder.
From a human/business point of view, standardizing on “8” or “12” or whatever, creates a reliable and consistent scholarly experience.
