From Signals to KPIs: Building Reusable CS Metrics with Gainsight’s Data Designer

(audience applauding) Hey, thank you for that. As you can see, I have the physique of a level athlete, right? But yeah, it's been a few years since I've done that, but it was a pretty exciting time in my life. So anyway, we know why we're all here, I guess.

I wanted to say first of all, because I missed it this morning, who's fired up to be a pulse? (audience cheering) Good. I'm so thrilled to hear that, because I have so many things I want to talk about. But first of all, surprisingly enough, as few people in this room know, I'm an introvert, and it's the funniest darn thing because I have such a big personality and nobody believes that about me.

But introverts lose energy as they have social interactions. Pulse is the one place where I don't. It's all about this community, all about the energy, all about connecting with people that are in the same place that you are, and doing the same things that you are, and facing the same challenges, and it really just energizes me. So I'm thrilled to have you here with me.

I guess we'll go ahead into the first slide here. All right, so I'm gonna start with a slide-o. I wanna know why you're in this room. And this is important to me.

So are you here because you need to talk about KPIs for your CSMs? Are you just looking for a good story? I'm a good example, so always has great stories. Are you here because you wanted a technical session and you couldn't find any other one in the app?

Or did you just end up here or was the only one that still had space and you just don't wanna be rude and now you're gonna stay with us for the next half an hour? So let me know what you think. While you're doing that, I'll give you a little background on myself. Using gain sites in 2018, I was a CSM at the time.

I came to my first pulse in person in 2019 and 10 of us CSMs were going room to room to room for the same content. And we were hearing the same message and it wasn't very exciting. And I was just thinking to myself, why am I sitting through this when we're not collectively earning anything more? And I saw out of the corner of my eye a dark room in the corner and it had a little sign that said technical admin training.

And of course I didn't pay for that but I snuck into the back of the room and I acted like I should be there. And then as they started to show the slides and I saw Journey Orchestrator and I saw the flow charts and I started moving a little closer and I said, at the time I was a high touch CSM. I started to see the power that Gain Site had to leverage scale that we weren't doing at our company. And so that was my first foray into technical on Gain Site.

But it definitely was an eye opening experience for me and I'm one of those people that move from CSM to the Gain Site admin role. So I hope there's a few of you in here that are maybe something like that. But that's, now I'm on my sixth pulse in person and I live for this. So anyway, do we have results?

Oh boy, that's not what I was expecting. All right. (laughing) All right, so maybe we'll be able to help you. I'm always hoping for number three.

No, sorry, it's up there. Number two, the technical sessions. I do, when we get to the end of this, there is gonna be a survey. If you want more technical sessions, please let me know.

I will keep doing them. My community will keep doing them because we know that there's other people in the room that wanna keep learning a lot more of these technical skills in Gain Site. So anyway, and then added bonus. I've already told you I'm a nerd.

You can tell, but if anybody plays Pokemon, I'm still trying to take my kids down. So let me know. I'll help you get some points. All right.

So, Deltech has been a Gain Site customer since 2018. We have about 17,000 customers in our instance with 23,000 relationships. When I joined the team two years ago, I was the third member of the CSOps team. We're up to nine now.

Plus we have an enablement team. So we're doing heavy investment into Gain Site. We also added PX a number of years ago, still working on getting that data in the CS, but we're starting to finally leverage it for signals. And we just recently acquired Skilljar.

So we have a new team working on that as well. All right. So the challenge we were facing, our CSMs, like most places, were measured on renewals and expansion. But in 2025, we restructured and created a renewal and growth team.

They took most of the quota for renewal and expansions. So the CSMs were left without good ways to measure their performance. And so we wanted to start talking about how do we measure their performance so that they could get their variable comp. Dashboards weren't enough.

And the reason for it is we don't want a referenceable place where you just go and say, okay, well, let's pay them for this KPI and that KPI. We have a compensation team that needed the data to come over in a structured way on a monthly basis. So we needed to have a good output that would be reliable and referenceable. But then the CSMs are now shifting from a predictable model for their variable comp.

Used to be focused on renewal and growth, but now it's on KPIs that they've never had visibility into. They don't even understand a lot of these KPIs that we put together. It's pretty straightforward, we'll get into that. But they wanted to see that in real time so that they could forecast their variable comp because it's their take home, right?

We don't want to leave them without. We came up with some basic KPIs. I know these are basic, also helps with the presentation. The first one is our customer touch points.

