Dive Deeper with RHB: Maximizing Slate for Student Success

Exactly.

Right. Welcome, everyone. We're gonna give it a few minutes for people to join us. So. Or give it a minute or two. So sit tight and feel free to put in the chat. Send your greetings, and tell us where you're from.

All right. I've still got a couple of people joining in. There will probably be a few coming in a little bit late as well.

High Oklahoma State, University of West Florida, WSU.

It's good to see everyone.

It's always fun to see the number of participants just increase as people add into the.

The webinar. I enjoy that watching that number go up.

All right. Well, I think we'll get started and I am Christine Peterson here at technicians and I'm very excited to be here today with Abraham and Jolene from RHB. They'll introduce themselves a little bit more in a minute. But we're here to talk about maximizing slate for student success, which I'm sure you guys are all very excited about as well. I am a student success program manager on our student success team here. So I'm.

Very excited to hear what they have to say and hear all the great tips that they're going to share with us today. We have just a couple of housekeeping things to go over before they get started. First of all, this webinar is being recorded right now, so anything that you put in the chat will be available for people to watch later. And keep that in mind, but also you will be able to view this later if you want to close. Captioning can be enabled by clicking the little button that says CC up in the top right corner of your window.

And you can also get your full screen viewing there as you can see on the slide and click the expand button.

If you need if things get out of sync and you need to resync it, go ahead and just refresh your window and that should take care of it. And feel free to post any questions that you have in the chat. Abraham and Julie may answer them as they go. Otherwise, we will have a Q&A session time at the end of this webinar and we will take a look at them then. So without further ado, I'm going to turn it over to you guys.

Hi, my name is Abraham Noll. I'm joining you from RHB. I will tell you a little bit more about RHB here in in a slide or two, but a little bit about myself joined RHB a little bit more than two years ago. Prior to that I worked in higher education.

For 17 years.

And most of that at one institution, McAllister, College of St. Paul, MN.

I was the slave captain there for a number of years and have had the privilege to be involved in many different projects before enjoying RHB. After joining RHB, I'd say I work.

With implementations of a variety of sorts. So I've done admissions, student success and advancement, and then portals is kind of one of the things I enjoy doing. So that's I tend to get a lot of portal projects throughout my way. So with that said, I'll allow my colleague to introduce herself.

Yeah.

Hi, my name is Jolene Monson and I am also from RHB. I've been here for about a year. Before that I was at also in higher education, primarily at business schools I started in.

Program management and and student management and then moved into marketing and admissions where I worked in sleeve for about.

Let's see for about 7 years before coming into HB at Yale, so, and then before that at MIT and before that an institution in Germany.

So we are here today for a conversation about Slate for student success.

I think the thing I would say is that I think both Jolene and I would welcome the opportunity to have a conversation with you. Meaning if you ask questions as we go, we're OK with that. This is going to be less of a like a full polished presentation, hopefully more of a roundtable presentation. We really want to talk conceptually about some of the things that we've learned doing a couple of student success implementations of different flavors. And then also really, you know, take questions from you and see, you know, what are some of the things on your mind relative to doing student success and sleep.

So today we'll be, you know, we welcome questions as we go again. We will have questions available to be asked at the end if you'd like.

But we'll be covering a couple of different topics as we go through the material today. A little bit about our HB founded in 1991, we have worked with more than 300 institutions for enrollment, retention and revenue goals.

The RHB split into four different practices, enrollment management, Executive Council, institutional marketing and slate and related technology. Both Jolene and I represent the slate and related technology arm of the consultancy today in our roles. And you know that that part of the consultancy is the part that would be working primarily with the slate world. However, the other parts of the consultancy also sometimes we do some cross work. So that's kind of the one of the.

Advantages of working with RDP and that we try to do a holistic approach to our projects.

So in terms of what we're going to be covering today, a couple of things. You know, first of all, thinking about standard sleep features for this sort of student success population, what does that really mean relative to doing a success implementation?

Secondly, talking about portals for campus community groups. So campus community groups could be any number of different community groups. And when you think of a portal generally in a typical of mission implementation, that portal is facing toward the student and certainly for student success, you could do that. However, the beauty of slate is that you can now open it up to faculty groups. You could open up potentially to administrators that are not faculty but also work with students, which we'll talk a little bit about as one of our examples.

You also have the ability to open up to outside constituencies. Now that is most commonly seen through an alumni volunteer portal, which some of you probably have done. However, with the student success idea, that opens really the door to do for many different types of constituencies, and then you can you can blend into some advancement activity. So imagine a scenario where you have a portal that starts in student success as a current student, but then lands in an advancement world sort of on the end of the student lifecycle experience. That's also possible with some of this technology.

And then a big one that I personally think is really strong and slate is communications. So if you're coming from either the advancement or the admissions world, you're probably very familiar with the variety of communication tools that you can use in slate. It's amazing what you can do with student success. And we're going to talk a little bit about some of those kind of things days and to give you some examples that maybe hopefully give you some ability to dream about what you could be doing in Slate as far as student success goes.

And then I think the second thing is we're going to be going over some of these topics. So how do you use dashboard and tabs for quick view of students, profile permissions and populations? So really thinking about who can see, what they can see. Custom entities are everywhere in a suit success implementation. So that's huge. So we'll talk a bit about that. And then the final one, one of my personal favorites, how to show student photos in Slate, the three ways to do it, there might be more, but we know that at least.

Two ways to do it, all with differing degrees of things that come with them.

So with that intro said, I'll turn it over to my colleague Jolene, and I believe she has some examples for you today.

Yeah. So to kind of cover a few of these these things to give you an example of some of the work we've done with Sewanee, the the University of the South where we helped set up their student instance that we.

Would be happy to show you.

Right here so.

Um.

