Slate Spotlight on Class Years Dataset

Hello, Hello, everybody.

Welcome on this wonderful Wednesday morning, May 10th.

How's everybody doing today?

As we're getting started today, feel free to say hello in the chat that we have here. Let us know where you're dialing in from. Maybe with the weather is like today, what's you're most excited in the coming weeks. I would argue that the answer to that should be the Slate Summit, which is coming up in exactly 22 days. So hopefully we'll see you all in Nashville. Ashley, good morning. It's finally sunny in Michigan. That is great to hear some New York folks coming in as well. Totally good to have you here as well, man, this is great.

A number of people dialing in the call. We're just going to give it a minute or so as people are logging in today, getting their computers up and running on this Wednesday morning. This is great. Good things in Iowa. Transy. Justin, great to have you here. Amazing, amazing, amazing Queens. We have Phil logging in today. Ohh, Lauren for Lauren. It's kind of early out there in Oregon, isn't it? Yes, I think you got into this thing right.

Apparently that's great.

Awesome.

Perfect. Perfect. Perfect. Yeah. Dev 73, I think it's about the same here in New Haven. The sun is out. It is just a wonderful day. This is great.

All right, everybody. It looks like we may be having a decent number of folks who have registered in advanced signed up for today's conversation. So we'll go ahead and we'll dive right on in. Today's spotlight is going to be on class years. We're really going to be talking about class years as sort of a framework or model to start to think about how you think about hosting information, collecting, contextualizing data inside your database and start to use it in a bunch of different places.

So just a couple of housekeeping things as we get going here. 1 the webinar is going to be recorded. So we are recording this. You can view it afterwards, we'll send out the links. That way you can access this recording. We're also going to make this available on our website too, so it can be shared with other people. You can come back to it. You can watch over and over and over again and always relive May 10th, 2023 in your future lives. close captioning is available too. So if you need that, there is a little CC button on the top right corner of this window. Go ahead and click that.

If you need to view this full screen, there's also an expand button that's up there. Go ahead and click that if you want to see a bigger version of me or a bigger version of these slides. If there are any audio or visual problems that are happening, just go ahead, give your browser a refresh. It should resync anything back up. And the last one here is just to go ahead and put questions in the chat. So as we're moving along, we'll we'll start with sort of a brief overview, some context. We'll look at sort of how we're looking at class years inside of sleep.

Keep those questions rolling in the chat. My colleagues Genevieve and Carlos are keeping track of them diligently sort of on this little sheet that that we have sort of on the back end.

So that way we can get to your questions at the end. I don't imagine this to be a particularly long presentation for today, more of sort of the introduction of again this framework for how to think about these data relations, some examples that we have up, but they're really getting to your questions and talking about expanded use cases of this. So that's the preamble. That's the overview. We'll go ahead. I'll start sharing my screen as we get started for today. Hopefully you can all now see that and we'll get things going so.

Last years, this is continuing this train of thought that if you've joined several of these other spotlights in the last couple of weeks, we're continuing to build off this concept of sort of repositories of data or containers of information. Previously we've talked about things like performance management existing as its own data set to house information about your users, your employees, tracking goals, those types of things. We've talked more recently on namespaces where those also exist as a container, as a data set.

Themselves that houses information about that particular object. O when we're thinking about something like Clash Years introducing this concept of storing class years as a data set, what that's going to allow us to do is to start to store more and more information on a single place in a single repository, and then simply connect to that record to your various other records in the system. The nature of that connection means that you're able to store information in a single.

Location and then pull it when it's needed. So what can this look like? What benefits does it offer? Let's go and look at an example one and we'll talk all along the way.

So we'll first go to our lookup area. We'll see a bunch of different datasets over here. We'll click first into our class. Here's one. We just have two for our example today, class of 1982 and 1983. One thing I'll point out here as we're looking at this is this concept of the keep, right? So as you know, you're all familiar with datasets and how they work, very good practice to have a key associated with the data set. In this case, we're keeping it just as the simple year of the class itself that again gets that data.