Looking at regular valuable touch points with the customers either on a monthly basis or quarterly. Our measurement for that, since every one of them did it, is one business review CTA closed each year. Then our customer goals, if you haven't used the customer goals feature in Gainsight yet, or if you are, we're looking at those goals, but we're looking for quarterly updates there. So, excuse me, either creation or update of a goal within each quarter.

And then new customer onboarding CTAs, we had two KPI tasks on each of those. So we're looking at closing all of those KPI tasks each year. So, I'm gonna take a drink, I'm sorry. What's that?

All right, sorry about that. So, foundations, wanna talk about why we use Data Designer and building the right data architecture to support these efforts. So, key requirements and design elements for us. First of all, we always wanna start with our maximum population.

So we're looking at what's the maximum potential of objectives that a CSM can do. So, in most cases, for us, it's our active relationships. So, that's the maximum KPI you can get is X of Y for your relationships. The key here was that if you've done anything in Gainsight, if a manager comes to you and says, "Show me all of our accounts that churned "that have a risk CTA," that's super easy to do.

You go into your report, look at the call to action, so you can produce that. But now we have to show a lack of data. So, the other ask is, "Show me all the customers "that churned that did not have a risk CTA." That's why we have to leverage Data Designer. Your maximum population is the relationship list, but then how many had a CTA or did not becomes the numerator and the objective.

So, Data Designer really takes it beyond the data that's in there and brings in some logic so that you can also look at lack of data that's key to your measurement. I mentioned numerator and denominator a little bit there already. We always try to target that with KPI measurement. And so, the benefit of that is that maximum population on the bottom, it may change, but we don't want them to ever exceed that maximum objective population.

And then your numerator, we can look at it as we go on or iterate on it. So, what I'm talking about is, right now, we gave you some very basic KPIs. So, it's a business review that's closed success. But maybe next year, it's business review closed success with a PowerPoint presentation, or it has a timeline entry, or it has some other factor.

We can always just feed that into the numerator. So, where they achieve the objective, we can tweak because right now, we just have those buckets of success over your potential number of success. We also decided to tag relevant records with a KPI year. This helps a lot with filtering and with testing.

We did it in the backend because we didn't want our CSMs to mess with that data. But doing everything we can to make sure that that body of data is easy to get to. It also helps with annual rollover, right? So, one of the measures we talked about were the goals updates.

You can have goals that obviously span multiple years. If it's created in 2026, it still applies. We can then roll it forward, whereas your business reviews in a calendar year would stay in the calendar year. So, it gave us some flexibility on that as well.

And now, I just talked about flexibility. So, key requirements from the users. We needed to build in flexibility. One of the user stories we had was we have customers that we might have 20 customers in GainSight, but they manage them as one.

And that's because of how it was structured in Salesforce and how the contracts were structured. But now, we don't want to measure that CSM on all 20 of those accounts because they log everything at one. So, we need to be able to omit records so that that maximum population comes down and they're not being held to a different list of target. I'm going really, really fast.

Should I slow down? (laughs) And then, another user story that I thought was kind of interesting was we have CSMs around LEAF. And didn't really think about that when we designed it, but we had to start talking about the ownership of the KPI versus who did the work on a KPI. And there is a difference there that's important to note, but what we ended up doing was we kept the KPIs with the owner and then the compensation team will do the debits and credits for people that do the work instead.

So, it keeps it very clean. We had a lot of people that came back from LEAF and they're like, "Wait a minute, "somebody did my business review and I got credit "or I'm not gonna get credit for it "because they did it while I was out." And it got a little hairy, so we had to build in a way that we could handle it. It was handled outside the system, but we wanted to be consistent on our structure for KPIs so that it was manageable. All right, so the easy part was the data designer for business reviews and onboarding tasks.

Starting with your relationship for us, it could be company for you or any other object, but the maximum population. I'm just bringing in CSM and relationship. We've brought in a lot more, but that's what you need to move forward. Always bring in your GSIDs.

Always bring in your GSIDs. That's gonna be your key for connecting objects and connecting data. So, do make sure you do that. It's a hard lesson learned if you don't.

So, that was the maximum population. That's what becomes the bottom of that first metric on the top, right? So, first metric, wow, bottom and top. So, the one relationship, the maximum population on the bottom and the green there.

