Types, Forms, Services: same number of each?

Are we to have about the same number of types, forms, and services (like it seems to indicate in https://solutions.teamdynamix.com/TDClient/KB/ArticleDet?ID=3340) or have things changed since that article was written (pre-v 9.5)? Type is less important now (v 10.1) in comparison to forms and there are newer things such as cascading attributes to use on forms. I'd like to have the fewest types and forms to use with my services while still allowing for good ticketing process flows and reporting filter robustness. What is TDX recommending now?

Tags ticket-type ticket-types forms service-catalog service form services
Asked by Greg Van De Mark on Tue 10/16/18 5:52 PM
Sign In to leave feedback or contribute an answer

Answers (8)

This answer has been marked as the accepted answer
Mark Sayers Wed 10/17/18 2:41 PM

I suppose you could reuse the same form for various services, but in that case I would *not* include the "Service" field on the form at all, as that already gets populated via the connection that services have with the forms they are using. If you were to include the Service field specifically on a form, and give it a default value of some service other than the one currently being requested, it would override the service the user is requesting and place the default value of the form on the created ticket. Hopefully that makes sense, but in general I'd steer away from including Service as a field on the form. It's a baked-in field that shows up on every ticket regardless of whether it is included specifically on the form, so there's no need to have it on forms, especially ones that aren't configured to be used from the TDNext end of the tool.

No feedback

Karen Compton Wed 10/17/18 2:54 PM


Regarding using Questions vs. the advisory group... I *do* follow the entire Questions category and wish more people did also. I prefer it to the advisory group because the emails from the advisory group do not include the topic, while the Questions emails do. I realize this isn't a "conversation forum" so I hope no one minds that I interjected this comment!


1 of 1 users found this helpful.

Greg Van De Mark Wed 10/17/18 2:56 PM Last edited Wed 10/17/18 2:57 PM

Thanks again Mark!

Now this helps! Even though I set up the service with the form, I thought I had to put the field on the form also. This type of information is great to have. Have any more? :)

Karen -

I think I'll do the same and I'm glad you interjected your comment!

No feedback

Greg Van De Mark Wed 10/17/18 2:36 PM


Thanks for the extra info. I thought it would have been an easier-type answer because I thought everyone was reusing a form on various services. Hiding the "service" field on the form so that customers don't see/interact with it doesn't lead me to think I could reduce the number of forms I use because even though the field was hidden, the field still exists and has a default value. I thought the answer would be along the lines of creating a more generic form and creating automation rules so that when the ticket gets created with (whatever) the automation rule kicks in and does (whatever). I don't use many automation rules yet so I was thinking there was an easy answer that involved things I don't know much about.

I am open to people at other institutions chiming in with their solutions but I don't think people generally read the questions area unless they are searching for an answer. I might post the question on the Service Management Advisory Group feed where it might get pushed in front of people. As for process consulting, I'll let you know.


No feedback

Mark Sayers Wed 10/17/18 11:59 AM

For your item 1) I can say that in general if you had things the Client shouldn't be interacting with on the form, just make those fields "Hidden" for the Client setting and "editable" or "editable and required" in TDNext so the techs can interact with the fields as needed after receiving requests.

Grouping similar services into a single service would eliminate the need for additional forms, then you could utilize cascading attributes to let the client select the exact item they're needing to request.

I think for 2) you could benefit from even just an hour or so of process consulting as that will be more of a best practice type thing that a consultant would be able to offer a few ideas on.

Let me know what you think about that.

No feedback

Mark Sayers Wed 10/17/18 11:28 AM


It sounds like possibly you could benefit from a block of time with a process consultant from TeamDynamix to go over some options that you might consider for optimizing services/forms/types for both portal and TDNext usage.

If you're interested I could refer this to your account manager to follow up and facilitate that engagement?

Otherwise I could request Professional Services to take a look and offer you some recommendations that have worked for their other customer. In general we do not have a list of recommendations that *might* work, as each organization typically sets up their services and forms in a way that is most useful to their needs, so a Services representative would be best suited to giving you some ideas to think about for the items you have asked here.

Mark Sayers
TD Support

No feedback

Greg Van De Mark Wed 10/17/18 11:08 AM

Great! I can figure out how to reduce the number of types (especially since we don't use SLAs yet). I understand the concepts of cascading attributes to limit the number of forms needed but I'm unsure on a couple of details:

  1. Our forms have titles, services, and types that are defaulted to the values associated with the service. Our technicians can change the values (TDNext) but I don't want to force our customers to do that (TDClient). How can I reduce the number of forms but make this work on the TDClient side?
  2. Even though our technicians can change the values in TDNext, it seems to be hard for them to change all the values that need changing. We use desktop reports to catch the tickets that aren't set right. Is there a better way to do this - preferably limiting the number of fields that the technicians need to change?
No feedback

Mark Sayers Wed 10/17/18 9:42 AM

Hello Greg,

You certainly do not *have* to have any more forms than you really want to use. With the existence of forms now and things like cascading attributes, it is hopefully possible for you to consolidate forms and services as much as possible to trim out things that might have been almost a duplication of effort.

Because of the way conversion to 9.5 happens you *do* end up with a form for each ticket Type, but you can remove those forms or do whatever you want with them to make them as useful as possible to your organization or the department who's ticketing app it is. Trimming down types and forms certainly would not hurt anything, and it would probably make things like automation rules and whatever work more efficiently if it didn't have so many of them to filter through when evaluating each new ticket.

Mark Sayers
TD Support

No feedback