As most Zendesk Administrators have learned, Zendesk doesn't natively offer a way to generate multiple tickets for various Groups, from a single Trigger. However, there are ways to use native functionality (along with minor outside sources) to achieve the same goal without the need of extra apps. This topic will specifically cover using a Form, Macro, Extensions, Tags, and Triggers to accomplish the goal.

Here is the "quick and dirty" of how I built this out, and below are the Step-by-Step instructions. I basically built my Ticket Fields and Form as normal. From there I:

• Built a Trigger specific to this Form, which routes the ticket to my IT Group, as well as adds a tag to identify these types of tickets (ensure you have it in your Condition section as a "does not contain tag" <-- keeps from ticket-looping).
• Add a Macro that the IT Group will activate, that populates the Ticket Field values into the body of the ticket, along with adding a new tag; This new tag is what will fire the next strings of Triggers built.
• Add Extensions (i.e. Email Target) for email addresses (configured in our Exchange server), that route to Zendesk for ticket generation for various Groups. If you only have one email address that routes to Zendesk for ticket creation, then you will need to configure those as well.
• Configure various Triggers for the teams that need to get a ticket, based on the parameters you specify. Again, ensure you are adding a tag that is also set within your Condition section (as a "does not contain"), to keep from "ticket-looping". Within the Actions section, you will want to use the "Notify Target" option, and specify the proper Extension you configured earlier. Within the Body, I created my own "email" template that is a listing of the various values, that are populated using Zendesk placeholders. As for the Subject, this is pulled from the Extension you configured.

Step 1: Determining who gets tickets and when

Before you begin building this out, you need to know who should be getting tickets generated for them, and at which point in the process. For this example, we will have our Manager start the process (i.e. submitting the Form via the web portal...non-agent side), and have that initially go to our IT group; Basically an EMP new hire process. From this point, the other teams will get their tickets as needed.

Step 2: Building based on order of operations

Now that we have our "goal" in mind, we can start building out the process. Based on our initial starting point, we need to build our Form, which requires the Ticket Fields to be configured, and then the Form to be built. Since these are fairly common practice and there is plenty of documentation on how to do this, I will not cover these in detail. One thing of note, it is highly recommended to specify a Brand for this Form, to ensure usage by the proper individuals (depending on your Use Case).

Building the Trigger

With the Form built, you can now start working on the next part, which is the Trigger to get the Form to our IT group. As normal, build a Trigger that looks specifically for values associated with the Form; These usually are:

• Form name
• Associated Brand
• Key Ticket Fields

Also, ensure you have a Condition that looks for a specific tag/s, that you are also applying in the Trigger. For example, I want my Trigger to post a tag of "emp_new_hire:, that way I can identify those types of tickets that are generated via this method, but to ensure the Trigger fires only once, I need to ensure the same tag is added as a Condition of not already existing. This is for ensuring there is a way to identify the ticket, but adding the Condition ensures you are not running into a "ticket loop" situation.

Building the Macro

Now that the ticket is with the IT Group, they will initiate the Ticket generation process for other teams by clicking on a Macro that applies the Field values into the body of the ticket, as well as applies a tag of "emp_macro" for Triggers to look for. For the Macro, it is pretty straight-forward:

• Only available to IT Group
• Set Subject
• Set Comment Mode to Private
• Set Comment with Ticket Field values, using Zendesk placeholders
• Add tag of "emp_macro"

Adding Extensions

Now you will want to configure "Email Targets" (via Extensions), in order for the other tickets to be generated by the Trigger/s we build in the next section. As such, configure your Email Target to the email address configured on your company's EmailExchange server, not the email address on the Zendesk side. These should be email addresses that already forward to Zendesk for generating tickets. For the Subject, put whatever you need to be in the Ticket subject, as this is what will be pulled (Zendesk placeholders are allowed). If you have Groups that will need tickets generated that don't currently have a direct email-to-ticket method, then you will need to create those before moving on to creating the Extensions and Trigger/s.

Not to get into specifics on this, but you will need to generate an email address on the Zendesk side, provide that to your Email/Exchange administrator to configure as a Forwarding email, and also generate a Trigger that routes that email to the proper Group.

