Recurring Email Notifications until the Issue is Solved

5 Comentarios

  • Pedro Rodrigues
    Community Moderator

    Hi Haubert, in order to better understand your workflow, can you please help me by clarifying the following:

    1. Are you using different targets (to change Requester as the retailer user ID + setting the Requester to the original Requester)?
    2. Is the retailer always the same user ID? If not, where does the retailer user value come from?
    3. The entire workflow is set up using automations, correct? Which means, there aren't any triggers being used?
    4. How are all your actions grouped? ¹
    5. Can you pinpoint more or less where (which step) does your workflow usually goes wrong?

    ¹ For example, if steps #1 and #2 belong to the same trigger/automation, or if #1 and #2 are separate automations.

    Thanks in advance!

  • Haubert

    Hi Pedro,

    Thank you for your prompt response!

    Are you from Zendesk?

    1. Yes, I have two targets: Setting Retailer as Requester and Setting Owner as Requester
    2. We are using URL target, something like this{{}}&ticket[requester]={{ticket.ticket_field_22797924}}&ticket[additional_tags]=[retailer_requester]

    3. Yes, that's right! The problem with the trigger is that some time it is too fast and becoming inconsistent. I achieve better, but not perfect consistent by using Automations. Idk how to explain it, it just happened to work that way.
    4. #1 to #9 are all separate automations
    5. The Requester switching is the one that is usually broken, hence, the message that was supposed to go to the Retailer is being received by the Owner instead (#2, #4, #6, #8, #10)

    Looking forward to hearing from you.

  • Pedro Rodrigues
    Community Moderator

    Hi Haubert, I do not work for Zendesk - just contributing as a Community Moderator :-)

    Thanks a lot for clarifying my questions. So the trick here is that we have to give these automations enough time to properly make changes, notify the correct requester, and only then make further changes.

    • I'm assuming the retailer isn't always the same, do you add it to your custom field ID 22797924 manually?
    • How crucial is it to be switching the requester all the time?

    I don't think you need to be changing the requester all the time, which means the options for this workflow are:

    • Having targets modifying the requester of the ticket, OR
    • Having targets notifying whichever Retailer is in custom field 22797924.

    This second option doesn't require you to modify the Requester: you just create a target that notifies the retailer whenever needed.

    Here's an example of what I'm saying:

    #1: Notify the Owner (the original Requester) when the issue is detected

    Trigger 1

    • Ticket Created
    • Add tag zd_step1
    • Email Owner

    Meanwhile, you'll add the Retailer to its specific custom field. If it really is added manually, I'd recommend you apply a macro to make sure a tag is added.

    Macro would add tag zd_retailer_set (for example)

    #3: Notify the Retailer about the issue

    Trigger 2 (executed as soon as an agent applies the previous macro)

    • Ticket is updated
    • Status is less than Pending
    • Tags contain zd_step1
    • Tags contain zd_retailer_set
    • Notify target to email Retailer
    • Add tags zd_step2, zd_retailer_notified

    If the issue is not resolved in 7 days:

    #5 + #7: Set a reminder email to the Owner that the issue is persisting

    Automation 1

    • Tags contain (...)
    • ...
    • Emails requester (Owner)
    • Notifies target (Retailer)

    If the issue is not resolved in yet another 7 days, repeat.

    When the issue is resolved, you execute #9: Email Requester (Owner) and notify target once again for #11 notify Retailer.

    Hope this helps!

  • Haubert

    Hi Pedro,


    Thanks for sharing your thought here!

    Really appreciate the detail instructions that you have layout there.

    I have tried a similar process previously, however, the downside of using the function of 'Notify Target' is that we are unable to set the subject of the email, isn't it? Or, do you happen to know the work around it?

    The reason why the subject of the notification matters is that we can accurately inform the reseller in regards to the status of the Owner. This is why we insisted on switching between the Retailer and the Owner as the requester.

    I hope this clarifies.

    But yeah, definitely can go back to the Notify Target method as at least for me, better than having no notifications at all.

  • Pedro Rodrigues
    Community Moderator

    Hi Haubert,

    Happy to help, it's fun thinking about and building workflows :-)

    Definitely understand the need to have a proper Subject. As far as I can see, there are at least two options.

    1. Few retailers, seldomly updated

    You could consider using an Email target for each Retailer.

    This would depend on how many, how often you need to add new retailers... In other words, how feasible this for your case.

    • Email Address: unfortunately you can't add placeholders here, you need to specify a specific email address (hence one email target per retailer) 
    • Subject: the subject you choose (you can use placeholders here)

    In the extension, you'd set the receiver email address (could be a placeholder), The body of the message to be sent is configured within the business rule.

    Here's an example of such target that I had created for testing (to be notified). The extension:

    And a trigger using that extension:

    Please note this would not modify the ticket Subject.

    2. Specific target to set the ticket Subject

    In this case, we use an HTTP target to update ticket fields (or use an existing one if you already have it)

    • URL:{{}}.json
    • Method: PUT
    • Content type: JSON

    Within the trigger/automation, set your new ticket Subject:

    {"ticket": {"subject": "Order {{}} from {{}}"}}

    Of course, this means that you'd have to use yet another target to update ticket fields, which means you'd have to be careful about the race condition issue (i.e. trigger updates and other targets might not be executed in the order we expect)


Iniciar sesión para dejar un comentario.

Tecnología de Zendesk