Slate Spotlight on Optimizing Data Configurations with Custom Datasets and Entities with RHB

Difference between 2 Steves?

I just. I just want your unconditional love and support, Steve.

Is that?

I wanna I wanna start typing in ChatGPT questions here, you know.

All right, 11:00 o'clock. Let him in.

Steve, instead of I'm going to stop myself down, so OK.

I don't know if we're broadcasting or not yet. It's hard to tell.

I think we are.

All right.

Awesome, someone said. We are.

Let's give everyone a second to trickle in, then it looks like the numbers are.

Continuing to rise, we'll give you guys second or so and we will.

Good question. If you're not Steve or Steven, can you type in the chat? I think you can. I think that we don't have the Steve moderation filter on. So I think that you are allowed, but it's a great question.

All right.

All right.

I think we can go ahead and get started in the interest of time since we only have an hour here. But a good morning slash good afternoon everyone and welcome to our session. Brian, go ahead and take it away.

Yeah, that sounds great. Good day to everyone. Thank you for coming to optimizing data configurations with data sets and entities as you're doing. Feel free to continue putting in chats, questions, things of that nature throughout there. We'll have Steven collecting and aggregating a lot of those questions. But just to introduce myself, my name is Brian Cho, served as a Senior Technology Consultant with RHB. I joined the firm about last fall, but before that I was with technology.

It's for roughly about four years, and prior to that was in the same shoes as you, all working in a mission at a small, private liberal arts college.

Yeah. And I'm Megan Miller. I am also a Senior Technology Consultant with RHB. Next year I will be have been at RHB for four years. So I've been here a little while prior to that, much like Brian and similar to how many of you are currently, I spent quite a bit of time at a university working as a slate administrator there. At this point, I have worked in more than 100 slate databases. So I have seen quite a bit.

And I see some familiar names in the chat as well of some some clients that we have worked with previously. Before we get started, Brian, I do want to mention your sound might need to be adjusted a little bit. It was a little bit echoey. So just as a heads up, but having said that, let's go ahead and talk about what RHB is.

Hold on, I've gotta get my slides working. OK, there we go. So RHB is a consultancy. We have been in higher education since 1991, so we've been here a while.

Are these slides showing? It's showing us like loading for me and it's not really cooperating. It's where is it showing this next slide? OK, great, Fantastic. We have been in higher education for since 1991 and we have worked with more than 300 schools across the country and around the world. Our mission statement is to inspire colleges and universities to greater relevance. So if you're not familiar with RHB, we have had the privilege of working with a lot of different schools. So focus on a whole lot of different things.

Everything from securing desirable market position to empowering schools to build affinity for their institutions. Every step of the student life cycle. To help strengthen the university as a whole, we offer for practices at RHB. Those are Enrollment Management, which is headed by our friend Ken Anselmo Ant Executive Council, which is working with institutions of presidents and boards specifically around items like planning.

For strategic planning and things like this.

Institutional marketing marketing, which is helping establish schools in their market position as well as their marketing strategies and then slate and related technology, which allows us to work with a lot of different schools. That's why we're here today.

Brian, I will turn it over to you.

I'm having a lot of trouble with these slides, so I apologize.

And you are muted also.

Well, while we wait for Brian real quickly, let's go ahead and talk about what we will actually discuss today. We have several different topics we're going to discuss. We're here to talk about custom datasets and entities, right. So we'll start by talking about custom datasets. What are they? What's the definition? What are a few basic use cases? From there, we'll move into entities. Same idea, what are the definitions? What do we need to know about datasets without entities themselves?

We'll talk about how to use those together so that they're not just two separate things living out in the slate universe, but that we can use them together. And we'll also talk about some of the things that we need to think about as you start utilizing these, as you start expanding your use of datasets and entities. So those caveats, some considerations, lessons learned from the process.

And then talk about also some comment mishaps that we've seen and then wrap with question and answer. So Brian is going to go ahead and start that conversation for us with custom datasets.

But Brian is, Brian, you're not broadcasting right now.

Well.

There you are. You're still not making any noise though.

OK. Well, I'll just start by talking about the definition of custom datasets. At some point, Brian will jump in and be able to join me. But let's go ahead and start by talking about custom datasets, what they are, how those are used. Custom datasets are designed to allow us to configure independent records that can tie to other types of records and allow us to meet unique business and reporting needs. These exist as independent records within the system.

And then we are able to create customization from there to define information about those custom records. If you are familiar with custom you're. If you're not familiar with custom datasets, you are familiar with datasets in because of your work in Slate. Datasets that exist in slate off the bat would be the person record, organizations, organization, contacts and there's Brian, I think I can hear you now.

Can I?

I don't know. Can you hear me?

OK, we have success. Great.

So.

Awesome. Awesome. Awesome. Awesome.

I thank you, Lindsay Waldron. Maybe if Ryan becomes Steve, I do just need to become Steve. I'm sorry about that, folks. Sorry, Megan. And were you covering over all the basics of it all?

You're getting into what custom data sets were and how. Even if you don't use custom datasets yet, you have used datasets for sure.

