2

I had a small error in my email sends recently that stopped over 50K emails from going out because there was a crazy unlikely Ampscript error on 2 of the messages. I completely understand that this is the way they set up their system and it is more secure to do it that way.

What I want to know is if there is any way that we can use something like RaiseError() to skip emails that have invalid AMPScript or otherwise error at send time. I would even be good if we can have something that would trigger an email to alert my team about the error so we can immediately address the issue.

I have talked to support and so far no one there has been able to provide a solution or work-around for this.

I think my main question would be if there is some sort of flag that I can trigger a script to go on for when a send fails.

For example (completely fabricated):

%%[ IF _messagecontext == "ERROR" THEN

RaiseError("Invalid Function", True)

ENDIF]%%

or if there is some way I can create an automation to check send logs against scheduled sends and provide an alert if a send was supposed to go out, but did not actually send at the appropriate time. Please note I do not have Journey Builder, only Automation Studio.

3
  • What was the AMPScript error? Commented Sep 12, 2016 at 18:24
  • Long story short, The error was that in the subject line we had an AMPScript IIF function that was using the MSWord double quote (which was displaying as a special character) instead of the generic double quote so it threw an error. This was only on the 'false' part, which only affected 2 people. But because of those 2 people, all the messages failed. The error has been solved, and we are working on a way to prevent this in the future - but just in case something like this happens again, I want to have a failsafe that will put the majority through still. Commented Sep 12, 2016 at 18:44
  • the crazy unlikely part is that it would validate and test send correctly on 49,998 emails, the error would only show up on the last 2 that would call the 'false' part of the IIF. Commented Sep 12, 2016 at 18:48

1 Answer 1

3

A few things off the top of my head:

  • First and foremost, code defensively. Don't use raw personalization strings. Use the AttributeValue() function and check them with empty(). Check the rowcount() on every function that returns a row-set. Check the length of strings before doing a substring(), etc.

  • If it's a real obscure/fluke error that's hard to detect, you can use a SSJS try/catch block and use write a row to a DE and then raiserror() in the catch. This will keep the email from blowing up the send and give you a record of what happened. It's not a good long term solution.

  • Clean your sending data with a prep/verification Query Activity.

2
  • Thanks for the answer Adam - I already do #1 and# 3 (#1 I learned from you and man I can't thank you enough for that word of advice!) I think the SSJS try/catch may be our best option right now for the more time sensitive campaigns we have. Thanks for the advice! (I would upvote you too, but I get the feeling it would just be removed again at some point...) Commented Sep 13, 2016 at 12:05
  • @Adam Spriggs ... What would be a long term solution ?
    – mario ruiz
    Commented Apr 19, 2017 at 22:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .