Using Service Desk Metadata to Create Your Own Schema Map

Version 5

    Verified Product Versions

    Service Desk 7.7.xService Desk 7.8.xService Desk 2016.x

    The purpose of this material is to instruct the reader to build their own database schema to assist in creating third party reporting.  It should not be used to create operations that bypass the programming of the Service Desk application.  Updating data directly in the database poses serious risks and is not supported by Ivanti or its partners.
    A common request among Service Desk users is to get a map of the Service Desk database schema. The attached document attempts to assist a person to create their own database schema map. It is designed to help those with only minimal understanding of databases. It will be helpful if the reader has a good understanding of database structures.  The documentation does not include any information on the basics of writing SQL queries. Education in this regard can be found in any number of books or for free at
    The attached documentation includes the following:
    1. An explanatory document on database relationships, primary keys and foreign keys. It uses examples outside of the realm of Service Desk that make it easier for the reader to relate to. This document is designed to help those with limited database knowledge to better understand relational databases.
    2. An explanatory document describing Service Desk metadata. It includes database explanations about the lack of published database schemas. It also includes an introduction to the Service Desk database naming conventions. It builds on this to explain the metadata and how to use specific tables to create a schema map.
    3. An .sql file containing two SQL queries as they are explained in the second document. These queries will likely be ready for use on the Service Desk database. The document attempts to explain the creation of these queries and why they work. While the queries are effective, a good understanding of why they work will be more beneficial in the long term.