Umm.

Yeah, absolutely.

But Brian is echoing, so apparently. So yeah, we're having a lot of issues with needing to refresh share I think, so we may need to. I also having some issues with things loading as well. If you do hit the refresh button Brian on your browser, it does help.

There's no echo though. You're not echoing. It says but he's gone anyway. Anyway, let's just keep talking about data sets anyway. You have probably seen you've seen data sets in your system. The person record in the organization are the ones that come straight out-of-the-box for slate. So person record, that's the one we all know and love. Organizations, also known as schools or institutions. There is another data set that comes straight out-of-the-box as well. The organization contacts those folks that.

You can reach out to at any of those given schools.

So those are the standard slate data sets that we'll see. And then Brian, you can tell us about the custom data set options that exist as well.

Awesome, great. And so we're just going to go into a quick overview and sorry about all of that into custom datasets and I know that Megan may have just touched on this briefly just now, but in terms of custom datasets, datasets allow you to configure independent records that can tie to other types of.

Records and to meet unique business reporting needs and just as Megan was mentioning earlier to you as well, Datasets should be really familiar to you. They may mirror and look very similar to what you already have out-of-the-box with the person record and the organization data set there as well. So with the person record that we do want to note that datasets are not necessarily a one to one comparison with the person record. It mirrors a lot of the functionality that you might have with it, but we just wanted to note.

That you may have already seen custom datasets because of what comes out-of-the-box with slate with that organization data set and that organization context data set. But what could be some options of custom datasets that you might want to implement into your instance there? One might be faculty. Some of my good friends over at Stevenson Institution Stevenson School out there in California gave a summit presentation on their portals and they talked about the use case of creating.

Faculty members, faculty data set as opposed to creating user records there. And we'll talk a little bit later down the road in this presentation about why you might want to do one or the other. Something you'll hear from a lot of us and you've heard at Summit many times is the answer to your questions is that it depends and we'll need to ask a couple of different questions of what is your ultimate goal and what does kind of that maintenance look like for you. Another another aspect of custom data set that you can create is clubs and groups and organizations.

So being able to track what different organizations and clubs are on your campus and then finally another custom data set could be community based organizations. This is something that we personally tracked when I was in a mission, just understanding who are we working with, where are those applicants coming from, and then collecting metadata about those Cbos. But we've shown you examples of what our custom data sets. But really probably why you're here is understanding how do I know when I should be.

Creating a custom data set. And when I come, when schools are asking me that question, one of the first things I like to ask is ultimately what are you trying to track or what are you trying to report on here? And the reason why I brought up it depends response there is that for faculty maybe that is just a prompt list that you have associated with an application record or person record. But if you came to us and said we really want to track metadata about the faculty members, how often do they teach?

Um, how long have they been at the institution? Things of that nature that might actually push us towards creating a custom data set so that you do have a central location where you are storing that information. The next might be permissions, and so this is something where you could permission out custom datasets to control who sees what and what they can do on those custom data set records. There you can also leverage population permissions to also control which of your users should be able to interact with those.

Custom data set records. Now I don't want you to take away from this slide that just because you need permissions that means that you should start creating a bunch of custom datasets. That's not necessarily the case. This is just something where maybe a combination of these options allow you to think maybe we should start to create custom datasets to kind of partition out our database but also for reporting purposes as well. In addition to that, we also have the option with datasets of portal logins or logins in general and this is what I was mentioning.

Earlier about that faculty option. There, of course you can create faculty members as user accounts in your database, but they can also be data set records that have a specific portal that's designed for them that only they can log into to see pertinent information.

The other slick piece with datasets and custom data sets is the ability to create both a parent and a child data set. Now you already have this in your database already, with organizations being the parent database and organization context being the child database there. So you can already start to think about options that you can create where you're creating a parent data set and a child data set and linking them together either by through their profile account option or through what we call a related datasets.

Field there. This example I'm going to show you next is talking about the parent data set being an academic course and then the child data set being the course section. So how often has that course been offered, what was the term metadata associated with that and what future sections will be offered there as well?

So in terms of, and I know this is going to look small and we're going to zoom in here real quick, but I just wanted to show you a 30,000 foot angle of what a custom data set could look like both on the dashboard and in custom tabs. But if we actually zoom in here at the very top, you'll see that for credit type, credits and status, this is just a dashboard query and we're displaying metadata about that custom data set, this one being Courses Microbiology 1. So we can see that the credit type is letter grade.

Offering three credits and the status is active there as well. Below that bar you'll see for Current sessions, Future sessions sections, and previous sections. We're actually just aggregating data of the associated child data set records there, so we're able to do that through the dashboard query here. And you can already see the use case of why this institution wanted to create a custom data set for those courses. If we Scroll down on that given dashboard page, we can see.

Putting what we call or what Slate calls an embedded data set row query here and this should feel and look the same of probably what you've constructed already at your institution where if you go to organization record, you might see past applicants that may have applied to that school organization or current students that may have come from there as well. And So what we're doing in that situation is taking organizations as that parent record schools as that child data set, kind of linking them together, not necessarily exactly what we're doing.

