I’m noodling on an idea to have a Cloudflare Email Worker watch an email address and process items it receives into Entities in Fibery. However, I’m not super familiar with this style of coding and how to get around CORS and other challenges…
Rather than continue to beat my head against a wall, I’ll ask: Has anyone in the community done something similar and may be able to post some psuedo-code that worked for them?
Thanks!
Is there a reason why you wouldn’t utilise the Fibery email integration?
This was my first thought as well, however in practice, it didn’t seem like it was possible. When I set an automation up in Fibery, watching an inbox, my only option for a “Task” related action was to update what Tasks link to the Message (see attachment).
I have a 1:m relationship set between Messages and Tasks already, as I thought that might have been the issue.
I’d imagine I could write a custom script that accomplishes this natively in Fibery without messing with Cloudflare. Maybe that’s where I’ll start…
The nice bit about Cloudflare is that it allows me to have a (or several) dedicated address like fibery@mycompany.com without me having to actually pay the monthly cost to have that inbox, via Gmail or the like. It can watch for any email traffic and filter / route those regardless if an actual inbox exists for them.
I’m not sure what you mean exactly. What would you like to happen when a new email message arrives?
Sorry for the lack of clarity there!
When an email arrives, I would like to create a “Task” entity based off of data from the email. It’s subject would be the name of the Task, it’s body the Task’s description field, and so on.
I’ve got a relationship setup between Messages and Tasks in Fibery, but there doesn’t appear to be an option, within Automations, to create a Task when a Message is created. I was trying to illustrate the options I have related to “Tasks” in my screenshot above, and my only choice in the automation is to update which Task the created message is related to.
Is the relation an ‘auto-relation’?
If so, you can’t add new linked Tasks (or unlink existing ones) since they will be linked/unlinked according to the criteria for matching.
Ah, I believe it WAS the auto-relation screwing things up. I’ve disabled that for now, and the ability to create a Task from an email is now showing in Automations… HOWEVER… 
My end goal is to have an email address that I can forward stuff to that will get processed into a Task. Thus, I’d love a “Message” entity to be converted to a “Task” entity. Automations get me close, but the one issue is that there’s no way to populate the Description field of the new Task entity with the email body from the Message.
When viewing the Task, I suppose the “source” Message would be linked as a relation, and then you could open that Message for more details on what the Task actually is. Not the best experience, as it hides the Task’s most important info behind some scrolling and clicks.
Add an automation in the Task db that runs on creation and the action is to overwrite the Description field with the email body, using markdown syntax e.g.
{{Message.Body}}
One of the big limitations to Fibery’s current email integration is the lack of any support for email headers.
Thus you will probably not be able to do things that would require identifying particular email threads.
But if headers aren’t needed, it should work fine.
I’ll give this a try! Good idea… Curious, since there may be multiple messages attached to a Task, would it still be {{Message.Body}} to add it to the description?
Thanks for all the help through this, Chris!!
Yeah, this is my holy grail! I’d love to be able to determine threads, so that all messages with my clients about a certain Task could be collected into a single thread in Fibery automatically. But in the meantime, I can kinda fake it
If a Task is linked to multiple Messages, it might just be easiest to use a feed view for the Messages relation field - that way you can see the Messages’ rich tect content from within the Task, without any automation necessary.
Great idea! I didn’t think about using Feed in that manner – thanks Chris!