You can see from this test example or from this test account an example of a student record that we built. So we custom built a dashboard and a variety of custom tabs which Abraham mentioned is very very common in a student success implementation. The reason for this is that the student record becomes kind of a landing page for staff and faculty to view information about the student and you can really control in a in a in a really nice way what somebody sees.

This is also linked to.

Permissions because what we're able to do with configurable joins and through some some unique sub queries is that we can hide certain boxes. So a good example here would be the cumulative GPA. Because I'm impersonating this account as as an All access user I'm seeing this cumulative GPA box. But if I wasn't if I didn't have the correct role as the current user then I wouldn't see that box. I also wouldn't see some of the the tags and some of the tabs here and within the tabs.

Then you can get a little bit funky with your with your with your permission. So this tab in particular, if I'm not an advisor of the student, then I am only going to see this top portion here up to this line. And if I am an advisor, I'm going to see the advising notes on some of my student successes that I've noted down some registration pins in case the student needs some help registering for the next semester. I can see their pin number there that they can connect to banner in.

Um.

So you can really kind of get really granular both within tabs and in the actual tab settings to kind of control what somebody sees.

We also talked or we also mentioned just a minute ago about custom entities and really custom entities are where it's at for student success implementations because you cannot hold so much in it. So we have a current advisor custom entity here. My test record isn't registered for any classes right now at Swanee, but if you saw if they were registered, you would see all of the classes that they were had been registered for were registered for the next term.

And then these two sections pop up depending on the role of the current user.

Um, custom entities are really really useful to to show notes and to keep notes on students notes of different capacity, or from different offices on campus or for different reasons, and these can all build upon each other. You can also build notes that have review statuses built into each entry to kind of keep track of if if something has been kind of followed through on on a on an office in in an office.

Workflow and without necessarily kind of bumping this this.

This issue into a full workflow that would that would require a full um kind of committee review or or a full.

Yeah, or review of the of the situation that might warrant like a full workflow for like cheating on an exam or or another issue like that.

Umm.

Very often in student success implementations, all schools want to see a photo of their student. That's kind of the the thing that everybody wants to see. So we wanted to share with you three ways that we have done in the past to share photos of students, really depending on how you.

Can best how your we do this on a case by case basis based on what is best for the school. First Swanee what we did is we actually used the student library or the deliver library so every every student's photo is uploaded. We used a folder system to try to keep the photos in a way that would be easy to archive, either archive or remove. Once a student was graduated from the institutions that the photos weren't hanging out there forever. Not going to click on one of these photos because I don't want to show you.

Lots of smiling faces, but each photo is titled their studentidnumber.jpg which is how we get to in liquid markup the photo in a in a dashboard or in a portal in order to show the students face every time that that we that we look them up. That is one way. Abraham, do you want to talk about another?

Way or another few ways.

Sure. So, you know, kind of putting this under the umbrella and I'm going to extend this even a little bit further. So I actually worked with the client recently who wanted to do photos in a portal and in their slate record, so differentiating those two things. But then they also wanted the ability to store pronunciations of the students names. So I thought that was a really clever thing to do.

I've never run into that before. The challenge with both of those is it's there aren't really a there's not an easy place to put that in slate, so if you're familiar with the application tool, there is an ability to upload an application photo.

For the admission product. But that photo is not super easy to get access to and it really is A1 on one thing. The other thing is that.

You know, when you talk about other media types, it's technically possible to put them places and sleep, but to extract them in a way where you can see that through the HTML may may not be possible. So we've seen classically kind of these three approaches. So the first approach was the one that Jolene showed you, which is essentially you leverage either the tool for the library, the library tool in the message system delivery system, which essentially is a outward facing archive, or a web directory.

So if you've ever put a a photo or if you ever put a.

Hmm.

The image or other assets into a message, there's always that string that I think it's www.image. Is that what it is, your name something and that's pointing to that specialized directory tool or the specialized library tool that Slate has built in?

OK.

Hmm.

The other method similar to that is you can use the file area of slate. So if you're familiar with setting up portals or you've worked with the branding assets in Slate, there's another part of the system where you can put files. The difference between I think those two things is that for the library tool you really end, correct me if I'm wrong, I think you're limited to only uploading certain types of assets so you're limited to images essentially. File tool and giving the example I gave earlier where the you might want to have a name pronunciation.

You can upload any type of file, so you could have you could have MP3 files for example or videos or other things.

The challenge with with both of those approaches, however, is that there's no way to mass pull files into the system. So it's an excellent way if you are OK with dragging files from one part of a 1 from 1 directory to a different part of the to different directory. But if, say for example, a student changes their photo, somebody has to do that. There's no mechanism built into slate to automatically go out and extract those photos and pull the new ones in. So that's option one. It's not a bad option, and we definitely have seen folks.

Use it for variety of different things and this this is a great example of that.

Option two is a variation of that. So what it is is instead of having the directory or the assets hosted on the slate system, you actually host them in a separate directory. Typically what we see is that directory is controlled by a central IT department who has the ability to mass pull files into that directory.

That sort of solves the problem of updates because what you could do is you could have those updates constantly coming in or you could do different times of the year then coming in so that that solves that problem. The big downside to it is that, and this incidentally also applies to the to the other method that we talked about earlier that is open to the Internet. So potentially somebody could scan that directory, they could see all those photos and they could download them or do things to them. Now this is where your policy comes into play.

You you know you have to decide what is you know from A and I won't go too deep down this rabbit hole, but Ferpa, what is your directory policy? You know what are the kind of things that can be shown to the outside world and that it may include a photo of the student. On the flip side, you can also do security guard security. So if you put it into a deep enough directory that's relatively hard to find. So it would be hard for an outside person to find that. And both of those approaches, you know that approach of that security, that obscurity is is OK in many cases.