Here, but in some similar ways, we're displaying all the child data set records that are tied to that master or parent data set record and displaying that metadata about them. So again, you can see here there's term section, whether it's taught online or on campus, how many people are registered, all that good stuff. And if we continue to Scroll down there, we'll see even previous sections. Again, these are child data set records of the sections of those academic terms that are displaying on that dashboard.

But again, similar to Person records, you're able to then create custom tabs to store metadata about that record there. This is representing the child data set record of the academic sections, and you can see similar to Person and Application records, we're able to edit and display custom data about that individual record there.

In addition to that I mentioned, one of the other use cases is that login, um, so being able to create a portal that is scoped to let's say a custom data set that you titled faculty. So that you're able to allow them to see information such as maybe metadata about their programs or the students that they are seeing in there or additional information about faculty members or what have you. Having a data set scope portal allows you to control who gets the login and kind of control the information that they'll see within that.

World.

Let me now kick it over to Megan to talk about high level overview of entities.

Yeah, thanks. Let's talk about entities a little bit. What are they? They sound a little bit like a sci-fi concept, but they're really a really not. What are they actually? An entity is going to be an item. It's a custom data table, and it's going to allow us to store multiple rows of similar data to a record. It's creating a custom 1 Dominion relationship. So what does that exactly mean? OK, those are some nice words, but what does that actually mean?

What even is A1 to many relationship? If you haven't heard that term before don't worry you have seen it before in slate. You have seen how these work. We have some pre built one to many relationships that exist in slate right off the bat. Here are a few examples for you for instance schools.

A person may have many schools on their record, right? They are each going to have unique data. It might be the dates they attended, the degree they received, their GPA, the school seed code itself, the level of study, etcetera. There are many different records that exist, each with their own unique data points, but they all tie to that same person or jobs. You can have multiple jobs, different titles, different organizations, different dates of employment, different departments you've worked in, but those are all going to tie back.

To 1 record and they're all just going to, but they're all gonna have their unique data associated with them. Relationships are a third example. You can have many different relationships each with their unique properties in terms of the relationship type, name, contact information, etcetera. Those come straight out-of-the-box. Those are one to many relationships that exist in Slate but sometimes we may want to do go beyond what slate written initially offers for that and so that's where custom.

Entities will come into play. Entities allow us to expand upon that data structure that Slate already supports to meet our custom needs. Some examples would be something like language proficiencies. You can capture information not just about like the name of the language that someone speaks, but also details like what's their proficiency spoken versus what's their written proficiency. How many years has someone studied that language? Is that their native language, or is it not? We can capture all of those points of information one?

Pro per language and tie that to the person or maybe awards and achievements. You may have a student who's a high flyer who's done a lot of different things and we want to capture that information uniquely per achievement that's the student has made. So you think about things like getting the date for an award or achievement. What was the organization name? If it's something like maybe a publication, what was the, what was that authorship? What was the journal it was published in for an award?

What was the level of the award? Was it an individual award or group award? Were able to collect all that data one row per achievement or award.

Scholarships are the classic example. I think if you go in and look in the knowledge base and read about entities, scholarships are the item that will be highlighted there where we're thinking about a one to many relationship for an applicant with scholarships. Potentially it's a classic example in Slate, but you're thinking about each scholarship a student can receive. So students will receive several scholarships. Each one may have a different name and dollar amount associated with it, but also things like is this a grant?

Or is it a scholarship? Is it a renewable scholarship or a one year scholarship? Is it an institutional award or is it external? All of those different data points can be captured within an entity. And for our friends over in student success, you are not forgotten. There are opportunities for entities as well. For you all, one of the ones that we see a lot would be holds or alerts. We know that students may have the same hold several times, overdue balances or parking.

Invitations for if we've ever done anything with student success, we see those a lot, but we want to get those specifics of each iteration of that. So what was the date? Is that hold cleared or still active? Are there any comments on that hold? We're able to store each of those as a unique row for the student.

So what does that actually look like on a record? Well, here's an example using Megan Test, Miller test, whoever she might be, of what an awards and achievements entity might look like on a person record. We can see there's several different sections that we can walk through here. At the top there's a Section 4 Awards where we're detailing things like the awarding body, the year that that award was received, what the award name is, the type.

Or the level. If you're zooming in and looking at that, I want to reassure you real quickly. There is actually no such thing as the International Association of Slate Administrators. So if you see that on there and you feel like you're missing out on something, you're only missing out on a figment of my imagination. So don't panic there. But you're able to see the details for each of those awards that have been offered for that that student record.

We also have a section here for patents, so we can see all of those cool things that I've invented. I agree, David, that it should be a thing. We'll see if we can get that started. ISA rolls right off the tongue, but patents, all those cool details here we can see all these things that I've invented as well as scenes, how that intellectual property is registered to me by country, what's the status, some of those other details that exist or we look here at publications, all these things that I've.

Written or just written in my imagination, uh, where I can see some details on the date, the publisher, what kind of publication type it is, what my authorship is. There we're able to capture all of that information in unique rows, and we can collect as many rows as we want depending on how much we've we've done on or whatever record has done. Note that these are all living on one entity called awards and achievements here, but you could.

