A knowledge graph for an MSP…

 So I determined that I needed a knowledge base for my MSP.  Here's the previous article explaining how and why I came to that conclusion.

You may be thinking, doesn't my PSA/CRM tool already do that for me?  Yes it does.

Well, sort-of.... But actually, No not really.  It does have the data, and MUCH of it may even have foreign key relationships (Pretty much ALL PSA/CRM tools are backed by a traditional relational database system like SQL), but not in an easy to view relationship model, and very difficult to construct deeply complicated, multi-level-deep queries.

However a proper knowledge graph database (like Neo4j in this case) allows you to write MUCH more deeply complex relationship queries than you can easily execute using traditional reporting.  It also permits you to ask questions about relationships to systems that your PSA/CRM tool has no integration with. (once you start ingesting MORE data sources)

Here's the schema visualization of the RangerMSP data within our graph:

How does this serve us in the real world?  Here's an example:

Because first impressions with a new user with any support organization are so crucial to getting buy-in and active participation we want to ensure that a new user is promptly getting their problem moved towards resolution. 

We could enable that by making sure a new user doesn't have a support ticket languishing in help-desk purgatory.

We want to check to see if any newly onboarded users for our clients are having delays in getting progress for a ticket they have opened.  My question may be something like this:

Show me all clients with an active Managed user plan contract that has a user added in the last 60 days that has an open ticket (NOT set to waiting vendor/client/approval) that has NOT had a charge or change to the ticket in the last 48 hours.  Return the Account, client, open ticket, ticket manager, and the assets attached to the ticket.

To answer that with a traditional relational database would involve a very complex query with several joins, your DBA would hate you, and the performance of this query could be quite terrible (if your PSA tool even had capability of answering this complex query).   This is a walk-in-the-park for a knowledge graph!

Here's how that query looks in cql (Cypher Query Language):

with timestamp()-172800000 as twodays,timestamp()-5184000000 as sixtydays

MATCH (a:Company)←[:CONTRACT_FOR]-(rc:Rangercontract)-[:CONTRACT_CATEGORY]→(ccat:Rangercontractcat {name:'User Plan'}) WHERE (rc)-[:CONTRACT_STATUS]→(:Rangercontractstatus {value:'A'})

MATCH (a)←[:WORKS_FOR]-(c:Contact)←[:TICKET_FOR]-(t:Ticket)-[]-(ts:Ticketstatus) WHERE ts.statcode <800 and NOT ts.name IN ['Waiting Approval','Waiting Client','Waiting Vendor/Materials'] and t.updatedon<twodays and t.createdon<twodays AND c.createdon > sixtydays

OPTIONAL MATCH (t)-[:PART_OF_TICKET]-(ch:Rangercharge) WHERE (ch.createdon>twodays or ch.updatedon>twodays)

WITH * WHERE ch.recid IS NULL

MATCH (t)-[:MANAGED_BY]→(e:Rangeremployee)

OPTIONAL MATCH (ra:Rangerasset)-[:TICKET_ASSET]-(t)

RETURN a,c,t,ts,e,ra

The query results can be displayed visually so you can explore your data:

Or it can be displayed in a more traditional tabular report by changing the RETURN method:

RETURN a.name as Company, c.name as Contact, t.number as Ticket ,ts.name as Status, e.name as Manager, ra.name as Asset, t.problem as Description

While this can provide for some interesting query capabilities, where this gets TRULY game-changing is when you start to ingest OTHER information from your other various service providers.  Then you can ask VERY complex questions about service states, over/under provisioned users, license consumption, consistency, etc.

So what does the Schema look like when you start ingesting much of the data above?  Something like this:

As you may imagine, you can answer complicated deep-data-relationship questions with this knowledge graph schema 

Here's an example of what connected data knowledge graph looks like for a single user:

In the next section I'll review the pre-requisites to start to build a platform so you can design your own workflows and integrations.