Point on that record, it becomes a very usable type of thing. We could start to do math with that key to do calculations, know if it's in a reunion year or not, but just also a good data hygiene right, something that's going to be consistent. There's that one to one relationship between the class year and the year itself. So let's go ahead and click into this class of 1982.

Right here you're seeing sort of, sort of one of the main features of putting this information into a data set and that's you're able to aggregate statistical information about people within the class. So once you have the connection, you can start driving people to the individual records without the need to necessarily go and create separate reports for different class years, separate queries, running a whole bunch of things in a different areas. Bringing that information, Elevating that information into a dashboard makes it very easy for folks just to see how many total.

Living alumni are there? How many deceased alumni are there? What is the current fiscal year giving from this class? From how many individual people? What's our pledges look like? What's our our total for this class actually looks like?

But you're able to see that information really out of clearance just by looking right at the dashboard. The query for this is very straightforward. We're simply looking from this data set, record this class to all the people that are connected to it. Now how do we make this connection right? This is again something that we were starting to see more and more consistently between your people records, for example, and other data set records that exist. So we'll go take a look at our friend Alexander Hamilton, who we frequently look at for these types of demos and models.

But if we go to their details tab, we have a custom field that we made that says class year. This is a special type of field. This is a related data set row field. And what it does is it provides a link between Alexander Hamilton record and this particular class of 1982 data set record. You may be thinking, Oh well what about the schools, the schools record that we have inside of slate or what about the differences? If somebody is, you know they have sort of their.

What's on their transcript last year, but then they have an associated or preferred or an affiliated type of class year. You can make multiple leagues fields. So we just have one here and we call it class year. It's tied to that particular data set. This might be called something like official class year. You might have another related data set really feel that you make that is there affiliated class year. So that way you're storing all the information in the right places. You have sort of the contextual information about what's affiliated versus what's formal but it ultimately.

Still does the same thing where it links that person to the central repository that we're calling their class Year.

How can this be set right? We'll see that we made the decision in this environment to have it as its own custom field, but I feel like at the school's record over here, State University is our example record, you know?

We like to think about storing information in the right place, so storing information about their major, about the school, about all those things on the individual record. And then what you're able to do is automate a process that can set that relational field. So imagine that you bring in information about when someones graduating, you're storing their dates that's conferred or expected. You might then have a like an export, import process or some other means to just then automatically set this relational field that then provides that linking. So it's then.

Right, available right from the person record. You don't need some of this extra joints to go through school and then ultimately up to those other areas. So this is what we're doing here in terms of the actual connection between a person's record and the data set. So imagine now that this value is set on all of the different constituents for a particular class year. If we jump back over to this class of 1982 record, we can now start to very quickly on maybe a tab start to have queries that show things like.

Who are those alums that are in this particular class year? This is simply just referencing that field that's on that record and says, you know, who are all the people attached to this very specific class year. So that way you can start to say, well, how are people in a particular class operating? What's they're giving, What's their account, What are their interests that they have when they were a student on campus? Who is our most engaged people from a class? Maybe those are the people that we think about reaching out to, to be a part of any of our committees.

Uh, which brings up another sort of good point about why we're thinking that a data set record might be the best place to store some of this type of information, because you get a lot of things with data set records kind of for free. In addition to the container itself, you get the ability to have dashboards, to have sort of profile information, to have timelines, materials, but also its own set of custom fields and entities and its own set of related data set row fields. So.

That way you're able to know at the class level. Is it in a reunion here, Maybe that's something that's set via a rule or maybe you had know who the class officers are and you're able to click on them and link them right out to those particular records. Or you're having a class reunion committee and you're keeping a history of that iteratively, where you're saying, OK, I'm adding a new committee member, it's for this particular year, here's our role, here's our status. And this ultimately then connects back out to that person record. So it goes a little bit to what?

We talked about on the namespaces conversation, which is where and how are somebody managing this information.

