Can I send email notifications to email addresses defined in child table?

  • 0
  • 1
  • Question
  • Updated 1 year ago
  • Answered

I would like to send notifications for an entity that has contact email addresses held in a child table. I don't think I can do this without holding the email addresses in denormalised form on the parent table - email1, email2, email3 etc. - but I wondered if anyone else had managed this. Thanks.

Photo of Jeremy

Jeremy

  • 0 Points

Posted 3 years ago

  • 0
  • 1
Photo of QuickBaseCoach App Dev./Training

QuickBaseCoach App Dev./Training, Champion

  • 60,198 Points 50k badge 2x thumb
You will  need to float up those email addresses from the children up to the parent record. This can be done through a series of looping reverse relationships and is viable if there is a reasonable maximum number of children. Say 5 or at most 10.

Post back if you would like help on how to float up those email addresses.
Photo of Jeremy

Jeremy

  • 0 Points
Thanks Mark. That's what I thought I'd need to do, but I thought I'd check.
Photo of Goizane Martinez

Goizane Martinez

  • 80 Points 75 badge 2x thumb
Hello Mark,

I have the same problem and I don't know how to float up them. Could you help me, please?

Thanks very much.
Photo of QuickBaseCoach App Dev./Training

QuickBaseCoach App Dev./Training, Champion

  • 60,198 Points 50k badge 2x thumb
How many children records does it need to handle?
Photo of Goizane Martinez

Goizane Martinez

  • 80 Points 75 badge 2x thumb
No more than 10 per record
Photo of Goizane Martinez

Goizane Martinez

  • 80 Points 75 badge 2x thumb
one trip has many bookings. I need the email of each booking to send a open notification when the trip status changes to "Confirmed"
Photo of QuickBaseCoach App Dev./Training

QuickBaseCoach App Dev./Training, Champion

  • 60,198 Points 50k badge 2x thumb
Here is an answer to a previous similar question where One Job has Many Operators

Reverse Relationship setup

The way to do this is with as many "reverse relationships" as you guess will be enough to cover off 99% if the situation.

So, let talk about Operators.  One Job has many Operators.  Make a summary field on that relationship of the Minimum of the Record ID# of Operators.  Call it [Record ID# of Operator 1]. 
Then do a lookup of that down to the child Operator table as we will need it later.

Then do a new Relationship where one Operator has many jobs. For the reference field (the field on the right side), use that new Summary field called [Record ID of Operator 1].  Get rid of the extra fields that get created on the left side of the relationship (Add Operator and that report link field).  Do a lookup from the Operator down to Jobs and bring in the Operator Name and call it Operator 1.

Wonderful, the Job now knows the first Operator.

Now, make a duplicate of that summary field, but in the duplicate add the extra condition that the [record ID#] is greater than the [Record ID# of Operator 1].  Call it [Record ID# of Operator 2].  Do a lookup of that field back down to the Child Operator table as we will need it later.

Now, in making that duplicate, conveniently, you will find that it duplicated the reverse relationship so now do a lookup in that relationship of the operator name called it [Operator 2].  Wonderful again, we now have Operator #2's name on the Job Record.

Then make another duplicate of that summary field and just keep going, each time changing the filter so that the record ID# is greater than the previously highest record ID of Operator.

In the end say you collect the names of the first 4 operators on a job, so then just string them together in a formula like

List ("\n",
[Operator 1],
[Operator 2],
[Operator 3],
[Operator 4])

 and put that concatenated field list on your report.