Then we went to the call to action object and we grabbed the number of business reviews and the number of business reviews closed. That becomes the numerator for that top metric in the green. It's important to note that we went Boolean with this. So, we're looking at one or zero on those business reviews so that they cannot exceed that maximum population on the bottom, right?

Good user story here is if you have a CSM that does quarterly business reviews and they're tagged the same way as CTAs, we didn't want them to overachieve with this account. So, we needed to make sure that we're only giving them credit for that one KPI per account. And then we fetch from the CS task. This changed the denominator completely.

We're looking at the total number of CS tasks that are KPIs. That becomes the denominator. And then whether or not it was closed becomes the numerator. We're always flowing that structure.

We can always change the filters of what qualifies as they're done with that objective. Sorry, I'm gonna get another one here. The not so easy was the data designer for quarterly goal updates. Started with the same large population, maximum population, your relationships.

But then when we looked at customer goals, we brought in number of goals created, updated, the total number of goals, but we also brought in fiscal quarter. And so now we've gone from the maximum population of relationships to relationship times four for the quarters. So, your maximum potential here grew exponentially. We still are looking at on the bottom one relationship per quarter.

And then on top, whether it was at least one goal was updated or created in the quarter. That becomes your numerator. Again, one or zero on top. But the challenge here was that this worked great in Q1.

Because Gainsight is great about what's the data look like right now. Once you go to historical, the data designer can't see backwards in history. So what we needed to do was add now a historical object and that's in the bottom there. So we've got that goal updates by quarter.

So we took the data designer, took the output, used a rule to write that to an object and then the object became part of the logic now. It's a great little trick. You don't have to use data designer as your initial feed. You could use a rule.

But we wanted to be consistent since we were doing most of this in data designer. Okay, and then bring it all together. Your relationships, call to actions, CS tasks, and the goals updated by quarter, merged and transform all of that, created another data designer that now summarized the information. If you remember the original output was we need a single line of record that needs to go to the compensation team and it needs to be consistent.

So that's that summary that's on the top new D, new DD, the top right corner. But then the users wanted to have that real time forecasting. They want to see where they are with each of those KPIs. And that's the dashboard.

So when we built this out, the summary is important, but the data is important as well. So maintain all of that. When you're building out your data designer, just keep it within the data set as much as you can. All right, so here's a copy of our KPI dashboard for one of our CSMs.

You can see at the top, that's the file that's going over to the compensation team. This CSM had 106 customers, business reviews, they've closed 16 of 36. So they haven't all been created because we create them on a quarterly basis. So those will expand as we get further into the year.

Their onboarding tasks, you can see they've completed seven of eight. And then the next column is kind of interesting. So I talked a lot about maximum population. Right now here it matches, right?

Your client list is 106 and the maximum population for goals is 106. There's always growth and attrition in a book of business. So that 106 may grow. It's never gonna get lower in our model.

And the reason for that is that we're looking at the maximum population for each quarter of the year. So we still wanna have that upper bound. It's almost like a check for us to make sure that our CSMs are not overachieving within a bucket. So that maximum population needs to be a little bit controlled and referenceable.

Then we go into what the CSMs are interested in. When I wanted to show where they are with business reviews, I'm always like more data is better. Let's just give it all to them, build out a report, they can sort through it, you know, reports are super easy, put it up in the filter, it's all good. No, we gave it to the users and of course they said, all I want is a to-do list.

I don't care about the rest of it. So we went with a kind of a hybrid model. You've got your list of their to-dos for their business reviews but then off to the right, the pie chart, that gives you all the CTAs, the business reviews, CTAs and all the status that they're in. You can still drill into it and get to the ones that they've closed and that sort of thing.

So always thinking about usability and sometimes I'm wrong but definitely the users helped us out with that. Bottom half of the dashboard, this looks very similar. It's for your onboarding tasks. Pie chart again, they've completed seven of eight.

They have one to do. Just quick, easy reference. And then down at the bottom, I think we may, this was an interesting challenge because again, we're trying to show the lack of data and positive data that exists. But the left-hand side is your accounts that still need updates to their goals and then the right-hand side are the ones that have had their updates already met for that quarter.

So one of the challenges and pitfalls that we found on this dashboard is it became about closing the CTA and less about doing the work. And so coming from a CS ops position, I understand that but the number one question I got was, all I have to do is close it and I'm good? Well, yes, but that's the technical explanation. It's more about the spirit of it.