And this type of case, it makes sense to store this on a a particular record because you canmore easily manage it centrally for a particular class to then know who the reunion committee is that I see your question in the chat about class agents. That's another great example of having right here either as their own standalone custom fields or as an entity. If you're doing something like that where you're keeping track of are they active agents, are they inactive agents. But what we're doing is we're making that linkage between the.

Last year the person and then maybe ultimately other people that are related to that person, right? We're having this sort of string of connections using these related data set row fields.

So here we're looking at custom fields, entities and those types of things. You know, this is really that framework that's starting point. Class agents, a great example of additional things you can add here. If there are very specific things about reunion pricing, things that are specific to a class that you don't necessarily want to store on every single individual record, this data set approach aggregates that information. You know, I was talking with Genevieve or my colleague.

Leave earlier today talking even something like the timeline, right? Imagine a scenario where you're able to make interactions that are for a specific class, right? So you're applying something to the class overall, not necessarily needing to find all the individual records. Or maybe you add interactions and it becomes kind of like an alert system. Where in this sort of framework, imagine that you have a portal that is taking in sort of the IDs for each of your different classes, where you can then now display information that you add either as a custom.

Field or his interactions on that record and then bring them into a portal. So your ability to have micro sites that are very class specific increases with this type of architecture, this type of environment that we're looking at.

Connecting and kind of full circle back to our performance management conversation, again using this concept of related related data set row entities, related custom fields, but maybe we're looking at this from the Alumni engagement officer side of things where we can know right from the class year who's assigned to manage a particular class. So in this case Oliver Walcott, what we're doing is this is actually a merge field, but this is being managed on that performance management data set record where you're able to.

OK, let's check out their role details. Similar concept that we're seeing last years that we're seeing named spaces, the city of custom fields, custom entities that provides this linkage between and among your various records. So in this case, he's managing the custom 1980, two 1983. You can continue to iterate on those with start and end date. So someone leaves and comes over, you have that full history of who is actually related to that particular class. So you have this full archive of information that's there.

I'll jump back over now to the class of 1983, which if we're doing the math here, that's going to tell us that they are in a reunion here, right. So now you can start to elevate key pieces of information like they're there for you near automatically using these dashboards almost as notifications or doing that math, so you don't have to sit there and think, OK, 2023, -, 10, right. It's just going to be easier, let the system do that type of thing to do these calculations that are up here.

I think that is most of the concerns, the conceptual things that we wanted to convey, right? This idea that what we're really talking about here from a big picture perspective is a framework. It is a container where we are storing information and we are linking people to that central repository. The nature of doing that allows us to have very quick, very easy reporting. It allows us to elevate things to the right people. You know, these class years, they can be permissioned too, right? So you can have this be.

As an authenticated type of thing where you know only maybe Illuminate Engagement officer can access this administratively or maybe the Alexander Hamilton record, they can log in and there's a restriction on their portal that says only for this particular class year. So they log in, they see the right class year. So a lot of really cool things that come along with datasets, I think we'll see as time goes on is and as you all start to build out these things in your own environments as more and more really interesting and cool youth cases.

To to manage something like a cloud shear, to help with your reunions, to help with sort of knowing information about your individual records and your individual classes. So with that, I think I'm going to turn over and look at some of the questions that maybe have come in during our time.

Uh, to to to talla. Looks like a question coming in from EU which reclass agents? The same we use their preferred class year. We wouldn't allow someone to be a class agent for a class that isn't the same as a preferred class. Yeah yeah great point. So a lot of this stuff too comes down to process, right? It's how do you want to to manage your own data, right? Do you want to have multiple related data set row fields, one for preferred, one for actual? Same thing on the entity side when you're making those different class.

Years, right? What are who are we actually gonna allowing to be an agent or sign up to be an agent that then creates that entity record on this particular class while this stuff goes down to process?