Uh, so you have to kind of look to your your security professionals that your institution, what are you OK with? What are you comfortable with? I think the big thing about those photos are you don't want to name them the name of the person. So typically what we will see is one of two flavors. We'll either see a username, which is useful in some cases, but more commonly we'll see a student identifier or a slate reference number used. Essentially any type of unique identifier, as long as it could be correlated back to the slate record, can be utilized for that purpose. So what I mean by that is if you use the sleep.

Graph ID or the slate ID for example, and you name those photos that number. When you write out the HTML, and there are examples of this in the knowledge base, you then are going to compare that to a query that's going to pull that ID number back and the query and the two can then be connected. So you can say this is IE 12345 dot JPEG that allows you to pull the image back as an HTML image just like anything else.

Both of those techniques though have the downside that they are open to the outside intervention. So now there are some ways to limit that. If you say, for example, or an institution that only allows people to use sleep within a VPN, then in theory you could put that inside your VPN and lock it down that way, which would be one way to increase the security on those photos.

There is a third method which I will talk about, which is totally different, and it's probably not sanctioned by technicians, but I think they know that people are doing it because I think I've even seen examples of it.

In some of their clean slate instances and that is called base 64 encoding.

So if you're not familiar with what base 64 is, it's and and and I don't pretend to be an expert on this, so forgive me if the technical people on the call catch an error to. I'll try not to leave any errors, but essentially what we're doing is we're taking a data file and I believe those are clobber blobs. What that really means I don't know, but that's typically how an image is stored that then is translated to an ASCII text base 64 texturing. And what you can do with that is you can store that base 64.

Upstream in slate. So what? In essence what you do is you can create a custom field, you could upload the photo and that base 64 ASCII format and then you can extract it and display it on the web page. So either the web page inside Slate or the web page on a portal. And I've actually done both methods using base 64. It really works well.

Here are the two big disadvantages with that method. Disadvantage one is you have to do the encoding, so if you're going one at a time, that's not too bad. And a usage case for that would be if a student uploads their photo as part of a new student intake process. That's a perfect use for that case, or a perfect use for that technology. The flip side of it is if you're uploading thousands of photos, you then need a base 64 encoder to do that encoding before it's uploaded into slate. The big advantage of that though is because it's text.

Can be uploaded slides, so you can push it in using a standard.

Source import. That just pulls the text into a custom field and you're good to go.

The other sort of.

Piece with that that is challenging is that, you know, Slate wasn't necessarily designed to work this way. You're in essence doing a decoding, and you're decoding large amounts of text.

You know, generally we don't see performance issues, but I did have one case where I worked with the client, they had a very advanced portal that required this base 64 decoding and it did slow it down a little bit. So you know, that's a case where you'd have to weigh the pros and cons of that. From a security standpoint, the base 64 is great because it really is connected. You know, you're only seeing it for the record you're looking at.

So that's great. You can't go and just extract all the base 64 images like you could in a directory. But the the downside of course are the are those encoding things and the fact that might slow your system down. So those are kind of the three methods we've seen generally deployed for this. Each have their advantages and disadvantages. I'm really hopeful someday tech solutions will put an enhancement in that will allow this to be kind of contained within the system in a standard format, but I don't think that's there yet. So that's I think that topic. Any questions?

About that, we've been talking a lot. Anybody have any questions that we can answer as we're going here? I see one about the is the Sony student success or the Swanee Student success instance separate from the admission instance? Do you want to answer that one, Julie?

Yeah, sure it is. They have two separate instances of sweet, one for admissions and then one that's entirely for student success that only holds current student data.

And, you know, I think this is a, you know, it's a topic in terms of things to think about when you do a student success installation. This is one of the big questions that come up. Can we do this in admissions or some cases in advancement? That's less common, but it's usually admissions. Usually you have the admission instance first and you're adding on to it and the answer is yes, you can absolutely put this in missions.

There are some. There's some upsides and downsides to both upsides and downsides to that approach, and then there's upsides and downsides to having a separate instance approach.

So to kind of parse those out, if you're a school that is very familiar with the admission instance, you're seasoned, you know how it works. It's a, if you want to start doing student success, it's a great way to get started. The classic example we see is a case where traditionally admissions ends at the point that a person is enrolled. And that could mean different things to different institutions. But generally it's the point where admissions recognizes them as done, they're going to come as a student and that's it. Usually admissions ends there. Again, differences at different institutions, but that.

That's typical. What schools will then do is go beyond that and they'll do this new student enrollment, or, I'm sorry, the new student process. And that can include things like it's typical for a student to have to fill out medical forms. It's typical for a new student to have to indicate class preferences or roommate preferences or housing preferences. It's typical for a student to have to do different types of trainings. So there are lots of cases where schools will put that functionality in a checklist or special portal.

They'll build it into the slate of mission instance and it all kind of works together seamlessly.

Then where it gets a little further is advising. So you might have a first year advisor that's part of that and they would then need to be considered. Now you might say that's great. Well why don't we just extend it further? Well that were you generally hit a wall is once you begin to go beyond those sort of new student things, now you're having potentially many different departments be in your slate instance, your admission instance. And if you have a particularly complex admission instance that can be very challenging from both a.

From the standpoint of a permission standpoint and also frankly from the standpoint of of, I want to use the word politics, but it's, it's sort of an ownership standpoint. So you have the admissions departments that classically were calling the shots in this instance and setting it up and defining parameters and who can get in and get out. And now you can no longer do that if you have a different office and there's student affairs office or maybe you have your athletics office who's using it for current student sport events, things like that.