So if you're not having a valuable conversation and logging goals and information, then don't check it off. That's more enablement, but it also led us to a place where now we have to start looking at the evidence, whether they closed it with value or not. And we're doing that through several different ways. One way is another data designer, which we have way too many of them.

But we have a data designer that checks that and we're also using AI to go look and make sure that these CSMs are not just closing 300 CTAs in a day. One of them tried it. We had to coach them into what's right. But definitely something to watch out for.

All right, so data designer tips and guidance just in general. First off, your data designers are only as fresh as the last run. You know, users are gonna say, "Hey, I've been updating my CTAs "and it's not reflecting on my dashboard." That's because data designers run on a schedule. There is no way around that.

It's actually smart. Gainesville is not supposed to be real time on a lot of this. So you will have to coach them through that. And it was probably our number one ticket problem was I'm just not seeing my changes.

Designs are temporary storage. If you need longer term like we did for our goals, looking at the quarterly output, bring it into a custom MDA object. Number three there, you can create data designs of data designs. And we did talk a little bit about that already but I don't think he's in here.

There's another admin that I worked with for a while and he was just mentioning that to me and I was like, "That's a crazy thing. "That just opens it up completely." The downside of it is if it's complex like that, now you have to start scheduling them in order. So you have to plan how long does it take for it to build and when we want the next one to fire off. You can do data designers, I think about every two hours.

I think I saw maybe a one hour but I'm not gonna do that to my system. So we usually do ours about every four hours and we run them on schedule. And we cannot chain them together. Like I said, you have to do it manually through scheduling.

Future state, I would love to have the ability to create a DD chain or better yet, a DD chain with rules peppered into it as well. Run things in order, it's logical and running at the same time. We don't have it yet. I don't know if we'll ever get it but I'll mention it.

Okay and then this one is the number one pitfall for data designers. Everyone who uses data designers has seen this, I bet. But always start with a population when you're building and testing. Always start with a population you know is gonna come out on the bottom.

And the reason for it is if you're doing two fetches and then merging and you fetch 20,000 records and 10,000 records, Gainsite's going to give you a preview of a thousand records on that fetch. So if I grab my 20,000 customers and I grab 50,000 relationship persons, they're gonna give me a thousand random records and I go into that merge and my merge is gonna say, yeah, you got no matches. It's because of that previewing feature that's in Gainsite that the first time you see it, it'll drive you nuts. So just be aware that it can happen and the fix for it is when you're building and testing, do the same filter at the top.

Put in a CSM on either of those fetches and then you got a pretty good chance that all the records are gonna match. When I'm troubleshooting data designers or even rules that use a similar setup or structure, I'll just put in a single customer on the fetches. And then I can see exactly what the data is and where the merges are happening and ensure that it's happening correctly. So number one thing that you have to watch out for, if you're new to Data Designer or databases in general, please learn about joins.

You can find this information everywhere but just look up SQL joins. If you don't understand joins, your data is going to be a mess. And I've, I didn't mention it earlier. I've worked in six gain site tenants now in the last, oh gosh, four or five years.

And I've seen it all, right? So if you don't understand joins, it's going to affect you. And related to that, just be thoughtful about your keys and your joins, especially with one-to-many. If you don't know how a one-to-many join works, if you have one on the left and it joins to five on the right, you now have five records and you may not want five records.

Worst case, or even worse than that, is if you're the other way, if you're doing many-to-one. So let's say you're fetching and you've got five records and you want to write it to one record, gain site's going to write all five of those records to that one record and one of them is going to be stored and you're going to have lost data. I had a customer that I worked with who designed an object to keep their entire CS history for the company in a single object. It grew to over a billion lines and whoever set up the keys and joins didn't know what they were doing.

Had multiple keys and many-to-one writes. And when I went into it, you would have customer level data, email address, historical dates, just peppered through it and they're like, "It's great, we run a report "and there's data, what are you complaining about?" And I said, "Well, if you look at the 300 fields, "it's nonsense, it's nonsense "and you don't understand what you're looking at "and it's completely useless, not to mention slow." So please, for your own benefit and for the benefit of your users and for anyone that might follow behind you in a technical role, understand joins, understand how they work before you start building these things or building DDs or reports, or excuse me, rules. All right, so key takeaways, learn the basics. Understand relational databases, watch for those data designer pitfalls.

We talked a lot about a couple of, not a lot, but we talked about those. And don't get frustrated with it. This is probably the one biggest lesson for me. I have to solve the problem.

