Overview
This guide covers the process of utilizing Web Service Methods in a workflow to create a cascading ticket for recurring maintenance. There are times where maintenance needs to recur in relation to when the last time maintenance was completed. In the real world setting a ticket being scheduled to come up every month may not be practical if there are delays and the maintenance does not happen for 2 weeks+. This could compress your schedule and cause maintenance to be repeated more often than necessary; wasting time. If you do need a basic scheduled ticket there are more simple processes on scheduling tickets that can be learned about here: Scheduled Tickets In this example we will proceed with the following scenario:
A technician creates a ticket
- Use a title describing the maintenance to be completed - This title will perpetuate across every occurrence in this maintenance cycle
- Description of the specific details on completing the maintenance - This title will perpetuate across every occurrence in this maintenance cycle
- Use a isolated service for these tickets - this will relate to Automation rules later
- Remember you can set services like this to have limited visibility, essentially isolating them to just the maintenance techs to be able to work with this process
- The requester added on the ticket will perpetuate across every occurrence in this maintenance cycle
This ticket will then wait 1 month, create a task for the maintenance to be enacted, wait for the maintenance task to be marked complete. Once the task is marked complete the workflow will create a new maintenance ticket copying the title, description, and requester attributes and will close the old ticket. The new ticket will be picked up by automation rules upon creation and add the same workflow to the ticket thus starting the process over beginning with the 1 month timer.
NOTES:
- Anytime you are working with automation for creation and loops it is best to test it in your Sandbox!!!!
- If at any point a change to the description, title, or requester is needed that can be changed manually on the ticket and it will carry forward to all copies from that ticket - It will not change historical data on closed previous tickets
- This workflow can be used on different tickets and the non-static attributes can be specific to those individual tickets (title, description, requester)
- You can adjust the timer to be any length you like (1 month in this example)
- You can add multiple tasks, notifications, etc. in the workflow between the timer and the creation of the new ticket - This example only adds 1 task
- Remember that you can only have 1 workflow assigned on a ticket at any time
Preparing to build the Web Service Method and Workflow
- You will need Global Admin access or app admin to the ticket app and client portal app you plan to use
- This guide assumes you have prepared your Workflow Web Services configurations in your Ticket application (Web Service Auth Accounts and Web Service Providers). For details on initial setup for Web API look at these articles: API Content
- You will need to choose a specific attribute to use as part of the workflow assignment in Automation Rules. For this example we use a Service as our anchor point to apply the automation rule. Once you choose your desired ticket element create that specific item (service, type, Dedicated title, etc.)
- You will need to gather some static values to use in the Web Service Method Build
- Type ID: Navigate to TDAdmin>Applications>Ticketing App>Types. Once there locate the ticket type you plan to use and document the ID number from that row.
- Form ID: Navigate to TDAdmin>Applications>Ticketing App>Forms. Locate the form you want to associate with and document the ID number from the row - In this example we are using a basic service request form
- Source ID: Navigate to TDAdmin>Applications>Ticketing App>Shared Ticketing Settings>Sources. Locate the Source you plan to use and document the ID number from the row
- Status ID: Navigate to TDAdmin>Applications>Ticketing App>Statuses. Locate the status you plan to use and document the ID number from the row
- Priority ID: Navigate to TDAdmin>Applications>Ticketing App>Shared Ticketing Settings>Priorities. Locate the priority you plan to use and document the ID number from the row
- Service ID: Navigate to TDAdmin>Applications>Client Portal App>Service Catalog>Services. Locate the service you plan to use and document the ID number from the row
- App ID: Navigate to TDAdmin>Applications. Locate the ticketing app you are going to be using and document the ID from that row
- If you want to be able to test the method you will also need:
- Account ID: Navigate to TDAdmin>Organization Settings>Account/Departments. Locate the Acct/Dept you plan to use and document the ID from the row
- RequestorUid: Navigate to TDAdmin>Users. Locate the user you want to set as the requester for the test ticket, click on the user to open their record, locate the URL string at the top of the user record window it will look like: YOURDOMAIN.teamdynamix.com/TDAdmin/Users/Edit.aspx?U=.......... The user ID is the end of the URL string starting after the "U=" It will be very long, use copy/paste or just keep the user object open for use in the testing section
Building the Workflow Web Service Method
- Navigate to TDAdmin>Applications>Ticketing App>Workflow Web Services>Web Service Methods
- Click + New
- Name the Web Service so you know what the service does
- Select a Web Service Provider
- Mark as Active
- Use a POST method and use the URL string: https://YOURDOMAIN.teamdynamix.com/TDWebApi/api/[App ID]/tickets/
- replace the [app id] with your ticket application ID number
- Enter Key: Content-type
- Enter Value: application/json
- Click +Add next to the value section; the key and value will not be assigned to the Web Service Method
- It is good to save your method as you go; hit save
- Navigate to the Parameters tab
- Enter and add the following Parameter lines to the method:
- Title - String - From Ticket - Title
- Description - String - From Ticket - Description
- RequestorUid - String - From Ticket - Requestor UID
- AccountID - String - From Ticket - Acct/Dept ID
- With those parameters added and saved navigate to the </>Body tab
- Enter the follow Body content:
-
{
"TypeID":[Type ID],
"FormID":[Form ID],
"Title":"{{Title}}",
"Description":"{{Description}}",
"AccountID":{{AccountID}},
"SourceID":[Source ID],
"StatusID":[Status ID],
"PriorityID":[Priority ID],
"RequestorUid":"{{RequestorUid}}",
"ServiceID":[Service ID],
}
- Replace the bold elements in the body with the static content you gathered in step 4 of the preparations
- example: "TypeID":1082,
- Remember to start and end the body with the curly brackets { *content* }
- Save the method and navigate to the Authentication tab
- Select your Web Service Auth Account
- Save the method
Testing the Method
If you would like to test the method at this point you can do so with the following manual steps or skip to Building the Workflow.
- You will need the additional values from step 5 in the preparation section: AccountID and RequestorUid
- Click on Test Request
- Enter a Title to be used for the ticket - Example: Test Maintenance Ticket
- Enter a Description to be used for the ticket - Example: Test description for Maintenance Ticket
- Enter the Account ID from the preparation step
- Enter the RequestorUid from the preparation step (you can leave this null if not known)
- You will see your values populated into the body preview on this test window
- click Send
- It should return a successful ticket creation and the ticket will be found in TDNext under your ticket application
Building the Workflow
- Navigate TDAdmin>Applications>Ticketing App>Workflows
- Click +New
- Add an appropriate Name and Description then save
- On the newly created workflow click View Builder
- Click New Step
- Name and create a Timer
- Set the timer to 1 month (or whatever amount you want)
- If you would like to do real world tests with the workflow on tickets set the timer to be very short (i.e. 1 minute) or omit the timer - you can come back and add or change the timer to fit your final design (ex. 1 month)
- Click New Step
- Name and create a Task Step
- Create a task and appropriate assignment to indicate that the maintenance activity should proceed
- If desired add additional notifications and tasks
- MAKE SURE YOU HAVE A TASK THAT "WAITS TO BE COMPLETED" INSERTED BEFORE THE TICKET CREATION STEP OR YOU COULD WIND UP LOOPING YOUR TICKET CREATION. Without the "wait to be completed" turned on the workflow will create the task then move forward to the next item; in this case creating a new ticket that would do the same action when it hits the task. If your timer were set very short this could result in numerous tickets until you manually stop the workflow.
- Click New Step
- Choose Web Service
- Name and describe the step
- Select the Web Service Method you created above
- Choose appropriate notifications (if applicable) and save
- Add your flow from the timer start to the task then to the Webservice
- Run the success on the webservice to approve and the failure to reject
- Click on Workflow dropdown menu and select details
- Choose the desired status for the approval of the workflow - Closed in this example
- Choose the desired status for the rejection of the workflow - Cancelled in this example
- Save and Check in the workflow - Close the builder
- On the workflow page make sure you click activate to mark active
Setup the Automation Rule
- Navigate to TDAdmin>Applications>Ticketing App>Automation Rules
- Click + New
- Add a name and Description
- Select Stop on Match
- Save it
- With it created click on Edit
- + Add under the conditions section
- Add the attribute you plan to anchor to - this might be a service, type, Dedicated title, etc..... - This example uses Service
- Service - is one of - [SERVICE NAME]
- Scroll to Automation Actions and locate Assign to Workflow - Choose the Workflow you created above
- Add any other actions desired and save
Using the Workflow
- Create a new ticket
- Name it with the name you want to perpetuate over the use of this cycle
- Add a requester you want to perpetuate for this maintenance cycle
- Add the details you want to perpetuate for this maintenance cycle
- Set the anchor attribute (Service) so it will check against the automation rule
- Complete the rest of the ticket and save
- This should result in a created ticket with the workflow added and the timer will have begun
Gotchas
- MAKE SURE YOU HAVE A TASK THAT "WAITS TO BE COMPLETED" INSERTED BEFORE THE TICKET CREATION STEP OR YOU COULD WIND UP LOOPING YOUR TICKET CREATION. Without the "wait to be completed" turned on the workflow will create the task then move forward to the next item; in this case creating a new ticket that would do the same action when it hits the task. If your timer were set very short this could result in numerous tickets until you manually stop the workflow.
- Testing this in sandbox first is advised...
- Remember to mark workflow method and workflow as active
- You can use any evaluation attribute for the automation rule - this example used a service- A service has several values as the filtered attribute:
- You can set visibility and group permissions on a service
- The service ID can be part of the work flow so if the workflow is manually added to a ticket that is not under that Service ID the cascading created tickets will have the correct Service assigned to align with the Automation rule