Uh, Phil, a question from you. Queens is moving to a projected Class A year and a preferred class year. Protected class year is for the student records and the preferred class year is only assigned one. The degree is confirmed and it's conferred by the registrars office. Yeah, so similar concept here when we're looking at something like Alexander Hamilton, you may, you know, while the time there are student, right, they're still working through things and you want to make sure that you know there's a difference between what's the official official class year. You might simply just have another field that is that sort of.

Affiliated classier than projected class year where you're taking information from the school's record and you're saying ohh the expected date is, you know, sometime way into the future. Well, we can still make that connection to that class year. It can be there And ultimately these things will start to align as you eventually get that information from the registrar's office. And in your particular case that you're describing ultimately that official official class year and then affiliated class year, that preferred class year will ultimately be a lot to ultimately be the same thing.

As you're ultimately adjusting the school's record on that particular person and yes I realize I said ultimately like 7 times in that one sentence, so apologies for the the syntactical mistakes there, but it is a need to way to sort of look at these connections.

Barbara, if someone skipped is anonymous, will their name be hidden in a gift list? Yeah. So when we think about pulling lists of gifts, anonymous is a flag that is directly on the gift table. So you know, if you're on a particular record and you want to show, sort of, you know, maybe exclude anonymous gifts from these calculations. Very easy to do, just simply apply a filter and filter out those anonymous gifts.

Phil, is there one request to change their preferred class year? Usually a December grad will be changing the one class year field, change all related fields in the class year data set? No. So what we're thinking about here is more on the personal side of things than on the class year data set side of things. Think about the class year as the data set as sort of that overarching container and then thinking about sort of the individual things that are happening on a person's record, whether a December graduation and May graduation, how they want their preferred.

One versus official one. That's where those values are actually being set to make that connection. And so that would be something that you're changing on that individual person's record as opposed to something on the class year record itself.

Good questions Scott. Questioning coming in from you. Can I ask do you go down to some basic components? For example, you create a data set and now show the fields associated with the data set. How are the fields being populated? Zoom. The data is in slate for a person, but you're aggregating data using a process to populate these fields in the data set. I pretty new so things about how these things are all connected. Yeah it's a great question right? So let's take even a bigger step back if you're not familiar with datasets incredibly powerful tool requires.

A little bit of.

Of thinking about how all the pieces do connect. So when you're making a data set, the very first step that you're actually doing is coming in here and you're going to the data set section of Slate and you're simply giving it a name. You can choose an icon, but you essentially create that data set that allows for that data set record, data set records to be created over here. I imagine that for the majority of these things, for class year, data set records, these are something that you likely.

You're already aware of, or if you're, you're you're. Your campus isn't. Doesn't have these containers with these additional fields. It's something that you will likely be able to very quickly import. You can import directly to this data set. It can create those data set records. Even if it's something as simple as starting with you know the name, you know the class of 2000 and the key the just 2000. That establishes the record, and then from there you're able to.

Very much like all of your Person records, all of your Company records, all your Fund records, you're able to say I want to make a new field and I want it to be associated with that class year data set. That allows you to create the additional destinations that you need to be able to say, is it in a reunion here, Is there a particular motto or a a class photo? Or is there any of these other things that are associated with the class? You're able to make those custom fields. Then you're also able to make those custom fields that are linkages.

Using these related data set row fields that are here so you're able to connect between Person and the class year data set.

So those create the actual destinations. What we're seeing when we look at that individual record is we're just simply showing those values on this tab. And so there's great documentation out there that describes how to make custom tabs using our forms tool, where you're then able to edit and then make changes to these pieces of information. If you already have this information, you can simply do an import and then we'll populate those fields that you made and everything should ultimately connect up.

A question coming from Ron and and Scott, let me know if you have follow up questions on that. That's a very high level, very quick overview of things. Ron, your question coming in, you know this will ultimately come down to how Clarkson wants to do it. But what is the thought process for undergrad and graduate schools, some grads with both degrees, different years. I think we talked about historically setting up a ground version of the class years and undergrad versions. But bring it up now while this is fresh and light. Yeah, it's.

