hi everybody Welcome to our DPM Academy Series this video is going to focus on kpi groups now this is a Hot Topic and we have quite a bit of content out there already what we wanted to provide in this particular video is a deep dive on the anatomy of a kpi and the group itself and also talk about troubleshooting so we can cover some common pitfalls and also steps to take remediating actions and hopefully put um some power back into your hands to be able to more easily configure the kpi groups for your DPM experience I am the product manager for digital portfolio management and with me I have Aaron Aon do you want to introduce yourself yeah hi my name is Aaron I'm one of the engineers for DPM I've been working with DPN pretty much since it's existed yes you got a lot of good Deep dive knowledge on this especially in the kpi group world so thanks for for jumping on this together with me today yeah excited so if we jump into it we have a couple of key things on our agenda so the first is to just kind of give a basic understanding of a kpi group from like a a definition point of view we do have quite a few resources out there already that we're happy to share for more inde depth on on that aspect of it but what we really want to spend time on are the components or like the anatomy of a kpi group and the common pitfalls for what to do or what we've seen I guess are common issues and then we will jump into an instance and aon's going to give us some really nice troubleshooting tips and we'll actually show you you know in the instance what a lot of these records look like and how you can navigate those to better understand the kpis that you're working with okay so what are kpi groups Aon I mean Where Do We Begin yeah I very like simply put what you can see here on the screen is it's it's a kpi groups in it of itself is really kind of a framework that is built around performance analytics indicators PA indicators and what we allow or what we enable with that group is to more easily be able to map those indicators to your Solutions in DPM so it's a much more configurable easily configurable experience versus having to for say like build out a custom dashboard using our next experience so being able to quickly and easily map and unmap kpis and kind of group kpis together a couple of the key benefits like I mentioned it's built around indicators they are you know easy to configure within the DPM workspace we do provide an inheritance so if you map a kpi group to for example in this view you're seeing it's mapped to a service portfolio it is inherited throughout that entire tree and so it's makes it a lot more simple versus having to map individual metrics or build out you know almost the same dashboard for each individual level you know of that portfolio to be able to view these metrics and then we also include this capability of nesting indicators so a lot of times when we've seen sample dashboards there's a ton of metrics on one page and it be can kind of become a little overwhelming what to look at and so with this um kind of framework it allows you to create parent and supporting indicators so that you can provide your top level most important um metrics that you know you want a user to start with and then when they drill down into that particular metric they can get supporting indicators so additional context to that kind of overarching initial data so yeah there's a lot of flexibility yeah go ahead Aron what were you gonna add I just say yeah and from like an engineering perspective like and you pointed it out but I just want to focus that the addition of making this easy to configure is is really nice because otherwise with having it being spread throughout all the different views you would need to edit many pages is inside of uib so the configurability is is such a advantage to this as a whole with the tables that we have introduced that to me is always like the best benefit I know if I can do it anyone can do it no that's a really good point I'm glad you called that out and that was one of the main reasons why we wanted to move forward with this is is to make it very easily configurable and very flexible so if we dig into a little bit like what actually is a kpi group and what is the anatomy we will dig into like some of these component parts of it but if we look at this left side kpi at the top which represents or I this label represents you know everything kind of within this box we have our kpi record our indicator record and then the indicator source and then we basically group these individual kpi into this concept of a kpi group so this record then has a relationship to these individual kpi records and you can then also create supporting indicators which are are kind of nested within here so yeah and and I think with the probably the best example we have is like our performance snapshot that's like a group and then inside of that we have like many different kpis right exactly and you could put I mean there's no limit right Aon like to the number of indicators yeah that's one of the things too when it comes to configurability like even the supporting ones because then we can show and I don't think we even have a limit on supporting either so when you drill in you can see all the different potentially related indicator or kpis a part of that group no I mean that's really powerful because otherwise that just implemen something like that inside of uib would be very difficult yes and and we do have that particular view so once the indicator is selected and you can view these supporting it does give the user a full breakdown view of all the supporting indicators and even breaking down by child entity so to speak so there's a lot of really rich data that we can provide there and I mean one of the main use cases if we if we think about why you might or or an example of a parent with supporting you might have an incident that is U or like let one of our indicators you mentioned the performance snapshot so we have an open incidence indicator at the at this parent level and then at the supporting levels we include some additional indicators around aging incidents or of those open incidents which ones are you know p1s or p2s or potentially a major incident I think we also have the indicator around like in an incident that was caused by a change so you could also start to get more insights into the makeup of that open incidence group yeah that's really powerful so let's go into the anatomy so Erin this is like your area of expertise right this is not at all simple so do you want to start walking us through how these kpis are structured yeah for sure so we kind of saw at the high level you have a kpi group and so the kind of the example I was asking about was like a performance snapshop we have many that come out of box and that your kpi group is just a collection of kpis once you de dig into that you'll see you have this kpi record and essentially that record one is associated to a PA indicator performance analytics indicator but on our kpi we have some additional values such as like aggregation whether that's average or sum latest score you can also Define like the different chart types how you want it to be displayed inside of DPM now once again you when you drill in further on that KP record you can drill in out to your kind of PA indicator performance analytics indicator and if you are familiar with that well good for you you're you're familiar with the rest of everything now but PA in itself is very complicated so kind of like a I guess a high level is by leveraging PA what we do is we can basically then Define the indicator we can Define what that indicator source is we can Define the breakdowns and we can Define when that data is collected via jobs so that kind of indicator is the where that data is aggregated or is maybe better putting is how that data gets aggregated and so like I said the kind of the the starting point to all of that would be the indicator source so that would be essentially the fax table or the table that defines where this data is being collected from though that could also be scripted and then in addition to that with that indicator Source there's also this layer of conditions too so it's not just where is The Tail being defined but what is that data being defined from essentially yeah there's a lot more L said I think we'll get to it later but there's there's more conditions on the indicator itself as well as the breakdowns themselves essentially act as a dimension but that they also have conditions included as well so all that to say right Erin like it's a lot and the the beauty and the curse of it is that it gives you a ton of flexibility and also Precision to get exactly what you need to report on and how you need to report on it and where you need to report it but to do that or I should say and to do that it does require quite a bit of of effort and understanding of how these are structured absolutely it really starts with that indicator Source like you said getting that data that Source data and then building on it with each of these like layers almost yeah exactly what what we wanted to talk a little bit about in addition to you know this Anatomy were some of those key pitfalls and we will actually jump into an instance so we can look at this in a little bit more detail but I think this is a really nice visual to show all those different building blocks yeah and understanding the layers exist first is it will really help understanding why the score you're seeing is the way it is and understanding like yeah that the anatomy of it is essentially you said layered that that um each way it's almost like it's filtered to then finally get that score and so understanding how it's filtered we really understand what that score is and and once you truly understand it then you can kind of configure things to get that Precision or the exact you know monitor the exact data you want yeah exactly and one thing actually that I think would be useful to call out at this point as well is like it's easy to overlook at the kpi record because much of the configuration and the conditions are are structured here but the kpi record adds a layer of looking at that those scores either as an aggregation or as the latest score of the indicator record and so if you are using this aggregation which means you're taking an average or sum of those scores in the dpmi there are start and end dates and so if you're saying it's the average of a metric then over that those start and end dates that number isn't going to be the latest score that was returned from the the job the PA job it's actually going to be the average of those S those scores over that time period And so that can also cause a lot of confusion again it's it's easy to sort of lose sight of that one that additional layer that's a very common Pitfall that's a good good one to point out yeah well so that's a great segue right like let's get into some of the pitfalls yeah so we have at a high level we have these four pitfalls Aaron you deal with cases and you you support customers all the time in these and so walk us through what you see most common yeah of course yeah so I see these often when when we get essentially a customer opens a case and reaches out and it often these are kind of like the most common issues I see number one missing breakdowns so this is once you kind of get into the actual indicator itself and all of our kind of indicators that we roll we we have our breakdowns and what what I mean by our breakdowns are we have the service offering service portfolio essentially we have breakdowns for all the different solution types in DPM and the configuration someone will add a customer or user will add a kpi with an indicator and when you dig into that indicator level you'll notice that that breakdown is missing those solution types so sorry that indicator is missing those breakdown solution types they're expecting to see and so without that then that data doesn't get cut up or ch popped up or collected in that dimensions for us to even display inside a DPM so it's really important to use the breakdowns that we provide so that is and you can kind of look at any of our existing kpis you can see it and and I'll probably uh show it later but it's DPM service offering DPM service even business app application service all those solution types well it's safe to say right all of our breakdowns are prepended with DPM and then a Col yeah yeah exactly yeah and that's just to make it more consistent and easy to understand like those other the breakdowns that have our definitions so next one uh indicators not mapped to a job this might maybe seem a little obvious but it it is easy very easy to miss that maybe it is associated to a job but you really want to double check that that job is one active and how often is it actually running that's very common that what we'll see is you maybe it is mapped and maybe sometimes it's not but maybe that job has just not been active for a while for whatever reason maybe doe to an upgrade or due to some testing done and then also sometimes if you using your own job you set that job to or using existing job that was been running 15 days and you're wondering why data is not showing up or why the data is still well usually that's a case of the job Bea an issue we have a job right Aon that we ship and yes that we have that set to run every 24 hours so we we have two jobs actually that we have so one is the a nightly job that's run every 24 hours like you said and that's the one that should be active and always running and sometimes it's as simple as that if if people if instances aren't showing data it's because that job's not running we also do come roll out with a second job and this is more of a gather data like historic data so that's intended to be used if either there's data that wasn't calculated and you need to recalculate or not calculate but you need to recapture that data then you can run the historic job the daily job it's very clearly lab DPM daily collection job is the job you want to run want to automatically be running every day so kind of associated with jobs still is that I kind of guess I jumped the gun there a little bit but the they fail to collect data would be the second part of this so there's all sorts of reasons luckily the Pas uh like CIS jobs or their jobs have a job log they have like a dedicated log that actually will tell you if there's errors or Warnings things like that and so often it's actually very verbose and very helpful to determine like oh maybe one of my indicator sources are flawed maybe I customize the breakdown source and the breakdown data is incorrect or the script is wrong you can get all that data actually from the job running and failing and um or even sometimes the job will actually completely run and it will click data for like half the indicators but the other half won't collect for whatever reason so that's always just like a valuable SP spot to kind of start looking in general but definitely common that anything in there could be failing and causing the whole job to fail it does happen and then finally the kind of yeah this last one's a big is a doozy isn't it yeah yeah this one the other ones I wasn't veros on this is going to be even more so this one is is I'll just read it data in accuracy Miss align and misunderstanding and this is an issue of more often not kind of not understanding exactly how the data is being collected so uh what I mean by that is first kpi once again it the shell or the the layers is a good way describing it because at a high level you have a kpi like I don't I don't know um trying to think right so I had like open incidents and when you look at open incidents you're going to think okay so this should be showing open incidents like incidents that are currently open but sometimes that definition is not as clear as an incident that is in State open because what is State open and so a lot of those things have nuance and understanding that Nuance will really help with understanding why a score might not be appearing how it's supposed to appear or how you or how it is believed to appear and that might not just be because of misunderstanding it could also be because of misalignment too you know like we believe that uh currently open incidences are this but some other organization or group might believe it's something else so I guess that can kind of also cause issues so in our case you know kind of going back on that open incident you know you have an open incident then you deal again that's the indicator is also open incident when you get into the indicator Source you see that incident table but then you see also that the definition of open is oh it's a incident that is State open but also is State new and is state in progress that happened yesterday or something and so you're you don't account for those other states so the number is looking larger than it actually is because you might think that it's only open as well as when you you know go a little further now you go into like the breakdowns so the breakdowns are like the dimension in which you gather the data to report so you might have one of our breakdowns is like DPM service offerings and a common one there is very a common Miss is that the breakdowns themselves also have a source and the source we see there for example for service offering is that offering needs to be an operational status and so it could just be as simple as updating your offering to operational and then all the and then you know recalculating the score and then you'll see the score you expect and then then to kind of even go further you also just have how those breakdowns are mapped to that indicator or to that in indicator source so like incident we might uh for an offering it has to be on the service offering form but maybe for like uh to have the score count for the tonomy node it needs to be mapped to the offering not just the service fi and maybe the incidents are all open on the service but not the offering complicated and I'm aware and I'm sure talking about it hopefully made it a little less complicating but it's more just identifying that there's a lot of layers here and so understanding that sometimes the score is not appearing is because one of those layers um is doing something that you're just not aware of did you did that make sense to you Kaitlyn yes no that's exactly right and I think the other aspect would be a misalignment of data so I do have get a lot of questions from customers around how we B you know sort of how the breakdowns work like how a record is mapped to the the solution type so if you know we were talking about service offerings if we stick with that example the way that an incident is mapped to a service offering and if that mapping is not done per our conditions or our criteria then the data is not going to show up so for customers who are maybe starting with services and haven't defined their offerings yet we do have like set conditions where the inent needs to be created against the service offering and then rolled up to the service which is then rolled up to the taxonomy node and and then all the way up to the portfolio and if the data is not aligned that way then the data is not going to show up in DPM there there's a lot of factors there yeah and I think it's safe to say like a lot of like the alignment we've done is is pretty much with a csdm right yes thank you for calling that out so we do work closely with that team and have taken a real effort to stay aligned with that best practice and we do try to make it flexible and support different use cases but because it it becomes really challenging to support every possible kind of instantiation of the data we do kind of have to to have a best practice you know and and have a data model and so that is the data model that we use and um is a good like welldefined model and like white paper and use cases so there is that that support if needed Co should I start showing off some of this what it looks like inside of a service now instance let's get into the troubleshooting eron that's the fun stuff so awesome so yeah so let me kind of start showing this off what this looks like and an actual instance so we're going to start by going to our kpi groups so this is just one of our kind of demo test instances so it might not align exactly with your instances or any sort of like instance um but it's all configurable so it all probably looks different anyways but yeah so right here we're seeing all the kpi groups and we're seeing the different kpi group names and we're seeing how they're mapped as well so actually sorry we're seeing the sorry we are seeing the kpi group and the type of KP kpi group group it can be Associated to so to better explain that like per perform snapshot can be Associated service portfolios so we're going to go there and what we're going to see here is now that we're looking at the kpi group we see the four different kpis that make it make up the kpi group and we're seeing where it's mapped so in this case we're mapped to the Enterprise technology service portfolio and what that means inside of DPM and correct me if I'm wrong Kaitlyn if you go to any of the items that are inside this portfolio you should see this performance snapshot yes that is a that's good so the the call out here is I do get quite a few questions around how to map a kpi group to more than one service at a time and the trick is if you're using a service portfolio then mapping that kpi group to either the top level portfolio so like you're seeing here or to create a kpi group for a taxonomy node all of the children within that structure so if we're looking at this portfolio that includes the portfolio itself all the taxonomy nodes all the services all the offerings will reflect that those metrics is that true for just like if I map to a taxonomy node then all of these services that are under that Texon would also get it like it's not just limited to the portfolio level right exactly that's actually how it Works sort of not regardless but also yes regardless so what I mean is anything that has a child child Loosely use Loosely using the word child because a lot of these like the seem to be relationship isn't child but if it there's a portfolio that has related taxonomy nodes if those taxonomy nodes have related taxonomy nodes or if they have related services and those Services have related offerings if you map a kpi group to anything above that service offering level everything below it like it will inherit down and so if you map something at the offering level there's nothing that will inherit from there and then with the business applications so we also include business apps in DPM if you map a kpi group to a business application the app services that are related to that business app will also inherit that kpi and they have portfolios as well and same rules apply there so the inheritance is nice it it saves the mappings yeah know and and I've had that too I I've heard that same question oh do any of map this to every single service and the answer is no yes and one thing while we're on this topic we do have so we have this performance snapshot which is like probably our most common because we do ship it out of the box and you can immediately map it to your service portfolio and see some of these like fundamental kpis you know being tracked the one call out is we do have a service Performance kpi Group which is is essentially like reflecting these same kpis yeah let's see where did it go oh service metrics yeah if you go to the service metrics up below sorry service metrics y oh yeah the same yes so we created this one for any customers who may not have their service portfolios built out yet you don't have to have a service portfolio to use DPM but you could map those same metrics directly to a service and then be able to see those on the offerings so like a little bit of a call out you don't need to double map like this one this this kpi group should not be mapped to services that are already in a portfolio that has those performance y snapshots yeah yep that's a good call out okay so I'm gonna go back to Performance snapshot so let's dig into a kpi real fast so we'll do we'll do open incidents because that's what I talked about how fitting um Okay cool so when we go here right now we we are looking at a a yeah so we're seeing all what kind of what we bring in here so we one label you can change labels of them which is nice because that's separate from the name of the indicator and and just to be super clear to your point like the label that is nice that is what will show up in DPM yes so make that as clear as possible for your end user for what is shown there yep yep and then what we see over here is we have the the aggregate so like for example in this instance we are using the aggregate not the current score and so this is one of the first things probably worth really pointing out is if you're not using current score then there's going to be this layer of aggregation that happens when you look at the snapshot or when you look at the kpis when they're over a time period so I think 30 days for example the score is going to be an average of whatever the data that was collected over those 30 days in this case and chart type where we can Define the different charts that's how they show up um let me continue down here in related list we have the supporting kpis so if we click on this it's going to look very similar to what we're already looking at it should um and it's the same thing this is kind of where you associate that these are going to be the ones that up here when you drill in yeah anything else to point out on this page before I move on Caitlyn no I I think that's good the other actually one other thing is the order all the way on the right that determines the order with which it will show up in the DPM UI kind of like first second third from left to right yes cool good good call out okay cool now we're goingon to dig in and so we should be going to the actual indicator now so now digging into the indicator we can see number DPM number of open incidents we prefresh everything in DPM with the DPM especially when we're starting talking about performance Analytics product just to really differentiate the ones that are a part of us a part of DPM so I'm not going to go describe every little detail of an indicator there's a lot of documentation on it it is complicated but I think going through the idea of troubleshooting I'll kind of point out some of the areas that lead to confusion first and then I'll kind of circle back real fast through like remediation I think first thing see here the indicator Source we've already talked about this quite a few times but this is where it exists indicator Source this is kind of like the core collection that is being collected for scores so here we can see that it's an incident is the fax table and then the conditions so in this case um and this is going to be the date's going to be update because the way we're looking at it but it's probably a relative date but we can see it's open on today or open before and this is a relative date and resolved is empty or resolved is greater than another relative date and state is not cancelled so this is really important because there's a lot more conditions on here than just opened on today and that's really important to note that's just the first kind of layer on data collection the next layer we're going to notice is breakdowns so when we see these breakdowns we have a lot of different breakdowns they're all prefers with DPM and these are all essential to having the data show up on those solution Pages all of our out of box indicators have them but when adding additional indicators is really important to add the breakdowns that make sense and so we'll dig into one right now so let's dig into we'll do Services actually we'll do we'll just do offerings so now when we look at one of these breakdowns there's another layer to understanding what is the data being collected when we dig into the breakdown Source we'll see the um we can start seeing here that there's even more definitions to what is a DPM service offering so one we know it's definitely on the service offering table but we have other filters here so service offerings with parents and we need to know what the the state is these kind of like are other layers where confusion can occur when uh an incident isn't showing up potentially but uh yeah this is like totally worth noting and seeing on top of that we have the mappings too so we can see some more some simpler mappings like with uh service aail avilability for example we look at the service offering field that exists on that record in order to map those service availability records so and that would be like with AV availability related kpis whereas in for incident we actually have a script and I'm not going to click in and and dig into it but you can see that to basically map a incident to a breakdown we have to have a scripted process of doing that so understanding there is more to it than just potentially using the service offering filled and I think in this specific use case it's actually just using the impacted Service as an affected CI related list is why it's scripted but yeah um it can get it more complicated for things like taxonomy node and service portfolio when we have to look at all sorts of different areas that's exactly right Ain so we do get a lot of questions about how we map data into DPM like where those relationships come from and that's a great place to start actually so that you can start to see actually in the tool how we are creating those breakdowns and the fact that we have taken care to to go through each type and make sure that it you know it is aligned with the cstm but it's also based on you know feedback and how customers are using the tools important factor and finally kind of the last part of this whole Anatomy is the job and so the jobs these are out aab box jobs DPM daily DPM daily data collection and the historic one and so the important thing here is that the DPM daily collection is active and it's set to be run scheduled I could probably show that off and yeah we can see that here so you can see like relative start relative end um but this is important and you're going to have a lot of job logs because it is running daily so our has been ran 194 times and then these are those logs I kind of mentioned earlier that are really great diagnosis tools so as we see here we're getting no warning errors but if there is ever issues this is probably where the one of the places to first start and speaking of that I guess we can kind of start getting into that and kind of like I just said but um yeah often when scores aren't as aren't appearing going to the job log is a great place to start because that will really show you right off the bat if there's any errors and then often we can kind of map oh that air is associated to this indicator and that's why the score is not appearing it's pretty cool warnings can also be noted um and the other kind of obvious thing too is you just want to make sure the job is running and you can tell that because every log is recorded here when this job is ran so that's kind of like always the first spot I kind of look is just to make sure like is the data even being attempted to be collected and a do you find that for customers who are they're using our outof boox indicators they're using our jobs can you talk a little bit about why they might still run into you know some of these errors potentially oh yeah uh customizations or potentially so customizations on the records themselves um yeah I mean that's one big one so like if there's added call well yeah it just I'll just leave it at that at customizations and sometimes that can have unexpected results to the breakdown mappings because they are scripted so things can change that's typically and sorry to interrupt you but that so if if they did do some customizations that would typically make itself known in a in the job logs you would know what's airing so you would know that like okay this indicator is filling and usually we even tell you like this breakdown specifically is not working and so then you could go to the breakdown and you need to have some knowledge to see like oh okay I I understand like you know this customization I did is actually impacting one of the fields that is being used in like the breakdown mapping or more often on the breakdown script the mapping are pretty straightforward but the scripts is where you can potentially hit a snag due to customization um sometimes also like the truth be told I mean like I I think at this point we have much more confidence but I mean in the past we have seen bugs introduced by us it happens um but we haven't had that a long time usually that's not that's complicated to get into but there's little reasons here and there that can happen for the most part nowadays yeah it's it's usually due to configuration or customization that makes sense yep so let me continue so I will look here just to make sure everything looks good and I will say generally nowadays everything does look good so then we have to kind of try a little bit harder so I'm going to go back to the indicator okay now that we're back on the indicator I'm going to go to analytics Hub so this is probably what I'd recommend for most people like I said the score sheet it's just important to know kind of how this all works it all gets recorded in a score sheet but analytics Hub is a definitely much friendlier tool to use and honestly as powerful if not more powerful and the reason why I say that is because here you can actually break down by individual breakdown items and it's really neat so for example let's say if you know I go to get access control I'm expecting to see 14 but I'm only seeing 13 well if I go to show records um you can actually see the records that are showing up there so you can figure out based off of that what records additional records are showing up that you don't expect or or which ones are missing that's why I I really like analytics Hub um to actually do like a deeper investigation because I can see like the buy breakdown and then see the individual records too plus you get a history and you can adjust your window as much and little as you want and this is also a great tool RAR to to compare scores between what might be showing in DPM versus what is showing in here yeah and and this is like really important because this especially with that extra layer of aggregate um it can create kind of some misunderstanding if I know like okay well it's 13 for this whole month why on I kind a bad example for average but if I look here and let's say I've had some more variant here right and I'm like well it's 13 but then in DPM it's telling me it's 14 or something and then you can really understand like oh that's just because it's an average and I think there's even a way yeah and even here it identifies the average so what you can do if you're really confused is uh set the time frame as the same and you should see the average matching if if it is average now there is some as well so you can kind of see that those numbers should match up with what's in DPM based off of whatever aggregate's on if it is on to be fair yeah that's a good good call out um but yeah this is a very very powerful tool finally though so okay if it's not shown up in the score sheet then it's probably not showing up here in analytics Hub so what do we do next so I go back to the indicator okay cool and so when we're at that point you know it's got to be related probably to a mismapping of the core data and so I've kind of already walked through it from the very beginning when going through the anatomy of everything but it's really understanding from that point forward if it's not shown up at any of those two points and your job is running that it's either because of the way that you're using the record so what I mean by that is the source record so if you're expecting an incident to show up and it's not showing up well that might be be because of any one of those kind of like previously mentioned areas of breakdowns breakdown mappings indicator Source breakdown Source all of those areas could be reasons why it's not working how how you might expect it to work yeah and and unfortunately with that there's no easy way to solve it you really just kind of have to dig through those like prominent areas that can lead to confusion and do you find customers would potentially like modify the breakdowns or create their own breakdowns and be able to map those and use those instead that's a really good question about customizations in general modifying the breakdowns I don't see very often and would probably not recommend for most cases um what we do see a lot of configuration of though is the indicators and even the indicator source to some degree though you need to be careful customizing that just because it can impact many indicators with an indicator for for example additional conditions is something that you can configure and and that's totally okay to do where there is something worth noting though is if wanting to add your own indicators to kpis and so when doing that it's just really important probably the most important thing is to leverage our breakdowns and because these are the breakdowns we consume in DPM so by defining you can have your own custom indicator but you want to add our breakdown and these specific ones to it and there is some difficulties with that specifically around scoping so you could only add basically you can only associate different PA records to each other if they're in the same scope so if there's a indicator you want to use that's in a different scoped app for example you wouldn't be able to associate our breakdowns to it so that in that case the best solution is actually to duplicate the indicator in the scope of DPM and then add the breakdowns and you shouldn't have an issue of of data missing I don't believe because it is all going to the same sort of like facts table in the end got it okay that makes sense I think that is helpful because we do encourage right like we we ship quite a few kpi groups and quite a few indicators I think the last I checked we ship a total of like 110 indicators or something well right now we have 75 but that's not including all of the formula ones right yes so there are different types the formula and automated and we do have formula indicators I think the note would be we expect right a level of modification of those because we know that it's it's a good we try to provide a good I'm going to use the word generic or standard you know starting point but in terms of flexibility and and getting the exact metrics that need to be tracked for your organization we do anticipate that they would need to be created and and ideally it can be done fair in a fairly straight forward manner at least the the kpi groups created and then mapped yeah and and definitely I would think if for most customizations the best level to do it besides the kpi would be to do it at this indicator level in most cases that should be fine but yeah absolutely I mean that's kind of PA was designed to be configurable and the only real kind of pit though with customization is is really just some of the scope issues but once you get around that it's very configurable are there any other limitations or suggestions or any other tips that you've learned having worked with different customers and and seeing different approaches to this that's a good question yeah that's hard I I think I think the main thing is when we're using so customers are going to have their own way they want to use data and that's potentially and that's fair often for example with breakdowns we might deem an application service to be one thing or we might deem a service offering that needs to be in a certain State and you can configure that and I I think that's fine to fit your model but there is just kind of just to be aware that some of these changes can be overarching that would be the number one thing so when we sometimes you know I'll look and notice oh yeah this one indicator or something's not working the one thing is not working how how it's supposed to work and it's because oh there was changes made somewhere else to some other indicator whether that be like the indicator Source or the breakdown mapping so that would be kind of the the one thing I would say that's really worth noting is like I kind of mentioned a little bit earlier is if you're going to change the indicator Source directly like the values the definition of a source just be careful because that can potentially imp other indicators and that's fine to do because that might be what you want to do you might want anything that's referencing open incidents to not involve resolved or necessarily state canell or something and that's totally fine to customize just be aware that it can impact many other kpis and indicators and often the other solution is just to create a brand new indicator indicator source and just swap it in if that's the case if it's just for this specific indicator that's just one example of just kind of like a general just kind of be aware of the ReUse of many of the items that exist in PA yeah that's a good call out the other the other thing I wonder about is the jobs so we have our jobs that run every 24 hours and I have gotten feedback or requests about seeing data more I I'll use the word timely so that it's not yesterday's data but it's maybe data that was like four hours ago or you know whatever the occurrence would be for that again do you recommend creating a new job and you know specifying that Cadence versus modifying the jobs that we have shipped that's another good question no I mean mod modification is it's fine and the reason why is because we rarely ever update the job itself what we do update is the kind of mtom or the indicators Associated to the job so if you do configure the job then if we introduce brand new indicators you will still get those indicators Associated to that job I'll leave that as a interpretation if that's a good or bad thing depending on your if you know if you want if you don't want newer indicators and you want indicators to be set the way they are then creating your own job is is the way to go and that's fine too you can just duplicate it make sure to turn the original one off and just run your new one but it really just depends on that use case do you want newer updates to in ter well do you want new indicators if we introduce new ones to show up automatically then just update the existing you don't want that to happen then just create your own job and same thing can and you can run it however you want um like I said we run it daily um you could update that to run sooner though probably just want to make sure it just doesn't overlap like collection times overlap because that can cause delays and potentially cause kind of a weirdness with data got it very good good question all very good information um I'm asking because I get these questions too and I I don't always know the answers so yeah I think this will be super helpful and thank you so much for walking through all these these tips and how to you know take actions not only based on what you're seeing but then what to do making sure the jobs are active making sure the indicators are mapped to jobs and making sure the breakdowns are mapped to the the indicators so if there are any other final thoughts that you have or any final words of wisdom you want to leave us with I think we can we can wrap up today's video yeah um no the last thing I was just going to say is you know this was a pleasure to do and I hope it's helpful the kind of last thing I to say though overall is PA performance analytics is it is a pretty large product and there is a lot of documentation there so when kind of going through kpis we have documentation in DPM but it's it's always always worth to kind of read up on PA and they are very well documented so definitely could help as well yes and when in doubt please don't hesitate to open a case we're here to help and we want to make you as successful as possible as quick as possible with that thank you so much Aon it's always such a pleasure to chat with you and kind of really dig into these topics I think it's so fascinating yeah thank you Caitlyn always a pleasure to talk to you too all right till next time y bye