Mandrill is the old, 3rd party service that System Default (Google Chime) is replacing.
It’s similar to how the new PDF engine is replacing PDF Rocket. But the new PDF service is an opt-in for beta testing, and this workflow option is a UI setting.
It should be a 1-to-1 replacement, but there are minor bugs still being worked out. I recently had to switch back to Mandrill because emails with hyphens are not getting delivered.
We obviously need your involvement for this. This optional control over the email workflow is new to everyone. We presume the default is Google hosting email delivery service while Mandrill is old mail services. Primal mail service behind email workflow was shifted from Mandril to Google recently, but unfortunately, there is a bit buggy behavior which interfere the use of workflow to submit emails from apps.
I m pretty much curious about your intention behind, placing the oprional toggle control button to the workflow.
Out of my complete guess, we retain the control to swtich back to old service while we see the outage or interuption on the new mail service, as back up, until the new service does the jobs in a stable manner?
What is the recommedation from to set this up, to leave it as default rather than Mandrill ?
Why are we instantly opted into the new service? I mean should default to the old system until the new service is validated. I mean even the new service isn’t really a beta feature should have some communication about it before we just get thrown into it. The old service worked X way so you base you’re expectations on it working X way, always.
Just noticed this and also noticed that my (MS Word) email body templates which have been very carefully crafted and had been working just fine are now inserting every embedded image as an attachment to the email (in addition to displaying them within the message) when using ‘System Default’. I switched to ‘System Mandrill’ and the issue goes away. Phew!
Hey AppSheet, don’t you think it would have been better to leave our existing workflows to use the legacy Mandrill system for now if there is any risk of affecting longstanding template behavior?
^my point exemplified! Our only issue so far has been delays in our emails sent but that is something that would be very disruptive.
I apologize for the inconvenience here. We simply did not predict the issues that have popped up on some of the email corner cases with this migration. We followed a pretty standard process of rolling out slowly, monitoring for problems, and then increasing the rollout as we would with most new features. We even ran into some technical issues where we reversed the rollout, got them fixed, and then continued. We thought we were in the clear when more than 90% of users were switched with no issues.
Meanwhile, that last 10% or so has uncovered a few more issues that we are working through, and we were manually switching back to Mandrill as a workaround for a while, but decided that it would be better to let users have some control of this so that they could switch back more quickly than waiting for us to get it done. Actually, it’s a very small percentage of users that have had to switch back…I don’t have the numbers handy, but it is only a few out of tens of thousands (much less than 1%).
We will get the remaining technical issues solved as soon as we can, and the hope is that folks can get 100% migrated to the default option without any further disruption.
Once again, I apologize that we did cause some problems for you that were not anticipated better. We are learning from this and hope to minimize this kind of disruption going forward. As you all know, there is always a fine balance between keeping everything exactly the same so that it can be stable, and moving forward to get the things done that need to be done and adding new functionality, which is riskier. We are continuing to enhance our test cases and attempt to improve the quality of every release. Thanks for your patience as we work through this.
So, yes @tsuji_koichi - you are correct in your analysis. We have provided a way for you to switch back to the old service (Mandrill) as a back up while we work out the last few remaining technical issues.
Thanks again for your patience,
Thank you very much for your detailed explanation and taking time for this.
Your statement is perfectly making sense to me.
Once the development is completed, i.e. making pefectly sure the bugs are not happening, and new mail service works in a stable way, I understand this optional control currently given to us shall be removed and the appsheet will be working solely on the new mail services where we no longer will know where the mal services wil be running. Hope it wont be far away, should be soon to complete this migration.
Thank you again.
Thanks for all you inputs.
We are currently working on 2 known issues with the Default/New (Google’s) email Service provider.
- Sending emails with one or more attachments > 25 mb limit. The fix should be in this week or early next week
- In some cases, emails with tables were not formatted correctly with new provider. We are working on the fix and releasing shortly.
Once we have these fixes in and bake for few days then we plan to silently remove the Mandrill option and route all the emails through Default Provider. Our recommendation is unless you see any issues stick with default option as thats going to be the only option going forward.
Meanwhile, please let us know if you any new issues with the default/new email service provider. Hope this helps.
@Jamie thanks for raising the issue. We are looking into it now.
@Austin_Lambeth do you still see delays in email deliveries.
@Harsh_Ch Hello… I am observing the email delays in my Inbox since Monday… This happens with emails containing pdf attachments only. The average time for me earlier used to be around 2-3 mins max… Currently it takes around 18-22 mins to be delivered.
I have already raised the issue with firstname.lastname@example.org yesterday evening.
Do I need to change to Mandrill or leave the default option selected??
Hello @Harsh_Ch, i’d like to report a new occurence, but this one happened using Mandrill
I received no emails while using a workflow with a pdf attachment, tried a few more times and later i received all my requests at the same time, and they didn’t arrive in order either as seen in the screenshot.
That, combined with the current state of the “test” screen for me, which only produces an output when there’s an error in my template, and doesn’t inform me when the workflow runs correctly as it used to do before, left me in a state of complete mystery for what is my app currently doing
We have made a change on our end to alleviate the email delay issue today. Can you please let us know if you see any email/SMS delay going forward?
Hi Sai, we had workflows scheduled at 6am with no previous issues but this morning some did not arrive until close to 8am
@Daisy_Ramirez : Thanks for letting me know. I’ll take a deeper look into why it is happening. Can you please paste the
Show Original for the email that was delivered late? We’ll try and dig deeper. Also please indicate when it was sent so that we can compare it in the backend
Hi Sai, should I send it into email@example.com?
No worries. I see there’s already reference here on the issue. Documentation is on the way…
@Daisy_Ramirez : Thanks for sending the data. Can you also please tell me when you initiated the action so that I can understand how much delay is present.
Hi Sai, the report workflow was set to generate at 6am central time.
@Daisy_Ramirez : We have made a couple more changes on our end to help the delay issues. Please let me know incase you still see the email delay issues.