Finally, set that up as separate entities as well. We can create these. These are created currently with some filters to limit which ones display. You could absolutely have them as editable roles as well using an entity widget. Here we're just using liquid looping to display things, but you could also create these on a tab with some entity widgets to allow for editing as well. But we're just controlling what displays on that record on this custom tab.

Based upon uh, the entity classifications and information.

So why would we use entities? I think this gives you an example of how entities work. I've seen some good questions coming in and I will we will speak to those in a few minutes. Let's talk a little bit more about the potential, not just the potential for entities, but practicalities of them in the past, prior to when entities were available or maybe prior to you knowing the opportunities that entities may present for us all your institution may have had in its database.

Some series of fields like scholarship one name, scholarship one value, scholarship two name, scholarship 2 value. Or maybe you have some multivalue fields for to capture like all the areas of interest on a record or things like that. Why would we want to use entities instead of a series of fields on a persons record or application record? Why would we want to use that in an entity instead of a multi value field?

I think there's several different opportunities that entities offer us that we can want to consider here. First of all, entities are going to give us much deeper record insights when it comes to looking at that record as a whole because we are able to view data that's going to expand based upon how many rows a record has and we're able to get much more data information on each of those rows. So if a record has 12 rows of data, we can see all 12 of them.

If they only have one, we just have to see the the one, but we don't have to worry about creating a bunch of different fields in hopes that if someone has 10 languages they want to report, we are able to collect all of that.

Entities allow us to collect as many as we want to, or as few as we as the student has. So we're getting able we're able to get much more robust data about each each of those specific iterations of data.

Additionally, because of that we get a lot more opportunities for reporting. So the report, not just insights on the record, but our reporting can become much more robust. Entities are a base you can query on and report on with configurable joins and that allows us that really opens up some opportunities for us where we can do reporting on those entity rows themselves instead of looking at those field values on the Person record. So for instance.

If we want to build a report that shows all of the languages that are incoming class of 2023 speaks and we want to see aggregates of that, we can actually do an entity that's using the the language report that's looking at that entity row and listing all of those as the report base versus trying to pull information from the person record. The benefit here also is that with multi value fields it's really difficult sometimes to aggregate data very cleanly.

On those roles, especially if there's records that may have more than one value, but because we are able to use the entity and pull each value individually, that report is going to be a lot more robust and give us a lot more insight. The third detail to think about here is the detailed communication that we can have with entities that sometimes would not be possible using multi value fields or using just a bunch of section grouped fields together. They allow us to be much more detailed in our communications to our records.

Uh, Liquid looping is a classic thing that entities are great great with. If you haven't heard of liquid looping before, liquid looping allows us to loop through each entity row and display data in a specific way for within a communication. We can configure how we want that to display, but it'll display one section per row of data that we're pulling. So you're thinking about something like a decision letter where you want to put a scholarship table into that.

Decision letter. You're able to create a decision that scholarship table with one row per award. If someone has three awards, it will pull in three rows automatically. If they have just one, it'll just put in one row. If they have seven awards, all seven would display.

It also allows us to think about things that a multi in terms of using some of those communication tools that would not be as user friendly using something like a multivalue field. So for instance you could use liquid looping and take the value on each entity row and use that to return a content block and have different content blocks displayed within an e-mail based off of that entity because there's one value per entity row versus a multi value field.

Where those might smash altogether and it would make it really difficult to do something like a content block there. So that's a nice opportunity as well when you're thinking about those communications.

One other thing to think about here is that you don't have to use these separately. They also can be used together in some pretty cool ways, and so we're going to think a little bit about how custom datasets and entities fit together.

Um, 1st way that you can think about using entities and data sets together is by creating some custom data set scoped entities. Entities can have a lot of different scopes so it's based on any of those record bases within the system are are going to allow you to use entities. So person scoped or application scoped. You could have an entity that's organization scoped. You could have an entity that's scoped to your custom data set so you're able to create entities that tie to those custom datasets themselves.

To capture some one to many relationship data.

Some examples that we can see here. For instance, maybe you have a student organizations data set. You're a student success instance of Slate, and you could have an entity for upcoming events. Maybe you don't want to give all of your student orgs ask access to the events module and Slate, but you do want to be able to list out what upcoming events are available for the for each organization. So a student org could put in a form that creates an entity row listing the date and time and title and location of each upcoming event and be able to pull that in.

To a communication or into a portal or something like that, based on those entity rows tied to the organization's data set. Or maybe you have faculty members who have different areas that they will advise students on, and they have you have faculty who are engineering faculty that can do advising on computer engineering or on computer science.

You would be able to pull in entity rows to link to a faculty data set indicating what the areas of advising are available for that faculty member, and some other considerations there. This is the third example of this program data set. This is something Brian and I have been working on with a client currently, and so this is something that's top of mind for us. But this idea of being able to create application deadlines tied to an academic program, looking at each semester and some of the details about the.