It's, it's an interesting question, right? Particularly when you're thinking about, oh, I have somebody who has multiple degrees from my institution in the same environment. That might actually be a good case for not having something like a single field that we have here that is the related class year. But where you might have something that's an entity that it is very much. Oh, and this reminds me about sort of our class or another class years, our namespaces entity, right, where there's a.

One to many relationship between Alexander Hamilton and these two named spaces. Similar concept. You might have an entity that is my class year's entity and each row is the particular degree that a person has received. So instead of donation level you might have something like you know degree level and it's grad or undergrad or it's it's degree and major right. You're keeping some of these things.

Separated out so that way you know very specifically on a row by row basis which class year it is for that particular thing. So the same concept, you're just taking that related days at Rockfield that we have here at the person level and you're moving that into an entity to account for that one to many relationship.

Yeah, same thing for parent readers too, right, Tracking the the, the years that the parent is associated, same sort of concept. All we're talking about here is really just creating that linkage, that relationship between the person records and that class year data container. Phil. Well, an example of this data set be in clean slate, yes, the the environment that we were in right now is what you see is what you get is what is there. So you can provision your clean slate from the advancement.

Showcase environment and you will be able to see this both on Alexander Hamilton as well as our two example class years.

Scott, follow-up, you're showing off give totals pledges for class year. They're calculated dynamically on the fly.

Yep, so this is calculated data that we're actually showing here. So if you are, if we look at what it's actually populating this particular dashboard query, go to our queries tool. I'm going to search for class years.

To do a lot Classier dashboard is the one that we want. So we'll see that it's the base for our class years and when we edit the query what we're doing is we're doing those calculations here. So when we're looking at total alums, it's going to be a very simple we're doing the join. Slate will automatically make these joints for you once that related data set we'll field is set up, but we're joining from this class years based out to all of the people that are associated via that related data set right field and we're doing account.

Same sort of thing for things like deceased, except we're adding a filter to say that that person is deceased. Similarly, if they're living, we're saying this, they are living. But then when we do things like gifts and count distincts for gifts, what we're doing here is we're joining to the person from that person to all of their gifts and then adding in whatever filters that we want. In this case, you know it's received, it's hard credit only and it's in this current fiscal year, so it is calculated right when you go and hit the record it is.

A relatively fast calculation that's actually occurring because it's only when you do that join, it's only looking at those people that are associated with that class year. It's not having to go and look across all 100,200 thousand, however many records are in your database. But we're starting from the last year. So then we can just simply make that connection over and we can calculate these things very, very quickly.

Great. Justin, question coming in from you never done this, but could you also place the custom row field scope to schools and based on school level study with class year being to allow it to person. Yeah, you're basically asking can we have done this linkage actually at the school level itself. So maybe a custom field here that would link out to the data set, right? That's that's the gist of your question I think if it is.

The answer is yes, you you could go that route too, right. So you can have it at the individual school level as well. It's it just adds another layer of complexity. So depending on sort of what your data architecture looks like with your schools and sort of your number of multiple degrees and all that type of thing, you can absolutely have that here. And then you would just add another join that would be needed. So you go from the school or sorry from the class year back through to the school record from the school.

Record back to the person record from the person record to their gifts. So it just adds in another layer. One of the things I like about pulling it up at this high level is it's more elevated. You're able to see this more. And the concept here is that it's something that is more donor centered when it's at the person level than maybe at the school, right. If somebody, you know, they went to undergrad and maybe that's where they had the time of their lives, but then they stayed for the other year or two years to get their masters degree. But you know, that's not really how they affiliate.

Through university, having this thing at that personal level makes that decision for you and for them. Or you know that they like to be communicated with in context of their grad year, because maybe this is what you're calling their preferred, and that might be different for one person than the other. The benefit about it being a preferred one is that it is a choice and people are able to select which ones they actually want, and then you have that connection elevated right on the person level. But from a technical perspective, you absolutely could have it on the.