Building Routing Triggers

Now comes the final piece, the Trigger/s that will generate the extra ticket/s. Depending on your scenario, you may only need one or you may require multiple Triggers. For example, if you have a process where multiple Groups perform work at the same time (that doesn't change based on specific parameters), then a single Trigger will work. However, for those that need a way to send extra tickets based on specific values, then you will need more than one Trigger.

Single Trigger
  Conditions:

• Specify Form
• Status less than Solved
• Tag contains the "Macro" tag (previous step above)
• Tag does not contain the "Macro Fired" tag (applied in this Trigger)

  Actions:

• Add tag "Macro Fired"; Put whatever you want here, that helps identify that this Trigger fired, and was a follow-up to the Macro being applied to the ticket. Ensure this same value is listed in the Condition statement above.
• Notify Target "Extension"; The Extension should be whatever you configured earlier, that is the email address of the Group that needs to receive a ticket.
  
  NOTE: Add all the "Notify Target" statements needed, for each of the various Groups that will receive a ticket. Please note that Zendesk placeholders can be used in the Message section, and is highly recommended to use for populating a lot of your values.

Now you can save the Trigger, and should be good to start generating tickets for all the various Groups needed.

NOTE: Be sure to run a test and ensure the tickets are generated to the correct Groups, as you may need to setup the "Zendesk User" as a user that can generate tickets within your environment. I state this, as my company has rules that only allow valid users to generate tickets, so I had to add the "Zendesk" automation user as a valid "person". If you don't see the tickets in the proper Groups, check your "Suspended" tickets queue and they should be there. If this is the case, you can click on the user and set the email address to "Verified".

Multiple Triggers

For situations where you will need to identify specific values before generating a ticket, you will need to build more than a single Trigger. Using the "EMP New Hire" example, we will show a few items to key off of, but the overall idea is the same as the Single Trigger.
  Trigger 1:
    Conditions:

• Specify Form
• Status less than Solved
• Tag contains the "Macro" tag (previous step above)
• Tag does not contain the "Macro Fired" tag (applied in this Trigger)
• Role is Support Manager

    Actions:

• Add tag "Macro Fired"; Put whatever you want here, that helps identify that this Trigger fired, and was a follow-up to the Macro being applied to the ticket. Ensure this same value is listed in the Condition statement above.
• Notify Target "Extension 01"
• Notify Target "Extension 02"
• Notify Target "Extension 04"

  Trigger 2:
    Conditions:

• Specify Form
• Status less than Solved
• Tag contains the "Macro" tag (previous step above)
• Tag does not contain the "Macro Fired" tag (applied in this Trigger)
• Role is Engineering Agent

    Actions:

• Add tag "Macro Fired"; Put whatever you want here, that helps identify that this Trigger fired, and was a follow-up to the Macro being applied to the ticket. Ensure this same value is listed in the Condition statement above.
• Notify Target "Extension 01"
• Notify Target "Extension 03"

  Trigger 3:
    Conditions:

• Specify Form
• Status less than Solved
• Tag contains the "Macro" tag (previous step above)
• Tag does not contain the "Macro Fired" tag (applied in this Trigger)
• Role is Corporate Security

    Actions:

• Add tag "Macro Fired"; Put whatever you want here, that helps identify that this Trigger fired, and was a follow-up to the Macro being applied to the ticket. Ensure this same value is listed in the Condition statement above.
• Notify Target "Extension 01"
• Notify Target "Extension 02"
• Notify Target "Extension 03"
• Notify Target "Extension 04"
• Notify Target "Extension 05"

And so forth, as needed. As stated with the Single Trigger build, be sure to run a test and ensure the tickets are generated to the correct Groups, as you may need to setup the "Zendesk User" as a user that can generate tickets within your environment. I state this, as my company has rules that only allow valid users to generate tickets, so I had to add the "Zendesk" automation user as a valid "person". If you don't see the tickets in the proper Groups, check your "Suspended" tickets queue and they should be there. If this is the case, you can click on the user and set the email address to "Verified".