So you have to decide is that going to work long term as you expand it out or does it make more sense to an essence break that off and make it its own thing and build it from the ground up for that purpose of having many different departments in it. And you know, in terms of what that looks like from permissions, like Julie, you want to comment on that a little bit. I think you've touched on that a little bit in your answers. You know how the permissions work with that kind of a scenario.

Yeah, so that's funny they have. There's the central office who's running the student success database is working with a variety of of different roles and they if they set up some pretty robust kind of roles that are connected to specialized permissions that control where different tabs are shown and where different sections of.

Of a record are shown and then what people can do obviously as well and and they're starting to walk down the road of working with realms to so that potentially or for example the people in charge of the premedical program can go in and send an e-mail through deliver to only the people who are registered as a pre Med student and can send messages about their.

About their program, just to the people who have opted into the pre Med program and that's done through realms and then some deliver templates in the query builder that are only kind of connected to those realms that allow that allow somebody in like managing the pre Med program to to send an e-mail within a few clicks.

But, but yeah, we do tend to work through the permissions in a student success implementation relatively early to understand the different constituencies that we'll be using slate, how they will be using it. Will they just be using a portal or will they have access to kind of the blue slightest side of slate, the administrative side of slate. And if they do, then what exactly do they need to see and what exactly do they should they have access to, to, to do. And we work and do quite a bit of testing on that to to make sure that we've got a good balance there.

Kind of building on that I guess. Tell the story about one client I worked with.

But I think actually there's a great question here about data flows. We'll definitely come back to that here in a moment.

Hmm.

You know, anticipating sort of permissions, I'm actually going to go back a slide. I think we have it on here. So sending communications to students, great, great usage case for student success instance. So here's the scenario. You have a central communication shop that wants to use slate to send student or send communications to current students on campus. Not prospective students, but current students.

In that scenario where it's one group doing that work, you know, permissions really aren't so much an issue. They have the ability to send, deliver, there's no realms, they just set up folders, just set of communications templates and it works very similar to how to admissions group would work use it or even an advancement group would use the communications tool. Where it gets more complicated is this scenario, and I have this with the client in real life where we were planning to do it. I don't know.

They they were definitely getting there. When I left the project, the idea was this, that there was going to be the Central communications group doing the sort of broadcast communications that everybody needs to know about, but they wanted to then take it and deploy it out to individual departments. So the scenario would be the biology department wants to send an e-mail to biology students or biology faculty or biology employees. So in that kind of a scenario, how do you do that in slate? And there are a couple ways to do it, but what I generally lean on is population based security.

Hmm.

So that's where you can really leverage a tool that was built for admissions originally and use it in a way where now you can say only the people in biology can only send emails to the biology students. And how you would do that is you would tie that record back to a custom field that would be fed in from an SSIS for a major or a program depending on if you're graduate or undergraduate.

And have a permission rule that would set the permission on a person level for that record. And now you're in business so you can say you can only include people who have that particular population permission if you have the corresponding permission on your user account. And now you have the capability to do emails and the the other key thing to this is there's a new query base and it's not that new, but the chemoth configurable joins it's population by person and population by application.

Hmm.

I see him that right. Those are the two bases. The amazing thing about those bases are if you give those to users they enforce the population based security. So if I'm in biology and joenes and economics, I can only access and query and send emails and that's the important thing here, send emails to students in biology. Angelina be able to do it for economics but not together. So you know this particular client, what we ended up doing was creating all the different population groups for the departments that needed this.

Capability. The permissions were set and then the idea was we would give those departments level folks the ability to access only that one query base so that. So worst case they can only send to their group by accident, not every group by accident. And that you know when you're learning to deliver, that's a risk that comes with delivery. You could end up sending an e-mail to the wrong groups. So by doing it that way it's a risk control, but it's also then become something that makes the queries easier. So in instead of having a bunch of different filters they had to work through the population could bake in things like.

Hmm.

We're going to only show biology students who are currently in an active status, meaning that they're enrolled and not on a leave of absence or not withdrawn. And only that group will be presented as a group that can be queryable and emailable or testable by the department level person. So that you know that's an example where if you leverage the tools in the way that you know, if you kind of know the tools and can leverage them, you can do this sort of deployed deliver system.

Yeah.

Many different departments, and there's nothing extra with slate. It's all built in. It's just using a tool that in the past really was using emissions for a particular usage case and expanding it to this sort of communications usage case.

Do you want to do you want me to take that the SAS question or do you want to take that one, Julie?

Well, while we're talking about communications maybe, I think this might be a good chance to talk about one other thing we've built before related to what? If you have a group of people that are using slate that you maybe don't want to give access to deliver for, maybe they maybe you don't even want to give them the option of trying to figure out.

How to use deliver? Or maybe the the group of people that they would need to e-mail for would be just untenable and creating a population for everybody in that group so I can share my screen one more time?

To share a form sort of situation that we set up for Swanee that is meant to be used by faculty members. So I'm going to bring up like a test faculty member here to kind of show you what the experience would look like.

Umm.

So what happens when I am impersonating someone or when a professor comes to use this form is I'm run through a series of asks of who do I want to send the e-mail to you and this using configurable joins and some and some liquid markup I'm able to say to to use the current user function to kind of say OK I know that doctor test is has two advisees, one is a carry fellow and one is a posse.

Dollar do I want to send an e-mail to all posse scholars or to all Kerry fellows and then I am able to write my e-mail? I've got some kind of error messages that pop up as well. If my test record was teaching a class, all of my classes would show up here and then I'd be asked to type in the CRN that matches the class. Once I type in my e-mail and my subject line, we would be using the registration confirmation functionality and forms to send this.

E-mail to every student who has a registration on their entity record that matches the CRM that the professor has typed in here. That would be through an independent subquery or the all of the Kerry fellows if I were to select Kerry Fellows.