School. Just know that you'll need to do a couple more joins and then you may also want to just elevate that data piece so it's not as buried down through the profile to the schools and then seeing that information here.

Awesome. These are great questions. I love these questions.

Are there any other things that people are thinking about? Hopefully what this conversation is doing is it's getting some wheels turning about how to think about sort of the relationship between folks and objects or containers of information.

Great. Yep. Brian would be hard to control when someone wants to array at the school's level 2. Yep schools just it adds a layer of complexity. From a pure data perspective I like it. But from a more sort of 100 centered or sort of your users experience approach, I'd like to get the person level.

To Ohh, Harry Grade thanks for that. Yeah, Gaucher and new to Slate for advancement here in the conversation stage. Looking forward to connecting. Yeah great. And Harry also I'll chime out. You know come to any of our community conversations that we have posted in the forums. We'd love to welcome you with open arms.

Yeah, right. Get on the forums ASAP. Uh, Scott, this won't be related to class your data set, but time permits. How are you using the various salutation overrides? And saw them in showcase. Yeah so a quick detour from our class years conversation. But what you're referencing Scott is something like this where we're using our rules engine or automations to actually do the calculations for things like formal citations and formal class years. These type of things, these are calculated fields that.

We have here because these are being calculated in the rules. What we're doing is we're allowing override. So if Alexander Hamilton doesn't want to have their formal salutation be written out in this way, you can set a formal salutation override if this value is set. What that allows us to do is in our rules and if you take a look at this, you'll notice that they're set up in exclusivity groups. This means that you know, it's just, you know for this particular Formula One we're saying if that override.

That don't do anything. Don't create any sort of custom namings for that next field, just don't do anything. So it's a way to say don't alley this calculation that we're doing for this salutation if that override field is set.

Catherine, I don't develop queries, but let's say you set up one of these containers for the class of 1982. Great, we have an example of that one. Excellent. Can you simply duplicate the query and change the class year? Yeah. So these queries that we have, they're dynamic. So they're actually, you can make them one time. And if I go to the class of 1983, it's that same query behind the scenes that is driving these data points that are being returned as the same query that is driving.

Who are the alums in this particular class? What these queries are is they're they're parameterized. I think that's a worried. If not, we'll make it up. But there's a parameter set on these queries that says.

Only return information for the record that we're on, O. In this case, the query knows that we're on the class of 1982, so it's only going to show us the information for the class of 1982. This allows you to be incredibly efficient in not how to make your queries and reports for every single class year, but by elevating that information to the dashboards to these embedded queries on the record itself. You're making these things one time and having that information be available. It's a great question.

We try to simplify it here by just making it elevating the data so that way you can see it, your users can see, your staff can see it. And it also makes it easy to share this information to maybe that class year in something like a portal because again, you can have those parameterized. I'm going to say it again, Jason queries right where you simply pass in the ID for the class year and all the underlying information is updated accordingly.

Awesome. Loving all of these questions. It's hollow. Would you show again how you make additional tabs on each class page? Sure. So clubs, we have something like our class details one and then we have something like our alums in class form. So if you wanted an additional tab, maybe you wanted to, I don't know have all the class agent stuff on maybe a different tab just to keep things simple. Or you wanted to permission things out in a certain way the way that our tabs.

Custom tabs work inside of Slate is a combination of two things. One is a form where we're able to sort of add the fields that we want here, and the 2nd is the tabs tool which essentially gives it the name and connects it to a particular data set. So if we wanted to have another example, I'll just walk through because it's a relatively straightforward example. In our form section we can say we want to add a new form and I'm going to call this my class years Agent tab, right, so we can put it in the folder I like to keep things.

Somewhat organized in clean slate, so we have a custom tabs folder where it will live. I always put things as active. It doesn't ultimately really matter for a form for a custom tab, but then we save it. The very next thing I do when we're making these forms is we need to change the scope. Right now forms are defaulted to Person scope, but we're going to edit our form. I'm going to remove all the different fields that are there by default, and then I'm going to click edit properties and change the scope of that form. So I'm going to choose.

