Deep Twillio Integration

[6mp]

• This will essentially allow for there to be a messaging client in the admin portal
• If there is an unread message from a volunteer show and indicator (maybe check and see if we haven't responded, twillio doesn't have a way to see if we have read messages)
• Allow texting all the people shown in the participant roster (this also means if a filter is applied only those who qualify will be texted)

There already is code on how to send message from twillio: https://github.com/twilio-labs/function-templates/tree/main/sms-notifications

Displaying the messages received from a specific is different but it is not to bad either

[mattsahn]

I just poked around the Twilio API using Make and there's an API called "List Messages" where you can get the past N messages between two phone numbers. So, our server could make a series of API calls to Twilio to get, say, the last 10 messages that each volunteer has sent to the Grassroots Twilio number. Could further filter that based on time received to show only from the past week.

Here's a couple examples showing messages sent to GG. The frontend could then be able to display most recent messages from each volunteer. Could also include messages sent to them.

Not sure if Twilio charges for calling the API since it is just informational, hopefully not. Another approach would be to mirror all messages going through Twilio via a webhook such that every message sends a webhook that we could listed to in Make and write to Airtable to build up a live, running log of all messages in Airtable. Then, the app can query the Airtable table to get all messages at once more or less for all users in the event. @hgreenhut, thoughts?

The example setup in Make: https://us1.make.com/1989/scenarios/1537816/edit