Application deadlines, what that might what what opportunities might exist there for us. We know that different programs, especially in the graduate side of the house, will have a lot of different deadlines. They're those deadlines can be based on a lot of different considerations. And so if there's a way to simplify that, that gives us a a real win in terms of administration and in terms of ease for students who are applying. So if we're thinking about that, you have a custom data set record for academic program, the academic program.

Data. There may be a lot of different things. For example, in this in this school we're working with right now, we're able to record things like what is the chart of account, what's the routing information for the fine, for finances, for reallocating funds, for application fees or you know, what department does this live in or what are some of those checklist requirements for that program. We're storing all of that information on the program itself. But in addition to that, we're also, we've also been able to create an entity that is scoped to that.

Academic programs data set to capture some of that academic academic programs application deadlines so that we're able to manage things a lot more easily both in the both within the application itself, application logic, but also in the ways that we're communicating to students. If we look at something, an example here, here's a program, we have some basic information on the top about some of the qualities of this program, but you can also see that there's an academic.

Deadline section that exists and it's looking at. It's split out by term, but we can see there's unique information per term in terms of when does this, When does this program open for this semester? What is the deadline for international students versus what's the deadline for domestic students? We're able to get all of that information and display it in rows. You can see that add semester deadline link on there that's indicating that this is an entity widget. So if you click on one of those.

Those you will be able to add another deadline granting permissions to the right folks to be able to create those deadlines on the program. If you click on that, you can see this is what that entity widget it will look like. You can see we've got some basic information about the semester. Some of those basic points about when the when does it open, when does it close for international students versus domestic students. You could add other fields as well if your materials were due later than the deadline. For instance, there's checklist materials that can come in late or if there's a standard.

Notification date that you want to know. You could pull all of that in there as well. For this, we're really looking at that semester as being the driver that's defining each of these rows that's tied to that record. And then for each semester, there are unique values that exist for the open date, for that international deadline or for that domestic deadline. This is really great. It does not just help us in terms of driving app logic when it comes to submitting the application, but it also is helping empower a program portal that we've configured.

It allows us to display each of the programs that's available to a student, see some basic information about each of those programs, but also see the information on when that application is going to open, when it's going to close. If you're an international student or a domestic student, that gives them a lot of information to help them be informed before they even start that application. So that's the 1st way we can think about using these two together, entities and custom datasets. In addition, we can use entities and data.

That's together to tie multiple record types together by using entity scoped related data set rows.

If you have heard of related data set rows before, um, they are often used on records to allow us to tie a person record or an application record to another data set in the system. The most common example that I can think of is creating an application scope related data set row that collects information about the school that a student will attend if they decline your offer of admission. So that's the standard idea of a related data set row, but you can.

Also use those on entities themselves to be able to tie two different kinds of datasets together with that entity. So for instance, academic programs like we talked about before that could there could be a person scoped student academic interests entity that would allow the student to record their different academic interests. Each of those tied to one of the academic programs within the database. So if a student has more than one academic interest, we can capture the details about each of those.

In terms of what the program is, what term they're interested in, enrollment load, things like that.

External organizations data set. You could use something like that to collect information on a person record about student involvement. So external organizations like the Peace Corps or AmeriCorps or Teach for America, McNair Scholars, National name Exchange, lots of those different kinds of organizations where it's really helpful to track that information. You might want to have a custom data set for those kinds of organizations because of the way that your school works with them and the way that some some of those partnerships.

List and then if you're able to tie that student directly to each of those organizations using entities, that gives you an opportunity to tie the two together, creating a mini to mini relationship where each organization may have many students tied to it and each student may have many organizations they are tied to as well. And then going back to what Brian talked about a little earlier with core sections, those class sections that might exist that you're offering from semester to semester.

You can tie that back to the person record using a coursework entity saying what's the students coursework? What are the courses they've registered for or completed. We can tie each of those entity rows to a course section that. Let's talk a little bit more about what that might look like. You have a person record as a person, most of your students if their student success if they're using a if they're using. If you're using slave for student success, most of your students are probably going to register for more than one.

Force across the course of their academic career. So you're going to have multiple different course registrations. It may exist, and they may have different statuses, different grades, different terms that they were they existed. Some might be weightless or withdrawn versus registered, but there's going to be quite a bit, quite a number of rows that may exist. Each of those courses. Each of those registrations is going to tie to a unique course section. SO1 might tie to microbiology for spring of 2022.

One might tie to Introduction to Psychology for fall of 2023 et cetera. So each of those entity rows going to go out and tie to one of those custom data set records. Each person may have multiple course registrations each each course section will have multiple students who are registered for it. So that entity is going to tie in a want a mini to many kind of relationship and what that might end up looking like on a students record is we have.

Custom coursework tab here. For those students coursework that they've completed or or has in progress, we can see that we have broken this down and captured some of that information. So we can see here the current coursework, for instance, what is the name of the course? What section and session is it? What term? What's our status? How many credits are we earning? When does that course end? Now Note that within this we're not just displaying information from the entity.

