Making Changes to Published Forms

This concepts article will help Technicians learn using and managing ticket forms in the TDNext. The user must have the Technician Security Role assigned in TDNext.

Overview

As technicians manage tickets on a day-to-day basis, they may find a need to change the forms that are actively being used to create tickets such as a Service Request Form. Changes to forms can take effect when new tickets are created or when editing an existing ticket. Ticket fields on the form may not adjust depending on the scenario for each use case. Below are some tips as well as a few scenarios explaining the form changes behavior.

Making Changes to Forms in TDNext (ticket intake)

• If any TDX field such as a textbox or text-area field already has a value and you change the ticket form, the field will stay the same, hence the “Sticky” behavior. Unless you select the “Reset” button on the actual form.
• If a field is blank or does not exist on the form, and the form you are using has a default value for that field, the default value will be applied, hence non - “Sticky”.
• Ticket Edit - When you change forms during a ticket edit and you have values in fields that are not on the new form, the values "stick" around.
• Ticket Creation – Reset Button allows you to reset the values and use the defaults from the latest form. Note: The form “Reset” button only exists during ticket creation.
• Depending on the previous ticket form any field could be “Sticky” and carry the initial value if the field existed on the previous form selected. Standard TDX required fields to create a ticket will always be “Sticky” such as Title, Requestor, Acct/Dept, Service & Type since they are needed on each ticket by the system.
• Ticket Templates can also help adjusting ticket fields; however, they only apply upon ticket creation.
• If a ticket has a default responsibility set in the form for TDNext and the field is set to Hidden, the responsibility of a ticket will revert to the default any time an edit is made. This is designed behavior and is not limited to just the responsibility. Any default/hidden field will revert to its original value.
• Secondly, the Requestor is entered as a Read-Only value.
• If you set your service to be publicly requested, and do not set it to perform Requestor Name Matching (specifically where it will create a People record when the entered email does not match an existing record), it will create a Read-Only Requestor value. This is not tied to a user account, and because of that lack of a Requestor, workflows will be prevented from being added by the service and by hand from a TDNext user.
  • The reason for this is because a workflow can have Approval steps which the Requestor is responsible for. If a Requestor is not recognized by the system, it wouldn't be able to set them responsible and the workflow would be broken. To prevent that break, we simply do not apply the workflow, regardless whether the Service should apply it or an Automation Rule.

Form Change Scenarios in TDNext

• Current Ticket
  1. If a ticket is created with form A, and an attribute is filled in for Form A, and the technician switches to Form B, and Form B does not have the attribute that I filled out for Form A, what happens to the attribute value?
     • Outcome: The attribute from Form A will persist even when switching to Form B. 
  2. If a ticket is created with form A, and an attribute has a default value Form A, and the technician switches to Form B, and Form B does indeed have the same attribute that I filled out for Form A, but Form B has a different defaulted value, what happens to the attribute value that I put in for Form A?
     • Outcome: The attribute value from Form A will persist even when switching to the defaulted value of Form B. 
• New Ticket (Not yet created)
  1. If a ticket is started (not yet created) with Form A, and an attribute is filled in for Form A, and the technician switches to Form B, and Form B does not have the attribute that I filled out for Form A, what happens to the attribute value?
     • Outcome: The attribute that does not exist on Form B will not appear on the form any longer. 
  2. If a ticket is started (not yet created) with Form A, and an attribute is filled in for Form A, and the technician switches to Form B, and Form B does indeed have the same attribute that I filled out for Form A, what happens to the attribute value that I put in for Form A?
     • Outcome: The attribute value from Form A will persist. The assumption is that the technician or client already answered the question previously, so if a value is there and the form is switched, the original value persists.
  3. If a ticket is started (not yet created) with Form A, and an attribute is filled in for Form A, and the technician switches to Form B, but Form B has a different defaulted value, what happens to the attribute value that I put in for Form A?
     • Outcome: The attribute value from Form A will persist.