On the student record who match that advisor type in their advisee entity should be another independent subquery. So in this case, you're using a forum to send an e-mail to everybody in a class or everybody who matches both being advised by myself and being and having a certain type of advisee that I'm, I'm responsible for that. You can send an e-mail to you without asking the professor to learn how to run this query or.

Build this query for them and deliver to send this e-mail and then all of these emails can stay in sleet and on the students record.

So that is another use case that's kind of a step 2.0 for sending messages to students.

And let's see, at least does this work for people who are double majoring? It could. It would depend on how you build that that query and how you're saving that information. But I think either if you're saving it in two separate fields or in like a A.

A program of study entity, you could get to a place where yes if if it was either a first meter or second meter and you wanted to send an e-mail to everybody who was an English major, it would catch both of those first and 2nd majors in there.

Uh, huh.

And kind of building on that from a permission standpoint, maybe you have a question also is formatted how does that, so if a person is double majoring, how does it work from a production standpoint? Well, the beauty of slate is you can have multiple populations on record. So I could be majoring in biology and economics, whether it's a double major or concentration or whatever. As long as you have a field and you have a rule that can point it at a population, that means I might have one or two or more populations associated with me, which then from what I was describing earlier, that would include the person in the population.

By person.

Hmm.

Query base as well as record access. So if you have the person in economics and biology they would be able to access both the same record that's double majored, we're double programmed and also be able to do the communications appropriately in both of those cases. So there's some really interesting possibilities for complex programs you think about like a rolling cohort situation where you have different cohorts, you could do different cohort based permissions. There's lots of creative things you can do with those population based security and you know I think for me the theme is.

Yep.

Anticipating this when you stand up the instance because it's harder in some ways to rebuild everything around this. If you have this in mind when you start, it can be easier. That's been my experience at least. I don't know about Jolene.

Yep.

Sir.

Can I go back and address the data feed question? So that is a little different topic. I love this one because it's a huge part of implementations with student success. So you know if you've done a traditional admission implementation or even advancement to some extent you're familiar with data feeds going into the system. I found with student success though it is very dependent on those data feeds. So I'll go back to the earlier example where we had a a client that was doing communications through their student success instance.

To make all of that work, they had to have a feed from their SIS that was updating constantly and by doing that then slate. I don't like the word shadow system because it implies a slate is somehow duplicating information that exists in the SSIS. I don't think that's really true, but what we're saying is in essence, the SSIS is the authoritative system for most of the records. So it's going to be the system that would know, is the student enrolled or not, what major are they in? What concentration do they have? Do they have a particular research?

Topic, if there are graduate student, do they have a particular advisor or committee member? Those kind of things would be stored in that s s and then ported to Slate and updated constantly. And then what you can do with that is you can then begin to build all the different communication tools, the portals, the logic around it. But those feeds are critical. So when you do these kind of implementations, you know one of the partners who generally are going to need and it and hopefully some of you are on the caller. This are those central IT folks who know how to create.

Feeds from the SIS system to slate. You may actually need feeds from slate back to the SIS system depending on what you're going to do. And I'll give a specific example of that. We work with a different client who was doing risk management associated with students leaving the institution and they had modeling system. And to make that modeling system work, we actually had to push the data in slate. So data was pushed into slate and then pushed out to a data warehouse that the modeling system that could pick up that information and do the modeling against.

So having that sort of skill set of doing the feeds back and forth was very important. The other thing I would say too is if you can go the route of API, that's in my mind the gold standard. Not every school has the technical acumen or the even the technology to support that. Flat files will work too, but API's are a great way to go and I have seen successful installations where with student success schools have been able to make those API's work where you're getting really very continuous feeds out of the SAS system.

I hope that answers the question though about the the SAS so and I think it was specific to the to the instance you showed Jolene. Can you speak to that?

Sure. Umm, so when when we set up Umm, so first, first swani, the the system feed is funneled through the traditional SFTP explorer process through sleet that's that's that's standard. And for most of the data in in the Swanee system, for almost all of it the the their s s is considered the the the the system.

Record and so every night things are pushed in from their SSIS system and then before that every night a retention policy runs to sort of refresh all of the fields or to to wipe all of the fields essentially before the RE upload in. That ensures that Umm for example if somebody goes from having a major to not having a major then the the field in sleep with that retention policy will go from.

English to empty instead of from English to staying English because it wasn't a new value wasn't uploaded into it. So you you do want to think carefully and and usually the data transfer processes is a really important kind of first step in setting up a student success instance. Especially if you're going to use the SI system as a student as a as a system of record for the majority of the data that you're going to have in the system.

Yeah.

I think there was a question about did we answer the question about the what happened when you submit the form that you showed earlier?

Yeah, So what happens when you submit the form is there is an e-mail attached to the form just like you would attach a registration confirmation e-mail. I think it is technically a registration confirmation e-mail. We're just souping it up a little bit so that the recipient e-mail isn't the form submitter. It becomes the all of the emails that are the result of.

The SUBQUERY or the independent Subquery that matches on that cierra number that matches on the advisor matching the advisor type on the student record, and all of those are kind of populated into the recipient list and the e-mail goes out.

Yeah.

And I'll add to that too, I actually have a a project I'm currently working on or it's it's live but it's still being refined. We're we're doing a similar process. The form is being submitted through the portal and that form is actually the communications are sending out, it's a student alert system. So it's actually sending alerts to different community members based upon submission of that form. So that's kind of a different variation of that the person submitting the.

Here's a different way to say it. The person or the community member actually submitting the alert doesn't even know they're sending emails by virtue of them having that sort of wired up on the back end that those alerts are going out to the world in, you know, essentially real time. Which is pretty nice way to use the the slate message tool with form submission. I think it's the only thing left that does real time. There used to be an option under deliver where you could do frequent notifications. I think that.