Itself, but we're also pulling information from that course itself is the course section. So the course name, the semester, the number of credits, those are all data points that live on the core section, but we're able to pull those because they're tied together. That entity ties to that course section. We're able to join to that course section and get that information and display it as well. We can also see there's a section for future coursework courses that haven't started yet, but that someone is registered for. We can again see some of that status information and what's going on.

Um, when when a when I start am I on a wait list for registered see that data?

And we can see the previous courses that I've taken, so we can see what courses I've attended in the past or withdrawn from. And there's some custom data that's existing that's from the entity itself here. So the quality points and grade, those are going to be unique per record status of completed or withdrawn. That's going to be again unique data per entity row. But some of this other information, the name, the section session, like I said before, those are all going to be true for all students who are registered for the course.

And so those come from that course section itself.

And then as Brian mentioned earlier, those embedded data row queries on the course section itself, we're able to see a query of all those coursework registrants and see the details that exist. So for this microbiology class, we can see all the information about the students as well as the status and the grade that they've earned because they joined together and allow us to see both the information about the course but also the the students who have taken that course.

Um, some of this unique data that comes from the entity versus coming straight from the straight from the course itself?

Thanks, Megan. Yeah. And just like you mentioned just now we've talked a little bit about what are some use cases and examples of entities and custom datasets and how you might go about using the two together. But I think it's always important to talk about the power of these features and what to consider when actually implementing them in your in your database there. The first being about data quality, I think when we talk to a lot of schools.

So that was quite a lot of information. I think at this point it's good to hand this off to Brian and talk a little bit about some of the considerations that we want to have when before we just jump straight in.

We just always want to warn a little bit that entities and data sets are not necessarily going to clean up your data structure or clean up the data that is in there. It actually might add more complexity. And so we always do want to warn before diving into some a project like this to fully understand your data structure and if there is some organizational cleanup to do to do it prior to actually implementing these features of entities and custom datasets. This phrase has been sent so many times that summit and on webinars as well, but truly.

Leave it up of garbage in, garbage out. And so really kind of make yourself make your job a little bit easier by first addressing what are the core issues. Before diving into. Let's start creating a bunch of custom datasets that will hopefully solve our issues. The next thing is with rules editor. I believe someone mentioned about unique identifiers for entities and being able to import them, but with the rules editor I do want to note that it currently is not.

Possible to create or update any entity values, so that is a current limitation with that feature there. We'll talk in a moment about kind of ways to get around that, but just something to note there as well and then also where entities actually work. So currently entities are possible, you're able to add them onto custom tabs and then you're also able to add them on application scoped entities within the slate hosted application.

And I know Megan is praying right now and hoping that person scope entities would be available in the application. So I think with there's about 300 of us right now, we can all Crowdsource and upvote the same feedback post, get that, get that public in up and running. But in addition to that, we also wanted to talk about read and write permissions there as well. So the ability, so something to know when you're actually testing this out is that a user in your database may have read permissions of a custom.

Tab. But if there is an entity on that custom tab, they will be able to click on it and be able to see a delete or an add button of the entity there as well. So just a small little kind of heads up for you all as you're kind of configuring this and thinking about how this affects the greater database there. But I mentioned to you all as well about.

The limitation of the rules editor, but potential workarounds that we have found successful are web services and an export import process. And when we say that I think that phrase export import process is said a lot in this like community. But explicitly using the query builder tool to push out data maybe overnight into your SFTP incoming folder or what have you and then using the upload data set tool to bring into slate so with upload data set.

You are able to update or create entity rows. So each entity row has an external ID that you can configure. Typically what we like to do upon import is we like to use the Field Fusion tool and to be able to concatenate certain data points in that entity row to create kind of a unique identifier. So then that way upon that export import process you're able to update that given entity row or if there's nothing that matches it will create.

Kind of a new row in that entity table there.

I've seen on the Slack community there people creating an export import process and kind of sitting back and being proud and it is a very satisfied feeling once you're able to get it up and running. Question we also had was are we able to delete entities? You are actually able to if you manually go to a record and go to the custom tab. You can't delete it right then and there if you want, but in batch you can also use the retention policy as well to help you out with deleting.

Deleting any erroneous rows or data rows that you have within that entity table. And then finally we found some success with using merge fields and hidden fields on the form, potentially using a unique identifier for that entity row and being able to update those values as well. But some things that we've we found successful working within kind of the limitations of entities as they exist today because as you know tomorrow they could be updated and we could get that person scope entity widget up and running as well, so.

Let me pass it over to Megan to talk about common mishaps we see happen when dealing with entities and custom datasets.

Yeah. We, we know that there are a lot of opportunities with datasets and entities and we also know that there are lots of opportunities to make mistakes along the way with those. So let's talk really quickly about some of those frequently encountered challenges that we see. First off data set row.

Names. So if you have A and, this is going to be a particular challenge I think for where your data set rows where you need a name that's coming from multiple field values. Especially thinking about things like child datasets like an organization contact for instance, where you've got multiple data points that don't drive that row name. Now for the standard slate datasets, Person record, especially slides, already got that configured for us what that display name is going to be, it's going to show the last name and then in parentheses.

