Implementation Gotchas

Overview

The purpose of this article is to help share information over with new clients about common implementation risks, pitfalls or 'gotchas' to look out for.

Both PPM and ITSM

• When importing in user records, especially for the first time, do not create customer records, create user records. Customer records cannot login and perform many of the functions you'll likely want them to do. There is no bulk way to convert customers to users in TDX apart from what's called Self-Registration, but that will require your clients to sign into the Client Portal.
  • all user imports (really all data imports in general) should be done via the API user import process. More details are listed on this KB Article. 
• When importing user records into a non private cloud environment, ensure that the usernames are fully scoped or truly unique to your organization. This is important in all environments but especially so in US and Canadian Standard SaaS.
  • e.g., If John Smith has a username jsmith@university.edu, ensure that his username is populated with the fully scoped address, not just jsmith, as there are likely jsmiths at every institution.
• When importing data into TDX, be sure to import it into sandbox FIRST and then to Production. Imports are easy to make mistakes on and there are not always ways to remove data in bulk from TDX.
• User records are permanent and cannot be deleted out of TeamDynamix, they can however be deactivated or merged (with other customer records). 
• When importing Acct/Dept records, ensure that the data is going to match what will be imported when you import users.
  • This should be imported in Sandbox FIRST then in Production once data looks good in Sandbox. This will ensure accurate data on your user's Acct/Dept value when importing those. 
• When in TDClient on a Service's Edit menu > Forms tab, the default selection is Create New Form. If you click save and navigate away from this page, you will have inadvertently created a form specific to this service. Either assign a form, create a new form, or navigate from the page without clicking save.
• Email Replies and Outbound SMTP servers can be set either at a global level or an application based level, meaning that they are used throughout TDX. For more information on the Email Services that TeamDynamix provides, please visit this KB Article 
• Email bounce backs should be diverted via an email rule on the email client inbox to a different folder to prevent loops of bounce backs creating tickets, sending ticket creation notifications, etc. 
• Groups + Group Memberships cannot be created in bulk unless you use the API endpoints and will have to be created manually.
• Type Categories are shared between Projects and Ticketing.
• Priority is shared across all ticketing applications and Project Management. While, Impact and Urgency are shared across all ticketing applications. When making decisions around these three, ensure these are organizational-wide standards all teams can agree with. 
• Project Management Security Roles are controlled in the main global TeamDynamix Security Roles section on the TDAdmin > Users/Roles page, due to the Projects application being shared across TeamDynamix and not having its own application segmentation like tickets and assets.
• Attributes types CANNOT be changed once the attribute has been created. 

ITSM Only

• Creating multiple client portals with multiple service catalogs with public services will mix services from multiple portals when viewing the services look up in TDNext. See the associated KB for more info. 

• When creating your service catalog, clients often try to create 'everything and the kitchen sink'. This can result in your project/service catalog stalling out because the scope is too large and unwieldy. 

  • Instead, focus on the vital few (the 80/20 rule). It has been proven that roughly 20 or so of your highest volume services comprise about 80 percent of your total ticket volume. Focus on building these 20 services, and then expand from there. 

• Reuse and rename attributes when possible.
  • e.g., If you want an attribute to appear as "Who is the user needing access?" on a form, it could help to name the attribute "User", and then customize the name of the form to appear as a question. This helps keep your attribute list from becoming convoluted with "Who is" or "What is" questions. Additionally, "User" is more generic, so if another form requires a people picker type attribute, you could repeatedly use the one you've already created and customize the name as needed.
• Create Attributes via the Ticketing application Attributes section as this area provides more resources to you like attribute choice sorting, adding Help text/description. Creating Attributes via Form Designer view is great for on the fly quick attributes like a text area, but does not provide more in-depth features on this view.
• Organization Settings in your Ticketing app are global and carry over to other ticketing apps. If you are a Ticketing App Admin then this area will be locked down for you.
  • coordinate efforts with the TDX global administrator to review settings and address your ticketing application needs.
• Status cannot be deleted, but can be deactivated or renamed.
  • test in your sandbox first. However, if you create one on accident, then simply deactivate or rename the status to a status you plan on using.
• Automation Rules only kick off upon ticket creation, and do not apply to tickets created via the excel importer. 
• Operational Hours in an Ticketing application should be set based on most coverage of a department's resources in the office. They cannot be set based by a team or teams.  Think of it as typical office hours of 8:30a-5:30p, M-Fri where ALL tiers of resources are available. 
• SLA's can use non operational hours, which means 24hrs x 7 days a week. This can be simply enabled by unchecking the setting called "Use Operational Hours..." in TDAdmin within the SLA configurations.
• Response Template Categories and Response Templates can only be created, and modified by a Global Administrator or an Application Administrator, not techs.

PPM Only

• Creating multiple workflow steps in the workflow template tag means you will always pull in those steps as you create additional project request workflows. 
  • You can deactivate steps you don't need, but they will still show up in admin when viewing the workflow
• If you make changes to the project request workflow and/or the project request sections tab in admin, NEITHER of those will apply to in process items. All new items created after the changes are made WILL see the new settings applied, but old stuff will not see those changes reflected.
• The Risks Register is not visible to client-licensed users in the Client Portal, even though you as an admin/Enterprise will always see that when creating project requests via TDClient. 
• Project Request Workflows will require an enterprise license to participate in, even if that is the only part of TDX that the user will engage with.
• Project Request Workflow step approvals at the Group level only require one User from that Group to approve in order for the step to move on to the next step.
• You cannot convert a waterfall plan to a cardwall plan or vice versa.
• Project Templates need to be Marked Global to allow other Users select the Template from a dropdown when Adding a Project Template to a Project.
• Make sure to add Time Types to Project Types in Admin, then Time Entry will be allowed on an future Project with that Project Type without having to manually add the Time Type to the newly created Project.
• Project Attributes (i.e.custom fields) are global by default, unless you add them to specific Project Types. 
• The majority of Project/Project Request Sections are defined/filled out during the project request review process. Therefore, they are not editable once it becomes a projects, with Role Forecasting being the most prominent example.
• PMs cannot add users to projects and choose any Functional Role to appear on the project, the user's primary Role is what will show if you skip the project request role forecasts. 
• Project requests inside of a project request workflow ONLY show up in reports (such as Analysis, Capacity Planner, etc) once the 'Ready for Reporting' step has been COMPLETED.