Disappeared a while back, but I think it's it, and so it's a great way. If you need that real time communication for a particular event, doing a form submission for it is great.

Other questions?

We can tell you stories about all the cool things we've done if you want that. That could be a topic here.

Why? I don't know. I I will say this, when I started in in this job, I had under my belt a couple of sort of student success things. But it's amazing the variety of things that people want to do with this system. And what we found in general is there are ways to do it in sleep.

You know, I I find sometimes that this whole topic is a little intimidating because how do you even start? And if I were going to give any advice around that, first of all, have some individual, ideally a group of individuals, be willing to own it forever. The lack of a better term. You need vision for this because you're typically not going to be able to do everything you want at the very beginning. So you need to have an ability to kind of say, here are the current goal and the things we want to do in the future.

How do we set up this installation in this instance to be able to do those things and then build toward those other, those other utilizations we've seen everywhere from very simple usages of slate? Very, very.

You know, small things that are important to the institution, but they're essentially one thing that might be communications, that might be advising all the way to schools that are really almost using it like an SSIS. So it's really replacing the s s functionality and it's all in a current student database. And you know, to me the thing that really makes that work is when entities came along that really opened the ability of slate to build the store many, many different types of information in ways that it couldn't do before that.

I don't know, Julie, do you have any sage advice around the like what have we learned in terms of the doing this a couple of Times Now?

Um.

Not in general. I mean, I think we're starting to get some really good questions. I think there were there was a question about maybe showing some portals which we can do.

So maybe we can just.

I think I have one portal that I can show you and then we can open it up to the other questions that we have.

Umm.

Show the portals. The port. Yeah, there we go.

Sure. So we've talked a little bit about portals that kind of have some functionality for other constituents on campus. So this is an example of a faculty portal and this portal will show kind of tabs based on. These are all of the people in that you advise in different capacities. If I was teach or if my test record here was teaching a class, you would have a tab as well for all of the classes that you're teaching, you have that link to that e-mail students.

Form that I just showed Umm just a minute ago, as well as some other helpful links and training and that sort of thing. When you click on a name, the student account shows up. So through a portal you can really control even more specifically exactly what you want a constituent to see. So this can be really useful for a faculty member, or even for groups of of people on campus, like maybe an athletic coach or a parent who should really only see really specific information about a specific student. You can really do that.

There in a portal really, really well without risking giving them all access to to all of blue slate. On the administrative side, some sort of Nice features that we integrated in is when you click on this e-mail here, it doesn't open up an outlook window for you, but it actually opens up a sleek e-mail just in the way that you would click on an e-mail on a student record. So the e-mail that you send in has access to all of the snippets that have been shared with you, but it also has.

It also keeps the e-mail on the student record so you can see in the timeline when a professor, when a staff member emailed the student, even when they emailed them through the portal. Here links to different forms and things are happening. And it's overall just a really good way to show exactly the students that you're responsible for. For example, without having to give somebody access to all of sleet on the blue slide and control what they see either through populations or through a more an even more robust and complicated.

Population permission setup so that can be useful. A useful example of a portal that we've built, although we have built quite a few portals for various different kind of reasons in student success influence in instances. Sawani also has a student portal for example that will allow that allow students to book appointments with their career coaches or with their student success coaches. It allows them to select any pre professional programs that they want.

You have to opt into like that premed program.

And then it allows them to book appointments with those and shows their appointments through a schedule or set up that we that we configured for them. So it shows like upcoming appointments with career coaches that they have booked over the next few weeks.

So some really quick examples of portals that we built in the past.

Any other questions that have come through on the chat?

Can I take that entities versus round period one?

Yeah, do it. Go for it.

Yeah. Am I echoing? By the way, I know there's a little bit of echoing for Joanne. Am I echoing OK?

So I'm going to actually expand this a little bit because the other one that comes with this is what's the difference between an entity and a data set?

So let's just go through each one of those things and we can talk through. So rounds and periods really are related to the application records and slate, and if you're an advancement user, you may not have ever seen this. So this is primarily for the admission folk on the call.

They really are baked into slate and the idea is in essence is it would relate to a early decision, regular decision transfer. You know that those are classically the way they are used. There are other ways to do it, particularly for graduate schools, but generally you have around per period that you're reading an application for.

That said, it is a one to many relationship, meaning that a person could potentially apply many times, but they only have one person record. An entity on the other hand is A1 to many relationship that can really be anything. So you know, Jolene for example showed an example where you saw a list of courses for the student. That's an entity. So what we're saying to slate in essence, here's a person record over here and in this entity give me every course that exists for that student.

And you can do that really for any type of concept. So you could have courses you could have.

I'm trying to think of a good examples and one example I worked with. We replicated the billing system from banner. If you know a banner is SAS system. We brought that information in, we're able to show it and slate in a way that created that information, but did it in a way that was less complex than how it exists in the SAS and Bing.

Other examples would be you could have you know this is typically going to be the case with like faculty. You could have a faculty member in a in a data set and then have all the courses that are teaching. So entities can exist not only in person records, they can exist on application records and on data set records. So they kind of give you that ability to have a one to many relationship however you want. There's no really limitations with that, it's really powerful. What about data set records? What's what? What are they? Aren't they many records? Well data set records?

I think of that as a sort of bundle of its own information. So in mostly installations for admissions, you you start with an organizational data set and an organizational contact data set, and there is a relationship between those two things. There's a parent child relationship, but those relate back to a person record.

In an advancement instance, you would have a funds data set or a you might have a data set associated with different organizations that are not the typical organizational data set.

Again, data sets. So you have a record for each one of those things and you can relate them back to a person record or other things in the system.