Is going to be whatever previous last names were used, comma, first name, preferred name, and parentheses. There's a standard rule that's been set up to display all of that information as the person name for each record. Unfortunately, Slate cannot read our minds yet, so it does not necessarily know what we want to have as a name for each custom data set row. Therefore, if you don't get that configured for for data sets where multiple rows feed into the name of that data set row.

You end up with a blank name, and that is pretty confusing because everything there's no names for any of these. It's hard to tell what what record you're even looking at. So remembering that multiple if there's multiple field values that need to feed into your data set rows name, you need to make sure that that's set up appropriately. Each custom data set will have its own exclusivity group, rule type four name, so you'll be able to set that up per custom data.

That you can set up rules for the name. The rule type is Name when you're creating that rule and think about what kind of concatenations of values you want to show there. If it's something that's going to come straight from your SSIS or straight from an import and the name is going to already be just fine the way it is, you can also map that directly. There is that name field that exists in the record properties that you can map to, but for those where you're going to have a first name and a last name, for instance or maybe for a course.

Section where you want to have the name of the course plus the semester and section or something like that. They're concatenated together. You'll need to make sure you're thinking about setting up rules appropriately for that so you don't have a bunch of blank rows of data.

A custom data set. Keys are the other thing that we want to make sure we're thinking about when we working we work with a data set.

Custom data set keys function the same way as like those ref IDs do within the person record for Slate or the application for Slate. It's a unique identifier that's defined for each record and so you want to make sure that you're getting that uniquely identified. Seems kind of intuitive if it's a unique identifier, make sure it's unique. But we have seen some challenges in the past sometimes with that where the the details that we think are going to.

Be able to be used to define a unique identifier for a record. There is a little bit more complexity to that than we expected if your.

Your unique identifiers are not truly unique. You are going to run some into some challenges when it comes to importing, when it comes to creating new records, and when it comes to rules. So think about think really carefully about making sure you're matching criteria are not going to match on more than one record. Also make sure that your rules that you set up for custom data set keys, if you're going to use rules to set those, make sure that those are really solid. We run into problems sometimes where the rules are not.

Configured properly and we know that if rules don't run the right way.

Um, if there's errors in one rule, it has a cascading impact on all of the other rules that exist. So if you need to use a custom key for your records, maybe you want to pull like an SSID and concatenate a couple different things together, or something like that. Make sure you're really thinking through those rules. Make sure they're configured appropriately. Account for blanks or null values so that the rest of your rules continue to run as well.

And then finally, entities. Entities do have a unique identifier as Brian mentioned, they come with an external ID, but we have to make sure we're matching those entities to that external ID or another unique identifier so that we don't end up with a bunch of duplicate rows. Especially if you're bringing in entity data in an import from SSIS or from another system where it's a cumulative files that come each night you don't want to accidentally.

It up with a ton of rows of the same academic hold on our students record or something like that. Same scholarships listed many many many times because you didn't match on a unique identifier. Make sure that external ID or some other unique identifier is being properly populated if you need to update entity rows or do anything like that to make.

Make the rows that already exist have data that shifts and change changes. A lot of times you can think about things like concatenating some values together to create those external IDs. That external ID needs to be unique per entity row on that person's record, or application record or data set record. But the key could be the same key as the entity row for another record, so you can do things to make. It doesn't have to be so unique that it's the only iteration of that in the system.

Yourself, but you do need to make sure you're matching to both the entity row and to the record it's tied to. As a best practice, we do really recommend that whenever possible, you do set up some kind of external ID when you're creating that entity row so that you have something to match to as well.

So let's just go ahead and quickly recap what we've talked about. I'm going to let Brian really quickly walk us through a few things that we discussed and we'll take some questions.

Awesome, great. And so just as a high level overview of what we've talked about here, custom data sets are those independent records that can link out to other records but also be able to store metadata about them as well. And entities are dependent on rows of data that create custom one to many relationship for that record. And really the high level what you can take away here are custom datasets are individual records that we've highlighted here whether they're faculty members.

Whether they're Cbos, but entities have to exist on a record. So whether they are tied to an Application or a person record, but also a custom data set record there as well. When using them together, we wanted to talk about how Datasets scoped entities can be used to capture custom one to many relational information, but then that related data set row field within entities can connect those records to one another creating a many to many.

Relationship there as well.

Some of our best practices before implementing and evaluating your data structure and considering how datasets and entities create and manage data. As I mentioned before, datasets and entities I would say only complicate and further add layers to your database. There it can be extremely powerful and using them together to organize your instance. But to be able to draw out before diving in breaking ground is extremely important. And then avoiding those communists by using rules and unique identifiers and.

Image new or updated records or entity rows. Back when I was working in the service desk, a common request we'd get a lot is our rules are not working. They are completely clogged up and they have not run for days. And not saying this happens all the time, but one common thread we'd see a lot is that there would be a data set key rule that was created and there was a duplicate key there. That would kind of junk everything up and it really hard to find in the haystack there to mitigate but just wanted to put that out there as an overview.

And let's send it off now. I know we have a few minutes for question and answer.