And so I would stare at that join where I had no matches because of the preview problem and I'd be like, "I know this should work "and I'll work the thing for three days. "Go away, come back." Still would not work and I finally found out about this preview feature. If I had just asked, would it save me a ton of time and frustration? So talk to people around you.

They might have experienced things that they can give you some guidance on that. Talk to the admin community. I'll talk about that in a minute. Talk to Gainsight, right?

Don't get frustrated with DDs. Learn from the experience of others and hopefully it'll help you. Building your foundation. I think that was key to what we did here.

Always look at that largest population, your Y and the X of Y. Focus on that numerator and denominator. You can then change your filters to iterate on it and improve it or to add additional KPIs. But do keep all of your original data just for testing purposes and or when your users come to you and say, "Okay, I see the summary number "but how did you get there?" It's easier to go back and see the data would already exist than try to recreate it after the fact.

Involving your users, they understand how they're gonna work with the tool better than you do. Do involve them. We talked about the dashboarding on that. Stay flexible.

Requirements are gonna change. User stories are gonna just emerge from the ether. People and customers come and go. Just make sure that you're being flexible and for us, building a structure or a plan of how you're gonna attack this kind of data structure so it's easier to pivot rather than rebuild.

Last thing I'll give you, top right corner is a QR code to the Global Gainsight Admin's Slack channel. If you have not been there, it's a wonderful resource independent from Gainsight. It was created by Admin's COVID time. And there are literally thousands of members now and probably at least a hundred that just have Slack open all the time waiting to help you.

Selfless individuals, a lot of them in the room here. So if you have questions, if you're stumped, if you wanna know if someone's done something before, it's a great resource, just go post. It's also great for comments and getting to know where the happy hours are when you're at Pulse. But do join that.

All are welcome. You don't have to be an advanced technical person. I told you early on that I was a CSM learning how to be an admin. It was a wonderful resource for me and I couldn't have gotten to where I'm at without that.

So do join that. All right, couple questions I saw come in. (audience applauding) So good. First one, once the KPI dataset was built, how did you roll it out to CSM so it felt useful for coaching and prioritization, not just another performance scorecard?

Let's see. So we actually worked with our enablement group to help with that and we first introduced it to the managers because we knew the managers would be having those conversations with their CSMs. Honestly, we've probably released it too fast and did receive feedback that they got a little bit frustrated but I did mention that one change that we made where it was like, hey, it's not overwhelming them with data. We wanna make sure it was all about the to-do list.

But honestly, their focus was my variable comp changed. I wanted my variable comp. And so they were motivated to work with us so that was actually a good side of it. Yeah.

Any gotchas or mistakes that you could warn us about to avoid? I gave you most of them. I think the too many data designers (laughs) might be a big part of it because you have to schedule them in order and they start tripping over each other at times. So revisiting that, I think also just that historical record.

That was the big one was I can't do this all in data designer and I wanted to but we had to pivot. What was the hardest stakeholder alignment decision you had to make around defining good CSM performance and how did you get everyone to agree? Luckily I didn't have to do that. (laughs) The CS managers came up with those measurements.

I completely disagree with them. I think that they are way too shallow. And so when I put on my CS hat, I'm really more about the, the deliberate intent of good valuable interactions with your customer and I don't think we're there. So I'm constantly talking about how do we improve it?

How do we iterate on this to make sure that it is looking for better evidence? So yeah, that was really up to the CS leaders and not myself, sorry for the cop out answer. (laughs) How did you create some of the best how did you create smart goals from the technical side? Oh my gosh, how do we create smart goals?

We worked with our teams, we have 15 products and so our goals are aligned to products and we worked with those individual teams and CS leaders to define common goals. Those common goals are KPIs for us and if you have a custom goal, we actually leave them at other KPIs and we did that so they've got some flexibility but we were trying to set up goals that could align to our PX data so that we could show target and then how are we measuring success against those targets? So as far as that goes, them being smart, again it was the CS organization that came up with them. I'm just trying to give them the technical feeds so that they can support it.

How did you use AI to further analyze if CSMs were actually doing the work? What AI tools did you use within Gainsight or other tools? Also, what's your favorite Pokemon? Okay, all right, all right.

So we used mainly Claude, we started out with Copilot and did run into a lot of trouble with that. We're using Claude now. We're using Claude now. We're using Claude now and we have started playing around with MCP.