Entities are kind of like that, but not really the same, because an entity typically is going to have less information and the only place that record exists is inside that entity record. It doesn't exist independent from that. Now here's the thing that's interesting about this. You can actually connect an entity to a data set record.

Great example for advancement if there's any advancement people on here, you could have a list of people who have evaluated a constituent, and you could then link that back to a staff member contained in the data.

Or you could link it back to an organization contained in the data set, so you can sort of mix and match these things together. But the basic idea is entities are the most, in my opinion, the most flexible. I should say that they're incredibly flexible. Data sets are also flexible, but they serve a different purpose. I hope that answered the question about the differences.

Yeah. And if I can just jump in for like rounds and periods for a student success implementation, I think there's a use case for them. For example, if you're looking to implement some financial aid into your student success instance, maybe with a student portal that shows a financially checklist every year. That checklist needs to be refreshed every year and and the students need to go through the process every year. So when you, when you start talking about every year that a student is enrolled, they have.

Like fill in a returning form or fill in a housing form every year or whatever they have to do. That's a good use case for when you would need to use application rounds and periods and kind of tweak them in a way to your own needs that would that would that would utilize that system. But if you.

Don't need any of that functionality. That's going to require some like year on year stuff. Um, then you don't necessarily need to use the applications or the periods and rounds at all. So it really is kind of like exactly what you're hoping to use. Umm, and and get out of the sleep kind of module there for whether you would need to to implement some some periods and rounds, but not necessarily depending on the information that you're hoping to use or the information that you're hoping to collect from students.

Hmm.

I'll throw one other thing in here that you may want to look at. There's a part of slate that's newer called Research which has been classically used for advancement. So it literally research that an advancement group might want to do with an individual to see wealth capability, they maybe get information from an outside services.

The big difference between entities and that is that.

There can be security on individual row level records inside that research. Whereas with an entity generally if you have access to the entity you have access to all the different records in that entity. There is a way to work around them. You can have different entities and it depends on whether the user can query or not. If they can query then you can break the information into separate entities. So you could have a group of entities storing information for Group A and group of entities storing information for Group B and then you can lock down the permissions so they can.

Query the group, but if the users don't need to query, you can actually do a really interesting thing. Entities can store the information, but you can display it differently on different tabs. The best example I can think of that is I worked with a client where we were storing course information and they wanted to see courses that the students currently taking, courses they took in the past, and courses they're enrolled in the future. And how you did that is we did off 1 entity but using filters on the view for that entity on the tab and then replicating it three times.

And why you might say how does that work with permissions? Well you can do that. You can put them on different tab and have filters based upon who is the current user. Can they see that view of the entity?

So there's some ability to impose security as long as the individual doesn't have to query the record, whereas with research securities kind of baked in, I don't see research use as much. Frankly, I think there's potential there, but I think it's a part of slate that's still evolving in terms of usage cases.

Let's see question we have about.

About 6 minutes left from a time check perspective we have a question about.

Terms and communications.

So I'm considering entities for a term and continuing to do that. OK, so this looks like a course thing. If it does not exist outside the entity, can I query it for communications?

I mean as long as that data point exists somewhere in the system, I think the answer is yes. The the question for me would be though, are you trying to connect that to an entity record? Then then you probably wouldn't want to do it that way. You probably want to put it into the entity somehow so you could do sort of row level access of that entity. I don't know if that's answered the question well, I hope so.

Any other questions, we'd be happy to talk to you about different things. This is a very broad topic, so it's potentially could be anything, which is kind of fun.

I will say this, that one of the other challenges with student success is that really when you start, you are given a blank box. You know you're giving a world that you can build inside of. This will resonate with some of you. Some of you won't. I I think of the game Minecraft where you start with an open world. You're given the tools, and now you go out and build something. And depending on if you're good or not at it, you can have a Hut at the end of the day, or you can have a castle. And I think that's where knowing as much about Slate as you can when you endeavor on that student success journey is critical.

So being able to understand what are the features that you can do? What's the difference between an entity and a data set record? So your best place at an institution is usually going to be your your people that have slate already. So bring them in, you know?

Is a former HR person. Secondary pay is a wonderful thing. You can do project level pay so you can bring that expertise in and use it inside of for that project. And if you're an IT practitioner that is a that is a huge thing. So having the expertise already baked into the organization could really make the difference between having something that never really reaches its potential to having something that really is amazing.

Do we have any client success stories? I hope so.

Let me see what's a good one.

What would be a good one to tell? Well, I would say I think the example.

I worked with the client that was doing risk retention. So their, their goal was to see you know, is there a correlation between retention and certain things that happen. And it's still to be determined whether that is pushing the needle at their institution, but they have the system that they can see the data. So but that by itself I think would be a success. The other thing I think that they have is they have the ability to communicate pretty effortlessly with current students. So I would call that a success.

I think another thing I might point to is.

Faculty related things. So I sort of a variation of something Jolene brought up way back. I did a project where we wanted to do faculty communications and we want, but we wanted to have that information inside of Slate but somewhat control it in that we wanted to come out a certain way, look a certain way. And by using the technique Jolene showed earlier, we were able to accomplish that. So I would call that a success. I mean do you have anything that kind of comes off the top, your wing is something you might highlight.

I think, I think we've developed like on the portal side. We've developed quite a few portals that just allow like groups of groups of constituencies on campus to to just really easily see the students that they should have their eye on and see the information that they need to see and communicate with those students really effectively and fluidly.

That always feels like a win to me because because it's just helping people do their job more effectively and and helping people connect with their students more easily, which is always nice.

Always a nice result.

I mean, I would say this going back to a different client and I mentioned this earlier, the ability to see bills. So one of the things they wanted to be able to do was have.

