NiceDuck

With that setup, the view will technically match each of the records from Table A to each of the records from Table B, since they all have '1' for the connector fields. The criteria will then remove records from which the actual matching records will then be excluded. In that sense, the view will only keep records from which the the actual (match/equal) are excluded. I would advised against this though for tables that are already saturated with records. The total number of records you will have will be: (table_A record count x Table B record count) - a total of matching records between the two tables.

What I would try to attemt. 1. For the actual join, I would use a connector field. In both table, there will be an extra field named 'Connector'. All records will have a value of '1' here. 2. In the View, join them using this connector field. 3. In the criteria, use a condition there to filter out records where the actual fields for joining (ex. ID to Foreign_ID) are equal.

Referential Integrity https://howto.caspio.com/tables-and-views/relationships/relationship-settings/ Make sures that a record can only exist in the child table if it has a properly defined parent record from the parent table. Values in the #inserted are yet to be recognized as a record in the parent table since it will only be officially included on the table when the trigger ended. Before that, if the trigger itself tries to insert it in the child table, the referential integrity will block it and will then cause the error which will prevent the record to be inserted on the parent record as well.

This would fail if the parent table and the child table have a relationship in which the 'Referential Integrity' is enabled.

We really need a proper 'ISNULL()' block. Creating all of those condition blocks just to replicate the same function feels too stuffy.

My suggestion above is what is more commonly used. HOWEVER, The first suggestion by @ParkLoey above is way better and more efficient for the trigger. Unless you have specific restraints, prefer to use that setup instead of the one I suggest above.

The other idea here is to put an extra yes/no flied in the table which will indicate if the record has already got an email. If the checkbox = false, it means they haven't had an email yet. after sending an email, update the record to have a check in that field.

The idea seems possible. Though I'm afraid that the line/column for the students details and the details for Teachers will line up in different columns. The idea I have in mind are the following Person (all records) > Teachers (matching only) Person (all records) > Students (matching only) Teachers (all records) > Class (matching only) Students (all records) > Class (matching only) This would basically a bunch of left join though I visualized the setup through Task/trigger and not view. Anyway, I hope it helps.

This is the first time I heard of that setup. The whole Idea seems to be an internal process, hence I suggest that you bring that up to the support. Though they may have to coordinate that to their Engineering or Internal team to further discuss.

OH! and adjust the conditional statement for the flag as well from 6 to 8. I hope this helps!

The only notable difference I see on this one compared to this: is the 2 weeks period. In that case, we just need to apply a filter on the same task so that it would only include records starting from 2 weeks ago. Use the same Task here: But apply this adjustments:

Since the the Table/list came from a table variable, I'm afraid I don't think we can modify it to simply highlight the ones that has less than 6, hence I added a 'Flag' column instead to easily mark them.

I forgot, make sure to use HTML to the Email set instead of Plain text so that the table would look better.

Heres the sample resultI got from the email, assuming my email is assigned to the name Mark.

You may want to try this: