For those who may not have noticed, we have a powerful integration with TeamDynamix that allows asset records to be created automatically within TeamDynamix based on data collected by AllSight, and various fields to be synced between the two systems. We have just released a script update that includes several valuable enhancements, but if you’ve used the existing script, it is important to revisit your script’s settings as soon as you have updated the script to the new version as well as upgrading KeyServer to 7.9.0.5 or later.
If you’ve never used this integration before, you don’t need to read this blog post, since it focuses on changes and how to update your configuration within the new script. Instead, simply read our TeamDynamix Integration TN. If you’ve used the older script, hopefully we already emailed you the information contained here – but if not, email us at support@sassafras.com to let us know you’re using the integration.
If you are using the older version of this script, please be sure to read the first section on behavior changes and settings that will need to be explicitly selected – even if you are not interested in the remaining improvements. You must be upgraded to KeyServer 7.9.0.5 or later in order to see many of the new options described here. If you are about to upgrade KeyServer, use 7.9.0.6, which has just been released.
Behavior changes after upgrading script
First and most importantly, you need to understand a few behavior changes between the old version of the script and the new one. While we always strive to seamlessly carry over existing functionality, once in a while it is necessary to make manual adjustments after an upgrade. If you upgrade the script without upgrading the KeyServer to 7.9.0.5 or later, there will be two changes. First, the option to “Set Warranty Date from KeyServer” will go away from the UI – it has not worked for several months so this is not in fact changing a behavior. With the server also upgraded you’ll have a new option to sync the Replacement Date – more on this later. Second, whereas the Location from TeamDynamix would sync to the Location field in AllSight with the shipping integration, this will stop syncing with the new script. Again, there will be a more flexible option for this once the server has also been upgraded.
If you have already upgraded the server to 7.9.0.5 or 7.9.0.6, if you merely upgrade the script without doing any further configuration, a number of fields will stop syncing – specifically Asset ID, Owner, Department, Location, Lifecycle Stage, and Warranty Date. By specifying new options, you can restore almost all functionality, or choose from a number of new behaviors. There are three main areas of attention to be aware of.
1. You will need to choose a number of options in the new “Mapping” tab if you want to preserve as much behavior from the old script as possible (alternatively you can select much more flexible new behaviors).
2. The option to “Set Warranty Date from KeyServer” has been removed. Instead, you may wish to turn on the mapping for “Replacement Date” – which uses a different field from the AllSight computer records. Or to continue to see the Warranty Date from AllSight, create a TeamDynamix Attribute names “KS: Warranty Date”.
3. Locations in TeamDynamix will be created differently. In the old script a single string was formed using the Location and Room fields from AllSight. In the new script, Locations in TeamDynamix can be created from values in the Building field of AllSight, and TeamDynamix rooms can be made from AllSight rooms.
We will touch on each of the above in more detail further on, along with describing all the new functionality. Beyond the three points above, you should look through all the new options and decide which will best suit your environment.
More extensive field mapping
There are several different categories of fields that will be synced between the two systems. First are the core fields of Serial Number and Name. These are always synced and have a well defined place in both systems. On the other extreme are properties that initially only exist within AllSight and don’t exist within TeamDynamix until the desired Custom Attributes are created. For these, the integration will populate data within TeamDynamix whenever the fields exist. To ensure that a field exists solely to receive AllSight data, we use a short prefix, which historically has been “KS” (more on this later). Finally, there are a number of fields related to asset management that exist within both systems, but depending on how you use these systems together you may or may not want them to get synced. For example, you might want to change a lifecycle stage in TeamDynamix and have that sync to AllSight – but conversely you might want to initiate that change in AllSight and have it end up synced to TeamDynamix. So, we have added better controls for this. There were 4 relevant options in the previous script, which are turned on in the screenshot below:
After upgrading the script, these sort of options will move to the “Mapping” tab in the script settings. Your settings for Computer Model and Purchase Date will be preserved – if the sync was turned on they will be set to “Sync to TeamDynamix” and if they were off, the new option will show “Do not sync”. Note that for these fields, the sync can only happen in that direction, never back into AllSight. Every other option in the Mapping tab will be set to “Do not sync”, even though this was not the behavior of the old script. In particular, if “Set Lifecycle Stage from KeyServer” was on before, you will have to turn it on in the new script. Furthermore, the old script synced some additional fields even though it did not provide any way to disable that sync. So, if you would like to mimic the behavior of the old script as closely as possible, configure the Mapping tab as below (assuming you had all four relevant options turned on, as in the prior screenshot – but with the caveat that Warranty can no longer be mapped):
The values as shown above correspond to the previous behavior, but now there are in some cases quite a few more choices that you could use instead. For example, looking at Asset ID we can see the following five choices, which give very fine grained control over how data should flow back and forth.
You might wonder what the purpose of the last two options is. Basically they allow data to be written both ways, but only if on one side there is a blank value. In other words, suppose that you manage Replacement Dates primarily in TeamDynamix. You might then choose “Sync to AllSight” to bring those dates into the AllSight databases. But now suppose there is some computer for which you have specified a Replacement Date in AllSight but not in TeamDynamix. With “Sync to AllSight”, the value will never get populated in TeamDynamix. Some day if you edit that record in TeamDynamix, then the value in AllSight will get overwritten by the TeamDynamix one. On the other hand, if you select “Sync Both Ways (TeamDynamix overrides)”, then you will ensure that if both systems have a date, the value in TeamDynamix will “win” and overwrite the AllSight one – but in the scenario above where you start with a date only present in AllSight, it will get written to TeamDynamix. Note that when syncing both ways you must choose either AllSight or TeamDynamix as the overriding value. There is no option to use the most recently changed value.
There is one field that cannot be synced from AllSight to TeamDynamix – Owner:
The reason for this is that within TeamDynamix the owner is a User, which is a complex object. It has data fields that may not be known within AllSight, and also ties closely to roles and permissions, reporting structure, and any number of other things in TeamDynamix. Because of this, we do not want to create User objects in TeamDynamix. So the only option available is to sync the Owner into AllSight (where we just have a text field) or not to sync at all. On the flip side, there are some fields that can only be synced into TeamDynamix and not back into AllSight.
We only provide that option for Model because it is a property that is discovered by our client. There is no point in overwriting it because it would simply get set back to what it was before. Other fields that can only Sync to TeamDynamix are Supplier, Purchase Cost, and Purchase Date. The reason for this is that TeamDynamix stores these fields directly in each Asset, whereas in AllSight, these fields are part of a purchase record. Because many computers can be associated with a single purchase, we could encounter a configuration where TeamDynamix has multiple values for what can only be a single value in AllSight.
New fields that can be mapped
As mentioned earlier, even though “Set Warranty Date from KeyServer” was selected in the screenshot of the old script configuration, it did not translate to anything. It used to map to “Expected Replacement Date” in TeamDynamix. Originally, AllSight did not have a Replacement Date field, and we decided that Warranty Date was close enough to equivalent, and gave a choice of whether to map it or not. Since then we have added an “Expected Replacement Date” field to AllSight, and as such this is the field that should be mapped, if anything. You’ll see a new option to map that field, but because it is different than the old field, you must turn this option on if you want to use it. If in fact you want the warranty date to become the expected replacement date (in both AllSight and TeamDynamix), the new script for Gather Warranty Dates has an option for this:
Note also that we have a separate script specifically for Set Replacement Date. This script has various options including setting a date relative to the Warranty Date. A screenshot is below – note it has additional flexibility such as setting a replacement date 12 months after the warranty date:
Besides the Replacement Date field, the options to map Supplier and Purchase Cost to TeamDynamix are new (these would come from Reseller and Unit Price of the purchase record, respectively).
To summarize visually then, the Mappings outlined in blue below will behave just as they did in the older script (although some can now be turned off which was previously not an option). The mappings outlined in orange are similar to older functionality but you should understand the caveats explained earlier. The mappings outlined in green are new with this version of the script.
New Custom Attributes
There are also some new fields that will be automatically populated with data if they exist. Two of these are “KS: Disk Capacity”, and “KS: Disk Available”. The values are strings like “1.5TB” and “320GB”. The AllSight server (KeyServer) must be 7.9.0.5 or higher for these to work. These fields are much more readable than the previous fields which were purely numeric (KS: Disk Size and KS: Disk Free). Furthermore they help to reduce the number of changes that will get recorded in the History Feed in TeamDynamix, since the Disk Available string is not as precise as the Disk Free number. There is also a “KS: Disk Free Percent” field, which again requires 7.9.0.5. Another field that is very useful to have, but which changes frequently and fills up the History Feed is “KS: Last Login”. For an actively used computer, this would change nearly every day. With the new script and 7.9.0.5 you can now create a text field named “KS: Login Recent” which will have a value of YES if the last login was within the last 7 days, and otherwise will change to NO.
Prefix option
In order to correctly identify which custom attributes in TeamDynamix were created to accept AllSight data as opposed to any other data, we have always used a prefix on column names. Previously this prefix was “KS” so you would create attributes such as “KS: Last User” instead of simply “Last User”. In the new script we have provided an option to change this prefix, e.g. “AllSight” or “Sassafras” as we have done in some subsequent screenshots. Whatever you type in the text field will additionally get a colon followed by a space. Note that ultimately you can specify any kind of label you want in a TeamDynamix form – but this column name will be the default value in forms so can save some additional configuration if it is a value you want.
TeamDynamix Asset link in AllSight
We have added a new option “Link Service URL to TeamDynamix Details”. When turned on, a link to the TeamDynamix Asset details will be recorded in the “Service URL” field of each computer in AllSight. This then gives you an easy way to check if a computer has tickets in TeamDynamix. Note that our JAMF and Intune integrations also will populate the Service URL field, so you may wish to leave this option disabled if you use those other scripts as well.
Sync of display assets
In our 7.8 release, we added code to automatically discover displays connected to computers with our client installed. Many of our clients have found this extremely useful, and now you can make that data available in TeamDynamix as well. To turn it on, just enable the “Include Display Devices” option as seen above. Just remember that in AllSight, ANY display connected to a computer with our client installed will be discovered, and with this option turned on, will become an Asset. This includes personal monitors users connect to their work laptops at home. We are discussing possible features that could alleviate that, but we wanted to err on the side of including too much rather than not reporting on enough.
Once you turn on this option and run the script again, you will see Assets get created for Displays. As with computers, you can create Custom Attributes in order to get some of the specific properties of displays, e.g. Width and Height:
Additionally, you will see relationships between Computers and the Displays that are connected to them, as below:
Although this option is very simple to describe, it’s probably one of the biggest new features we have added to the integration with this release.
Thank you
We hope these new features are as useful as we imagine they will be. If you have any questions at all please don’t hesitate to email support@sassafras.com .
Subscribe