They went, they went in to have the ability for a counselor to be able to see, you know, is there a bill that's due for the student and what is causing pressure on their ability to attend the institution. Now, you might decide that your institution, that's too much information to give and that's a totally reasonable response, but you might also decide that's really helpful information for certain people to be able to have. So one of the things that Slate solved was, in the past, getting that information, even if it was accessible for the person, required special training, special access to the SSIS. You had to give the logging.

To be able to navigate it, that could be complex.

With Slate, it literally is on tab and it's there. They can see the entire history. It's there. They can see whether the student has an outstanding balance or not. It's there. It's readable by human being with no training. So I would call that a success. And that's something that you can do with sleep, student success, which is really powerful in that you can use as a tool to summarize complex information from many different places. So if you're again that central IT person saying, how do I get somebody to be able to see information from this system, this system, this system, this system?

We'll slide can be the answer for that. So you build data feeds into slate, you summarize it, you put it into nice tabs and views. And now you have a system where it's very easy for a novice user to quickly pull up the information, see updated information that corresponds to the to the SAS system, but not have to do all that extra training. And it's locked down too, so they can't accidentally change something. So I, you know, I think we've seen a couple versions of that in the installations we've done and that's been huge for institutions.

Yeah.

Um.

To.

I think we're out of time or.

We can continue to answer questions if you like.

Yeah.

I can stick around a little longer. People want to hang out, although I don't think it shuts off automatically. We haven't been cut off yet, so that's good.

Uh.

OK.

Do you want to take the you want to take the one about the what's the major benefits of choosing Slate question.

Yeah, I think firstly for student success, it's it really is kind of AU designer and you build out, which can both feel really intimidating at the beginning, but it is.

It is a way for you to get exactly what you need out of, out of the system in the way that you build it. So you're really given the opportunity to kind of evaluate your needs and what you want out of it and then build it in a way that that looks and feels like what you, what you what you need out of out of the system. So you're able to show dashboards and landing pages about students in the way that you exactly want to see it. You're not given like a template, and you have to fit everything that you need in in that into that.

Specific structure that may or may not be be perfect for you and for your school. I think that is one of the benefits of sleep for student success. I think sleep is such a widely used product on the admissions side that a lot of institutions also have very savvy users that are very that can be very useful resources for building out a completely new database and making it look and feel really exciting when to once it's all done.

Shout out to Melissa from Concordia Saint Paul. Hi, Melissa.

So the let me see here.

Going to the question, oh, I love the question about should you use entities versus rounds.

That's a our application. That is a great question. It has many nuances and I think there are different schools of thought about it. So I will get back to that I promise. And and only if you really want to go down the rabbit hole stick around for that bit. But the you know I want to answer the one about the SAS to sleep.

That's a great question too, because to make slate nearer all these different feeds, you really do need to think about how are you going to deal with the idea of deltas or records being updated or keeping it constantly updated. And that has actually been a little bit of a challenge with it. We do have solutions for it and we have ways you can do it, and I'll kind of give you the two ways to do it.

So one way is you can have a method where you are importing the information on a nightly basis and you're matching on guids that correspond either to the person record. If you're dealing with personal data, that's pretty straightforward and Slate has the ability to store an external ID. So the classic way to deal with that is you have your SSID and you have your state ID and you have a feed that pushes that that SSID into Slate and now the two systems can communicate seamlessly. No issues. You only have to deal with it one time really on the push in.

So that you that can be handled even in admissions, depending on how your admission process works.

The other sort of challenge is how do you deal with sort of row level data. So the idea of I have an entity record, I'll use the course example again. So I have five courses for this student and the name of the course updates or the professor that's teaching it updates. How do you deal with that? Well, one method is you use a external ID in that record and then as long as you can get that external ID from the SAS it will just match it up to it. There is one big pickup of that though. You can't currently delete. I don't believe there's a way to delete.

Records using an upload in entities. So when you're in the world that you have to, I think, handle it one of two ways. So one method is you have a record on the entity that indicates whether that record is active or inactive. If it's active then you show it. If it's inactive, you can hide it from the filter view and then the end user doesn't see it. So still in the system but they can't access it. Then you have to deal with it from a query standpoint, but it's not terrible.

The other method to deal with it is you use retention rules and you run those on a regular basis. So I've had some clients do this and they do it very successfully. They run the retention rule, so usually it's about 4:00 AM. They run the retention rule, they wipe the data set up or not the data set, but the entity out for everybody, and then they reload it. So essentially for a window of time that particular record doesn't exist in the system and then it's uploaded again. So you're constantly refreshing the system. The big downside of that is at least right now, today.

Let's technicians comes out with this on this meeting. You can't say when you want that refresh to run, so you only say I want it to run on the day and when that happens it's going to be slightly different depending on which instance you're in. That would be one of my enhancement requests. But the one I really want if you're listening technicians, is I want the ability for when you upload a data set to have that retention rule run as part of that data set upload. There's an enhancement request out there for covette for it. It's something that would be hugely helpful to students success installations.

The so that's, you know, using retention rules. Timing it is one way to do it. And there's a hybrid of those two approaches. So the hybrid is this, you upload the record, you mark the record as inactive, and then you don't have that retention rule remove it before the next upload, but you have to do it after the fact. So in other words, you might have 5 inactive records on a person's five inactive courses on a on a person's record you want to remove, you have the upload from the SAS, mark them as inactive and then subsequently you have the data.

Retention policy come back at some later date and remove them from the system. So it's on a delay, but it works just as well. That's those are the kind of three flavors of those I've seen for entities.

But yeah, with external ID's they serve the same purpose. I would pick what exists in the SSIS so you can use it in slate, ideally without having to feed it into slate if you can make it work.

Ah.

Thank you everyone.

Thank you very much. I think Christine is.

No, thank you.

Yeah. OK. Excellent. Thank you for attending. Take care.

Right.