Yeah. So you guys have sent a lot of really good questions, which we could spend hours probably answering questions about this, but let's go ahead and just look at a couple of the ones that came in.

You know that I saw several questions start popping up when it came to questions about the application logic or the application deadline configuration. With academic programs, how do we, how do we do that? How do we make sure that the application logic accounts for the appropriate deadline based on term? So you are going to be looking at some independent subqueries potentially here where you are going to be comparing the the value for that semester.

With the value of the semester on that students record. So you're looking at it, you're going to be doing something like joining from the application to that application program that exists. If you're if you're doing something we let me let me back this up a little bit. The way that we've set things up is that the student applies and they are applying for an academic program. There is a join that is occurring at that point. The application has a related data set row that ties to that application program. So they are all already.

Joined as is. So when we are looking at application logic, we are joining to the application and then in a subquery we're going to join two those application deadline entities, compare the deadline of for that semester and that entity to the deadline that the students or the compare the semester to the semester the students selected. So when those two match, we want to look at what the deadline is, see how that compares to.

The current date. So it's getting a little bit deeper into the weeds, right? You're joining and then you're joining some more and then joining some more and then doing some comparisons and the hokey pokey and you turn yourself around and then you find out if you're you've met the deadline or not. But really you are going to be doing several series of joins if you were going to be doing something where you didn't want to. You wanted to have those applications, those programs live as their own independent thing. The student was selecting something like a prompt to select their program.

You would need to do an independent subquery to compare both the program name to the this program the student selected, and then also the semester to the semester. You need to make sure there were some unique identifiers matching up, maybe export value matches the key for that program, and then also looking at what the deadline was based on that semester versus the semester on that entity. It's kind of complicated. It's not very good. I just talking with my hands trying to explain it. It's not probably helping a whole lot, but.

The idea is there's a lot of configurable joins, and depending on how you're connecting your program up with your application, you're going to approach that from a couple different angles.

It is, yeah.

Yeah.

Hmm.

It should be an Olympic sport to talk about considerable joins in just words and not actually demoing it. Yeah and I know, yeah and yeah. Another question that we had was can data be deleted from either for example, financial award that was posted but now needs to be removed. Just wanted to to reiterate that yes, you can either do that manually directly on that.

Record or through a retention policy where I know that there are a lot of student success folks out there that probably have regular retention policies that are running. Very, very thankful that those overnight processes are back on to be able to clean up those entities that maybe you have a system that doesn't necessarily tell you that they're deleted and so being able to do that in slate.

Yeah.

Some questions around scope. I think we have talked a little bit about this at this point. In terms of how do we what can entities be tied to? Entities can be scoped to a specific data set. So you could have a person scoped entity or an application scoped entity or a data set scoped entity. Entities can also be scoped to multiple things at the same time. So you could have an entity that would be both person scoped or application scoped. That is sometimes the case that we that we see.

Just remember that these are different objects at that point. So if you are mapping data to the application, it is not going to just automatically go over and also show on that person scoped entity as well. Those are those are going to be independent of each other. So if you are using some kind of entity where you have it scoped to multiple different data sets, just remember that each one you're going to have to join a little bit differently, but you can scope things in multiple different ways.

Annuities.

We had another question, uh, China asked can we use entities in checklists for applications? If not, is that something that option may be released in the future?

OK.

I'm not going. I'm always curious about the use case as to not using kind of the standard checklist items. Not saying there isn't a good use case for it, but I would. I would emphasize that Rules cannot place entities on an application record or any type of record there. And so there we would need to kind of suss out a little bit more of what the ultimate end goal is, because you could theoretically have some sort of process that's importing those entities and adding them onto the records there. But for the most part I would say we try to stick with what's already standard.

Yeah.

In slate there before recreating an existing feature.

Yeah, a question I see from Vicki that I really like is the question about we can't update entity fields for via rules, but can we maybe update a person scoped field using data from an entity? And the answer is absolutely yes to that, with the caveat that you want to make sure you're careful to specify which entity row you're looking at here. So you could definitely take something like a calculation formula to maybe if you wanted to say like number.

Of publications, aggregate the number of rows of entity data that exist that are publications and have that populate in a rule. Populate a field that's number of publications. You could do something like that. You could also, if you wanted to have like maybe the most the rank one entity row. You could also do something like join to the entity on the base, specify which entity you're looking at, maybe ordered by date or created or something like that and use whatever data.

This on that rank one entity row to populate data on the fields for a person record or an application or something like that as well.

Yeah.

Yeah.

And we are running up on time. I know there are so many questions on there as well, but we wanted just to put our information up there and really appreciate you all spending your time with us talking about entities and datasets.

Yeah, thanks for bearing with us at the beginning with the technical difficulties. We did finally get it figured out. So thanks for sticking with us. And if you have any questions that we can answer further, you can see our contact information on the screen. Brian and I could probably talk about it all day long. So feel free to pick our brains at any point will be really happy to speak with you, with you more about the the power of these two different objects in slate.

Have a wonderful week and we will look forward to connecting in the slate verse somewhere. OK. Thank you.