One of our page construction scopes. So I data set page and then I'm going to choose the data set. So I'm choosing my class here as data set right here.

Now that I do that, I'm going to bring over maybe just some instructions. I'm going to say hello just so we have something that's there. But now if we go back to the form overall, you'll notice that that list of registrations is gone away because we're telling slight we intended to use this particular form as a construction mechanism to display information back to folks while they're on that record. So the next step are Part 2 is going to the database tool going to our tabs.

Direction. So we've got tabs and then we're inserting a new tab. And I'm saying this is my. I'm going to call out my class.

Agents details, if that's what we're pretending for. In this case, choose data set as my scope class years and then you'll be able to see what are those forms that are scoped to that same data set that I just selected and are also that data set page scoped form. So we'll see that sort of this agent one that I just made. You can give it an order. It will change sort of the left to right nature of what tabs are showing up and what order, but then we can go ahead and click save if I come back over to my.

Tab here give us a little refresh. We now see Class Agent details with my Hello showing up as another tab on this record.

Good question.

Other questions, things that people are curious about. Like I said, I don't think today is necessarily an entirely super long conversation. I I think we mostly wanted to communicate this concept, some of the the key key pieces of connection and then let you guys kind of sit on it, think about it, ideate, brainstorm, all those types of things and then hear back from you in the forums and the community conversations and that summit in 22.

Days, 23 hours and 25 minutes.

Any final thoughts? Questions. Debbie, Would you ever use anything under the Profile tab for this data set and maybe put the class agent under the name there? Yeah, so you're. I absolutely see use cases for using this profile tab for different pieces of information. One is the relationships you might choose to use the standard relationships functionality and Slate and a Leo of anything like an entity with related data set row fields.

Uh, so this might be an appropriate place where you're put. Class officers may be here. Then instead of the custom fields that we have, this could be where you put things like agent names if there's only a handful of them. I like entities as it starts to get longer, doesn't muddy up your relationships table, but things like contacts and addresses, you know if there's a class year reunion e-mail, or if there's a mailing address for a class year or a post office box or something that they are actually receiving mail, you can absolutely start to use the the standard.

Things that are associated with datasets for this class year's project that you might have.

Excellent. Now, Brianna, I not keeping track of anything that we know there's a ahead of Summit. There is a a countdown clock right when you come into our office in New Haven it's down to the millisecond. So I always knew exactly where we are in relation to being in Nashville at the opening session.

Julie and in terms of alumni participation, would it make sense to make a data set record like all classes together, percentages for all classes in one place for leadership and the alumni engagement stuff? Interesting question. I think this also goes a little bit to how you think about calculating alumni participation overall. I don't know that a data set for all classes makes sense in terms of.

Needing the data set to get that information, I agree with you 100%, it's important information to have.

I think that when we're thinking about that type of number, what that that APR percentage rate actually is, it's a, it's almost like a single calculated value. And so I don't know that necessarily warrants a whole data set. It might make more sense in something like that performance management framework that we talked about previously and I alluded to earlier in our conversation where you might have a portal that does some of those aggregations for you and your leadership team or for the.

And engagement staff where it's at a very high level, you're logging in and you're seeing something like the summary KPIs for alumni engagement, how many donors do we have revenue per dollars over all alumni participation rate. This is a a very straightforward query that you can then look across all of your records that are marked as a lab. So it's a I think you might find more utility in that approach than sort of the data set approach for it.

Questioning from Tess, I have a dream very much not for right now to make a whole housing data set for our reunion housing which would incorporate somehow into our class year data set. Each reunion has very specific dorm or quad that they stay in. Each reunion as imagining a tab with an entity showing who is staying there, maybe even showing what rooms are still there, maybe with floor plans. Yes, so the you can absolutely start to get into layers and layers of complexity with these types of things.

