TDX: Asset Management

Before Getting Started

TeamDynamix (TDX) has extensive documentation of their own on Asset Management, and there have been a number of TDX Converge Presentations on the topic. There is also an Asset Management advisory group on the TDX Community site which people can join. This article supplements these resources with some basic lessons learned as of 2024.

Assumption

Asset management is being implemented by colleges in both Facilities management and in IT management. The Asset applications can be, and typically are, separate.

Details

Asset Forms

Asset forms can be customized in the same way that ticket forms can, including with custom attributes and the use of dependencies. 

Locations

The built-in Locations functionality is incredibly useful with assets.  Our recommendation is to use that functionality for TDNext users, although it could be confusing to client (portal) users. Locations should be named using the "College - Campus - Building" format, or "College - Building" where campus is not relevant. The custom attributes of College and Campus should also be used. Rooms are optional. VCCS can facilitate importing this data.

Importing data

Always fully validate imports in Sandbox before importing in Production.

When importing asset-related data, there is a not very obvious link to download an Excel template for each type of import. This import template includes lookup values. There is also advice on specific formats related to names, models, and locations.

In general, all other data must be in place before the assets themselves are imported, e.g. vendors. A good sequence is:

1. Add/Import vendors
2. Add Product Types (no import option)
3. Add/Import Product Models
4. Validate/Request Locations from ITS
5. Add/Import Assets

Product Types should not be overly detailed, two levels at most, and our experience is that product types are not very useful because you cannot quickly filter by them in most asset lookup screens. Product Types have to be created manually. On Asset Forms, the Product Type is implicit and derived from the Product Model that is chosen.

We intentionally included the Type and Sub-Type in the name of the assets to facilitate searching (e.g. "CWAS H112 H - Mechanical / Clothes Washer"), because of these limitations in searching by product type.

Related Tickets

For our first Facilities implementation, we were partly focused on Preventative Maintenance. This involved creating a custom Preventative Maintenance form in the Facilities ticketing application. Then we created templates for the core kinds of preventative maintenance under the Tickets cogwheel, e.g. HVAC Preventative Maintenance. Once these were in place, scheduled tickets could be created with the assets pre-attached and responsibilities pre-assigned, e.g. to conduct the HVAC maintenance in Building A monthly. We also chose to put the procedure for maintenance in the template description, but another valid approach would be to attach a KB article.

If you take this approach, when you add, remove, or change an asset, make sure to review and update any related scheduled tickets.

Assets can be attached to tickets and tickets can be attached to assets, and navigation between the two is built-in. Similarly, reporting in the Assets application enables easy and quick reporting as in the Ticketing applications.

You can create tickets from the main Assets listing "on the fly" by filtering, selecting and using the Create Ticket button. You can also do bulk updates in this way.

Configuration Items

We have not made use of Configuration Items so far, since they seem to be more limited than Assets. In fact, the System Office has also used Assets in order to document our application inventory, rather than Configuration Items. This was based on the experience shared by other institutions.

Relationships

We have also not made use of Relationships so far, although we do expect to do so, particularly Parent-Child relationships between IT assets.