I'm still a little bit hesitant into just releasing that to everyone. Basically what we're doing is just feeding at the data from those objects to ensure that there's evidence on the backend. Timeline entries that support it, seeing if there's PowerPoints in those, making sure that we didn't close a ton of them on a single day, which we see at month end where they'll just go in there and just close a bunch. It's like, okay, let's revisit that with your manager so that you're doing it correctly.

So we're mainly just using it to have a look for signals in the data as to non-compliance with the spirit of the KPI. Favorite Pokemon, all right. So my, what's that? No, all right.

My favorite is my Shundo Garchomp. He's a shiny Hundo Garchomp. So he's got full stats. So he's my favorite one.

He took a while to get up to that level, but anyway, so he's my favorite. Okay, I'll have to look through my kid's binder and find that one so I know what you're referencing. My current buddy though is a Snom. If you haven't seen the Snom, he's just sort of a little fidget thing, but anyway.

A couple more here. Looking back, what would you do differently in the planning phase before building the dataset and data designer? Honestly, I feel like maybe thinking more about the fact that there would be changes to the data over a calendar year. I talked a little bit about that with the historical record.

We honestly did not realize that when we changed to another quarter that it would have lost that record and we had to go back and redevelop it along the way. So I think that was the big one. I don't think if there was anything else. I think the fact that we settled on the terminology, the maximum population and the X of Y, I felt really good about that structure.

So, and we were able to be flexible and pivot, like I said. So, don't feel too bad about it. What is your process for determining when to use a data designer or to use a rule and write to a standard or custom object? It really doesn't, there is no difference at this point.

It was just we were built, we had a data designer we were already using and so we used that to write over. I would prefer the rule, it's just more efficient and I can schedule it in a rule chain. So I would go rule if I was to rebuild it, but we had already been down the DD path. How do you typically handle data discrepancies when designing new data sets and data designer?

Wow. How do we typically handle? I mean, I won't say our data is clean, but it's just, I don't think we question the data all that much. Maybe I'm not understanding the question real well, but how do you typically handle data discrepancies?

I would feel like a data discrepancy is probably the only time I would surface currently is if I made a mistake, right? So in the build itself and that I would see during the troubleshooting process. But maybe I'm not understanding the question. This person wants more technical sessions.

Yay! Yes. How do you support goals for your long tail at Dell Tech? Do you have customers that don't get annual reviews but you still want to track performance and goal progress?

Great question. We do capture goals via surveys. So we have a mostly digitized long tail. And so when they go through the onboarding process, they'll get a survey that says, hey, here's some common goals for the product that you purchased, how many of those apply to you, open-ended as well so we can get some more detail on that.

And we have that right to the goals object so that it's actually referenceable on their account and gain site. They do not get annual business reviews. We are looking at some automation about how we can generate just basically an email review that would be, here's the value proposition you're getting with our product before you go into your renewal cycle. So we are trying to do that now.

We're not quite there. The big one, the big gap for us on that is our PX data to show that they're achieving that value or what the next value prop is. Do you document these complex data designs anywhere for your team to reference or even for your future self to understand the reasoning behind the decisions? If so, what's been the most effective approach?

Spreadsheets, unfortunately. We do most of it just in the tool and it's ad hoc. We do write and share between, I've got two admins that report to me and I cannot give up the technical work so we're all working at it all the time. So we do kind of talk about it and that sort of thing.

I have started using Claude to log a lot of the information about what we're building and things like this. Haven't really seen much benefit of it yet but I think we're feeding it, right? The eating will come later. How have you handled needing to edit components of a design that have steps before or after?

In their experience, the after steps need to be deleted and requires rebuilding. Is that still the case? Yeah, unfortunately that is. Basically, you're just gonna have to leave them and move them up, move it up to a higher level and do it.

If I'm facing that, I reevaluate the structure that I built to make sure that it's the most efficient. So I'm not just going to back it up, add another one and then bring it back down. I'm gonna reevaluate how I built it completely and just say, this is still the best way to do it before I make that change. I also do silly things like fetch relationship at the front with a GSID, bring it all the way down to the bottom and then fetch relationship again and bring in the data you're looking for that last object.

So you can augment data doing that. Okay, I think that is all we have time for. So before we close out the session, just a reminder to everybody that you can give feedback to this session by going to this session in the agenda and clicking at the survey on the bottom. Wayne, thank you so much.

Very informative, wonderful session. Round of applause for Wayne. Thank you very much.