Update Field After Running a Custom Email Task

Feature Requests
1

I love how we can send custom emails by creating "Tasks". One thing missing from this workflow is a way for us to update a field after sending the email. In fact, with all custom email sending it would be good to allow us to automatically update a record's field after the email is sent.

Without that there is really no way for us to automate the following:

1 - A customer record is added to our database.
2 - Task runs nightly to send an informational email to all users who have been newly added.
3 - A field is updated to let us know that the email has been sent to that customer thus preventing a duplicate email from being sent when the task runs again.

Adding an "Update Field" action to the custom email work flow would solve this.

The other option would be to allow us to query based on the history of which emails have been sent to certain records. However, I am not clear whether Knack even tracks that info.



Welcome to hear any current workarounds if anyone has one. Right now, we just have to do it all manually.



Thanks, Kevin


2

This has been a feature request for sometime.  another workaround is to use Zapier or integromat

Create a flag field YES/NO

Task: In the case of sending an custom email. either Bcc an email to zapier mail address. Zapier parses the email and extracts records id;s and updates knack above record flag to YES (Sent)

Same with Inegromat.  Of course you'll burn up some zaps etc but its a quick way to update and prevent tasks running twice.

Of course the first task would have to check the flag first for NO.

Or running a task after the first with a say 60min interval to update the flag could work, but in some cases that hard and not reliable.

 

My 2Cents

3

Would really like to see this feature Knack too.

4

Would really like to see this feature Knack.  Having tasks be able to do multiple actions just makes sense.  In the couple of years I've been a Knack developer, I have come across countless cases where doing more than one task when a condition is met is required.

 

Sending an e-mail AND updating a field just makes sense.

 

Also, while not in line with this thread having a task run to insert a connected record AND update the current record is required.

 

Please add this to your roadmap Knack!

5

Just a thought...

Here's a small twist on this feature request that would make it much more flexible and elegant:

Allow multiple actions for a single condition.  Then when the condition is met (e.g., an email has not been sent), you could send an email AND change a field (e.g., an email has been sent), or send another email, or whatever.  

1 Like
6

Thanks.  I'll look into your potential work around.  I feel like we tried something similar without success, but I need to dig into it a little more to see what we were doing wrong.  Of course, adding an "update field" option after sending emails would make this all a lot easier :)

7

Sure, np!

Yes, first case is as described, and I would like the feature for the same reason.

Second case you can deal with, involves a few steps, as shown below. Just remember that the Record Rules run before the email rules, and they run top to bottom (ie. you have to create the rules below in the same order or it won't work!)

  • create a yes/no flag (call it Deliver Email Flag for example)
  • create a record rule to set the Deliver Email Flag to no, this *must* be the first rule
  • create a second record rule that will check the dropdown for 'send welcome email'
  •   if so, set the Deliver Email Flag to 'yes' and the Email Sent field to 'yes', and probably reset the dropdown to some default (something other than 'send welcome email')

Now you can also create an email rule to send an email when the Deliver Email Flag is Yes, which will only send when the dropdown is set to 'send welcome email'.

Its essentially an extra step but will get you what you want.

Best,

Mark

8

Thanks Mark.  Your suggestion would definitely work for a simple use case.  I still would like to have the sent flag since we have 4 - 5 different emails that get sent to a customer leading up to one of our events and it would be great for us to quickly look and see who has been sent what.  (They aren't all sent during the first 24 hours of signup and so it becomes a little more complicated.)

In terms of the second case, that is what we tried.  We created two form rules, one that sends the email when "Send Email" is selected in the drop down and then one that updates the field to "Email Sent".  The problem is that the update field always seems to take precedence over the send email rule and so the field get's updated and then the email never sends.  We tried playing with the order of the rules and such, but it didn't seem to matter.  Perhaps we are doing something wrong, but that is what our initial testing resulted in.

Thanks for the responses!

9

Well, for the first use case have a email task only for new customers that have been added in the last day (ie. make sure there is a 'Date Created' field in the customer object), running it at 12:01am the next day. That way you will ensure every new customer gets sent an email only once and you don't even have to track it (although setting a 'Sent' flag would be nice...)

You can solve the second case by:

1) assuming that the email is sent (have to test to make sure its working as expected of course)

2) Setting up a form record rule that updates the 'Email Sent' field to 'Yes' when 'Send Welcome Email' was selected in the dropdown

Cheers,

Mark

10

Another use case where this feature would be helpful:

We have a database which tracks every employee we have on our events.  When we add an employee, we need to send them a welcome email, so we created a dropdown selection "send welcome email" which triggers a custom email to be sent with the event details.  We would then like to update that field to say "email sent" but there is no way to do that automatically.  The admin user must remember to select the "email sent" after sending the email and thus save the new status.

11

Agreed, but there really is no way to know who to update with the "update field" task.  Ideally, we want to update whomever was sent the email but I don't think that history exists for us to query.  Of course, we can always just run the tasks within minutes of each other and just hope that no new customers were added within the lag time.  Not the most "fool proof" method but probably accurate 95% of the time.

12

Well, easiest way to accomplish would be to run a timed task and then schedule another separate 'Update Field' task to occur and hour or two later...

Cheers,

Mark

13

I find trying to see the history of emails sent by tasks is really tricky. I’d suggest expanding this feature request to insert a connected record with the email body as one field. This would be particularly useful in a CRM/ticketing system so front end users can see a full history of emails in a related history object.

Currently we bcc most emails to be able to troubleshoot but they are not linked to the original record.