forms and service, type (and service offering) attributes: TDClient vs. TDNext

I'm setting up forms and trying to keep them as simple as possible. Therefore I'm not including service, service offering, and type attributes since I can associate the form with the service offering and those attributes should be taken care of.

When using the form in TDClient, those three attributes are correct - they show up in the "other fields" section of the form with the correct values.

When using the form in TDNext [tickets > +new > (select the form)], service and type (not service offering) show up in the "other fields" section of the form with no values. Since "type" is required, this forces a person to go to the section and select a value which takes time.

Most of our tickets are created through TDNext so I need to have that working more efficiently. Did I miss something in the setup? Am I looking at this wrong?

Tags form attributes
Asked by Greg Van De Mark on Wed 5/1/24 9:43 AM
Sign In to leave feedback or contribute an answer

Answer (1)

This answer has been marked as the accepted answer
Mark Sayers Wed 5/1/24 9:46 AM

Hello Greg,

The answer is in your post above. You said: Therefore I'm not including service, service offering, and type attributes since I can associate the form with the service offering and those attributes should be taken care of.

So if you aren't including those fields on the form, they won't have a default value when you go to use the form in TDnext, nor should they when configured that way.

You'd have to give the form a default value of some sort if you want it to have one when you use the form in TDNext.

Sincerely,
Mark Sayers
Sr Support Consultant, CS

No feedback
I've included these three fields on my forms and they have correct values. Now for an additional question... If the form attribute is changed, is there a way for the three fields to change automatically so that people don't need to change so many attributes every time a form is changed? Example: A ticket is created from an email using a generic form. Our tier 1 changes the form (to work with more detailed info). Do they have to manually change the type, service, and service offering fields? It seems that if the form is changed only the service field is changed also - type and service offering are not. Did I mess something up in my setup? - Greg Van De Mark Wed 5/22/24 1:02 PM
Changing the form after the ticket is created does not force fields with saved values to also change. You do have to touch those fields manually to get them to change after the creation is complete. - Mark Sayers Wed 5/22/24 1:09 PM
We are not using those three attributes (type, service, service offering) on the form except for possible reporting. (We aren't doing SLAs, etc.) Really, when doing reporting, just selecting or filtering on "form" is as fancy as we need to get at our small university. Do you see any downside to hiding the three fields and let the values be whatever they end up being? - Greg Van De Mark Wed 5/22/24 1:52 PM
I guess if they are getting their value from the service that uses the form, that works. But if you don't have them on the form and create tickets manually, you *will* at minimum need to be providing a Ticket Type value. It is a fundamental field required for tickets. - Mark Sayers Wed 5/22/24 2:15 PM
People reading this may wonder, "Why all the fuss?"
When creating a ticket and changing the form, the type, service, and service offering attributes were not being updated. But when I was changing the form on an existing ticket, those attributes were being updated. Weird. But... I had not noticed the "reset" button right next to the form attribute when creating a ticket. When selecting a new form and tapping the "reset" button, things worked as expected. If I would have seen the button, I wouldn't have been so confused. - Greg Van De Mark Thu 5/23/24 10:32 AM