As we think about how to store structure this information entities, I always like the entity approach for different things where you have information about sort of what are the maybe it's an entity here that is what are the housing options available, right. You only can have so many spaces really if you want to see that information. One thing we haven't yet talked about in sort of this series, this evolution of conversations we have that ultimately has been focused on data sets is the concept of a child data set.

And so it might be that for, you know, you may not want to have sort of an overarching housing type of thing, but if they really truly are associated with each individual class and options associated with that, you might have a child data set relationship between one of your primary datasets. So that way it exists in context of the class years. That is a really cool thing because then.

If it exists as its own data set, it's like kind of mentioned at the start of this. Data sets give you a lot of really cool stuff for free. You can have custom fields on each of those housing locations. You can upload materials for, you know, the floor plan for the room, maybe each sort of, if it's you know, a dorm that has 10 different floors, you have 10 different materials on that particular dorm room, each with the sort of the planning gram or the map for that particular floor. Then when you know where somebody is staying, you can reference the appropriate floor. So a lot of really cool.

Things that you can do there. I like the idea of sort of continuing the rabbit hole of these types of things, but the one thing I would caution folks that are on the call about here is getting too far down the rabbit hole. I think there's a there's a healthy balance between.

What makes sense just to store as a basic field, store as a basic entity versus going down layers and layers within data sets or related data set rows to each other. I always tend to think that simple is sometimes better in these cases, but this the based on what you've outlined here, I kind of like the approach for a child data set record that can then host all that information.

Just never going to rabbit hole. No, I agree with you. I I've never seen you dive down deep in those rabbit holes. Laurie, can you explain the purpose of the key on a data set? Not specifically for this year. Yeah. So if you want to be a random number, incremental value, you can make rules that set keys. Keys are primarily used as a matching criteria as one of its main purposes for your datasets. So it's easy for something like this for something like ohh I'd.

No, um.

Something like our namespaces, one, right? We're giving it sort of these keys. So you could either define these things upon entry, but you can also make rules that automate the creation of these. They can be random numbers they can follow, they can be something that's mapped over, maybe that that thing, that object exists in another system may be upon import you just set the key to something that's familiar from any of your other systems on campus, or simply create your own upon entry, but primarily using from a matching.

Perspective to that particular data set record, we will make an identity for each data set record. So it will generate a number on that top right corner if a key doesn't exist. But it doesn't have as many qualities when it comes to matching.

Uh, did you do Justin, have you thought about using a custom entity on a person? That would be to set a record for FY23 alumni given percentage on the class your data set. If the person meets the criteria for being eligible for that fiscal year, they would we would set a row. We have a single record to see the current fiscal year, alumni giving processes, stores, static numbers for the year, etcetera. I'm not entirely sure I'm following Justin, what you're looking to do.

The customer and the other person record.

Yeah, Data rabbit hole, data rabbit hole indeed. I, you know I tend to think about, I think what you're asking about is can we store the alumni percentage on that person's record in addition to on the data set record. Is that what you're you're driving to here?

Uh.

Maybe if you could provide a little bit more context in the chat, we'll jump back to this one question from Debbie. Is this being recorded? Yes, we are indeed recording this conversation, so from attending you will receive the link shortly after this concludes.

And to Yep Sarah, you can also say ruled set the key with a random ID. Create all good.

Yeah. Justin, I'd be curious maybe maybe bringing that question to one of our community conversations. That way we can have you on also talking and we can sort of map it out or sort of explore what you're looking for there.

Other thoughts, questions, points of inspiration, things. Now you're thinking about various ways to use these types of things.

Awesome.

Well, great. Well, thank you everybody for joining in the conversation today. I think this is an excellent conversation. I love the questions that came into the chat. Let's continue it. Let's continue the conversation and our community conversations that happened twice every single week talking to not only technician staff, but other folks that are on here. So that way we can continue to all grow and be creative as a community. So with that, we'll say goodbye for now. We'll see you all.

In 2222 days and 23 hours and 15 minutes maybe.

In Nashville for the sleet summit. So until then, we will see you very soon. Take care everybody. Bye.