Dive Deeper with Axiom Elite: Slate & Student System Integration with Axiom Elite

Hello everyone, welcome to the dive deeper series. We'll get started in just a moment, but feel free to introduce yourselves in the chat. Let us know where you're joining from and I don't know how the weather is on your side of the country today.

We will get started in just a moment, but feel free to say hello in the chat in the meantime.

And we'll just give it another 20 seconds or so, still see a couple of folks jumping on in.

Alright, perfect. Thanks Connor. So as I get started here, feel free to respond to Connor's poll about which sisu currently is. But yeah, my name is Chris Gonzalez and I'm here at the technicians Portland office. Welcome to the dive deeper webinar series. Today we are talking about slate and student system integrations with Axiom. We are joined by.

Connor from Axiom, Mark from Saint Lawrence, and Jeff from Stonehill. Before we get started, I'm gonna go over a couple of housekeeping tips. You've probably heard these before.

Through other webinars are posted, this webinar is being recorded and will be made available for viewing. So if the content is good and you want to share it with your coworkers, feel free to do that. Don't feel like you need to write down everything they're recording is there along with all the slides. If you'd like close captioning, there is an icon at the upper right. You can click on that and it'll become available.

Full screen viewing can be enabled close by to that icon. Just two icons to the right of that so you can view it in full screen.

Um, if you want to get rid of the chat, there's also an icon for that, just in case you want to, like, focus on the slides specifically. Should anything go wrong, say a slide seems to be frozen or our audio or video goes off, just reset your browser. It doesn't kick you out at the meeting, you'll be back in viewing things where you left off. It should be good. Any questions you have, just go ahead and post them in the chat. We've got a team of folks who will be responding to it. And yeah, without further ado, let's get started.

Hey, everybody. My name's Connor Lloyd and I'm from axiom. Today we're going to be going over our presentation from some of our customers. We're going to be starting with Jeff Smith. He's from stonehill. He's going to be going over his Slaton banner experience. Then we're going to be going over to Mark Fallon from Saint Lawrence University. He's going to be touching on his Slaton colleague experience in the chat. We do also have Nicole Armajani, Amanda Michaels and.

At least from the axiom side. So if you have any questions, please feel free to pop them into the chat and we'll go through them again at the end.

For the agenda and like I just said, we are going to be starting with Stone Hill, their experience with Jeff and then move over to Mark and Saint Lawrence's experience.

All right, Jeff.

Hey, thank you, Connor, and welcome, everybody. I'm going to start just with a quick introduction to Stonehill College. If you're not familiar with Stonehill, we're here in Easton, MA. We are a private Catholic coeducational college. We're founded in 1948 by the Congregation of Holy Cross.

We're primarily undergraduate right around 2500 undergraduate students and we have three graduate programs that were introduced around six years ago and and that part of our college is growing seemingly every year. We recently made a transition to NCAA Division One athletics. This is our first year participating in the New England Conference, the NEC.

And my my role at the college is in the enrollment management division and specifically I work most specifically with undergraduate admission. I do work with our graduate admission team. I work with our athletics department and our financial aid Office on special projects that incorporate enrollment management data. In January, I will have been at the College in for 12 years. I started in marketing.

Um running content for the college's website um and moved into this position associate Dean of admission and director of Rural Management systems about six years ago.

So my background is primarily in marketing and communications, not a traditional admission background. I've never been in Mission counselor. I've never traveled or or read applications myself. And I'm also not a traditional, I wouldn't say a traditional information technology professional. Again more coming from that marketing and communications background. So I'm going to talk to you next a little bit about how we use Slate at Stonehill and then I'll move into the way our ecology.

This banner, UM and and then into how axiom kind of ties that all together for us. I'll share some keys to success that we the success of our slate implementation and a little bit about what's next for us for us at Stonehill and then I'm happy to answer any questions that you might have about any of that.

Alright. So um at Stonehill Slate is the system of record for the enrollment management division.

And that means everything from the search campaign stage, so purchase prospects through inquiries, application data.

Reader data, event registrations, decision release, any type of payment that we're receiving as a student is enrolling at the college. We do use slate payments. We brought search in-house approximately 2 years ago.

We do all of our travel out of slate. We have portals for applicants for admitted students. We also have portals for coaches in our athletics department.

Essentially, all of our business processes and enrollment management at Stonehill are conducted in slate. And if we don't have a record of something in slate, it's almost as if it didn't happen.

And we do use slate, as I said, for just about everything that we do. Our implementation started in May of 2018, ahead of our fall 2019 recruitment cycle, and we were up and running with everything from event registration to communications application reading by the end of the year. We were releasing decisions just before Christmas.

In 2018, so again started in May and we were releasing decisions out of slate by December. We are a common app school, so that was part of our implementation as well where we initially or prior to Slate brought common app data directly into banner.

We we pivoted when we when we implemented slate, we pivoted to bringing common app data into slate and manipulating it there. It's also slate is also the system where we collect all admission documentation, transcripts, letters of recommendation, school reports, everything like that.

So on the other side of the house we have, we have banner and banner is the system of record for essentially every other division at the college. And as it pertains to this presentation most specifically our academic affairs division, student affairs, finance, advancement, development use banner as their system of record. And so one thing that that that's very was very important for us during our implementation of slate was figuring out how to write the data.

That the rest of our campus needs how to, how to take it from Slate and incorporate it into banner again, prior to Slate, we were importing common app data directly into banner and all of our reader forms and checklists and all of that process was built using banner tools or homegrown tools. And so pivoting the slate was a big moment for us in that we were essentially taking all of the data pertaining to admission out of that.

Environment, rebuilding those processes and workflows and slate and then needing to figure out, OK, how do we then take the data that other folks on our campus rely upon and make sure that it gets into banner so that so that they can use it. And this is talking about everything from financial aid, packaging to eventually student record creation, registering for courses, student accounts, data for institutional research, as well as alumni.

Bears and advancement reaching out to to whether it's graduates or their families again all of our all of our financial aid packaging occurs in banner. So that was that was a big part of of our project was that question mark around.

Taking that, taking that data out of banner.

Putting it in Slate 1st and then how do we get what we want back into banner and the answer to that?

Was axiom. Um, so wasn't his axiom. So we use Axiom for two way data integration between Slate and banner.

Um.

Most of the data that we're sending does go from Slate to banner. There are a select few data points that we bring back from banner. This includes everything from a person record in banner to the application record, curriculum data, addresses, application supplemental data, ratings, attributes, school information. We are test blind, but we weren't at the at the outset of our implementation so we do have a data feed for test scores.

Which we no longer collect. So that's gone quiet, um as I mentioned where we collect payments for enrollment deposits through slate payments. So we also have a data feed from site to banner for that payment information.

The way it works for us is we have a distinct data feeds for undergraduate data, for graduate data, and then also for athletic preread data, and we have a slate query that's tailored to each distinct feed I think we're up to.

Some quick math here. I think we're up to about 25 feeds at this point, with a query in slate that corresponds to each feed.

One of the biggest things that Axiom does for us is looks into our banner database and tries to match on an existing record because so much of our business processes happen in slate. First and foremost, we found that once we got away from our initial implementation, I mean reset here, so we had fall 2019 recruitment data. That cycle started in banner and then we implemented slate. So there was existing data in in banner for the fall 2019 recruitment cycle.

And a little bit beyond even some fall 2020 data was in banner already. So when we first implemented Axiom we were we were using it a lot to match application data that was coming into slate with existing records and banner over the last couple years where essentially none of that data exists in in banner anymore, or at least not until the point of application. We found a lot fewer matches in our banner database and and Axiom is essentially.

Establishing new records much more frequently than it is matching on existing records, at least at that initial record creation point. We also use Axiom to keep up with data changes in slate. So as decision codes change, as addresses change, as various application attributes, chains, curriculum, data majors, minors, things like that. As that information is changing, we use Axiom to overwrite data in banner.

As appropriate.

We have our feeds running approximately once a day. Um, and that's everything from creating initial records, updating addresses, to putting new decision codes in what we do.

Game Axiom a little bit and and there are certain times of year decision release May 1st we where we turn up the frequency of a particular data feed, maybe it's the decision code or the payment feed in order to keep banners up to date as close to real time as possible. But generally throughout the year we find that pretty much we're having sources or data right into banner once a day and and that's pretty much sufficient for our for our needs.

Alright, so I'll just I'll talk about a few keys to success for our slate implementation and axiom implementation as well. We're extremely pleased with the product. It's really both products really have revolutionized the way we do business and enrollment management. Upon my arrival in the office of admission, we had a six or seven person operations team that was spending most of their time trying to keep data up-to-date among 3456 different.

Systems, we had a system that collected event registrations. We had a system that sent emails. We had a system that collected admission application data and documentation. We had a system to read those applications. We had a system to release decisions. We had a system to collect payments. And and those were all different systems. And so a lot of our time was spent making sure that data that was in one system was accurate according and in alignment with data.

Was in another system.

Um, we've pretty much done away with with all of that by moving most of our business processes into slate. And so the piece that the piece that we need to make sure is in place again is having that data flow from slate into banner, making sure that's accurate. And Axiom has essentially taken over that work from from our operations team. So we are spending more of our time on innovation on communications.

On improving processes, on improving the experience for prospective students, um, we've seen an uptick in applications every year since we since we had slate and our enrollment numbers are this year was a record, a record class for us so.

Again, really taking that time away from making sure that data is accurate and instead investing in more and more fun and productive things. So some of the keys to our success were to do your research right and particularly when we're talking about syncing data from slide into banner, find out what your campus partners really need.

At least for us we don't in in in admission and enrollment management. We don't spend a lot of time in banner anymore at least on a day-to-day basis. And so sending data into banners is really for the benefit of our campus partners. And so doing research meeting, meeting with those folks and your registrar's office and your financial aid office and your finance division or your your bursar's office whatever that might be your your billing function to find out the data points that they really need that that they report on.

And and focusing your your axiom feeds and your axiom project on that data. I will say that Axiom has a lot of really great sources right out-of-the-box. They know what they're doing. They've done a lot of banner implementations slate to banner implementations and so right out-of-the-box they're gonna be able to tell you kind of the core of what you need to be sending and then it's it's just finding out, figuring out the details. The next key for us was investing in our slate queries. We used a lot of export values calculations.

Translations really with the goal in mind to be sending Banner ready data from Slate into Axiom and not asking Axiom to perform a lot of translations or conversions of data.

From from Slate into banner acceptable values we we do a lot of that or almost all of that insulate we try to make good decisions on our query filters and sending data when it's been updated there's a lot of time stamping on fields and slate. So we're able to really hone in our our queries to say you know only send this this data into Axiom if it's changed in slate or if it's new in slate and and one of the key for us it just kind of.

As a public relations tool was to know our imports schedules, our campus partners really want to know how often our data is being updated in banner, how reliable it might be, and when they can essentially run their own business processes or the best times to do that. So knowing your import schedules, knowing when when data is formed from one system to the other was that was a really important thing for us.

So just a little bit about what's next at Stonehill and then I'll hand off to Mark. We do have a new institutional financial aid application this year developed in Slate. It's part of our applicant checklist. We used to be a CSS profile school and we've moved into this new institutional financial aid application. We have a new athletic pre read process which consists of a request form for coaches review environment for admission.

In the portal for the assignment of athletic related aid. That project came about as a result of our move to Division One athletics and we're considering a few next steps. We're looking at Slate for advancement or advancement. Team is aware of the success that we've had with Slate in enrollment management and they are considering a new CRM. They may actually have already signed on with slate for advancement and also branching out into student success, we've pushed our instance of slate.

Further and further into the onboarding experience for new students, so we host or we have orientation registration forms and slate, we have placement exams and slate we have information confirmation forms that kind of fill that that gap between the enrollment deposit and actually registering for classes and and arriving on campus. And so we're pushing Slate further and further into the into the student experience and the current student experience and and right now that that consists mostly of.

Of the onboarding process. But again, we've had a lot of really great success there. And our campus partners in student affairs and in academic affairs are taking note of that and considering what it might look like for us to implement more of the student experience.

Using slate. And with that, I'm going to take a backseat and hand off to Mark Falen at Saint Lawrence and look forward to your questions.

Thanks so much, Jeff.

Hello, everybody. So for this part of the segment, it's going to be talking primarily about Slate and colleague and it's really going to be a quick overview about Saint Lawrence. And then we're going to jump right into why Axiom. We're going to give you some tidbits on why we went that path. So just a little bit about Saint Lawrence. So we're founded in 1856 private lower arts, 2200 undergraduate students. We have a really small graduate population.

Uh, we're Topper upper part of New York State. Um, almost Canada. It is 41 degrees here right now. Um should come visit us sometime in January. And we have 35 athletic teams on Division One hockey.

Any part through this conversation, feel free to, as you're doing now, put things in the chat and we'll get to them. Either during this or right after, we'll have some questions.

I'm about me. Just look real quick. Um, I've been at Saint Lawrence 16 years. I was in it. I went to admissions. Actually, this slide is now outdated. Now I'm back in it. I'll talk about that a little bit later.

Um, but I really want to jump right in and talk about Axiom with you.

So the Y axiom.

We recently went from colleague on premise to hosting colleague in the cloud and when we did that our current setup for getting data from Slate to colleague had to change. We were using a process called ELF. We had another SQL database tied into it. Long story short, we had to find a different product to get to the cloud because the setup was not supported. We looked at a couple of different vendors, actually being one of them.

We honestly went with Axiom and here's some tidbits on why, uh, so cost is comparable, but ultimately we're looking at Axiom they, they seem to have more market, more people in the marketplace that have already started when them and used them. In addition to that, we were looking at expanding beyond this initial admissions to colleague feed. So we'll talk about that in a minute too, but really they.

They had a good hold in the market and we wanted to utilize them as best we could.

Um.

I wanna, as we talk about action, I want to dig in a little bit on what you should expect right out-of-the-box. So with Axiom, thinking about integration with colleague, they're going to give you some templates that are going to help you out tremendously to get you going. They've been through this before. So just to kind of overview this with you, you're going to get a template for person and application data, address and decisions. Those are the first three that you'll probably get set up.

And put on a frequent schedule every every morning, whatever that turns into. In addition to that, there's also templates for schools and relationship data that will pass over. We do that once a kid has deposited, we pass the extra data to colleague, they don't need it beforehand, and we passed on test scores and payments.

Um, so wanted to let you know generally how that's set up for us. Each one of those pieces is a slate slate query that exports data to axiom.

Try to make this as smart as we could. So like Jeff mentioned.

We put majority of them a logic in the slate query. So if we need to change a field, we actually just did last week, we make that change in slate, we test it, we verify it, and we can just pass it to X and just as a pass through. So very little logic ended up being an axiom, and they're totally fine with that. They understand we want to make it easier for all the clients to use them.

And that's worked out very well. So I would very much encourage you to continue that. Put as much logic as you can.

On this late side for you.

In addition to that kind of what Jeff mentioned too, we started off with pushing data to Kylie just once a day.

Um, it turned out with that, that wasn't frequently enough on the data goes to colleague, primarily for financial aid to package student and get their decisions ready.

Um. And so.

We talked to the financial aid group. They wanted it twice a day in 10 seconds. We were pushing it twice a day. It's just a matter of how frequently you push it out of slate. It's how much you know, how fast it goes to colleague.

I see the questions rolling in, so please keep them going.

Um, in addition to all this. So I want to describe how axioms be done. Complete total package for us. So we're pushing data to Axiom, which then goes to colleague with it. It's all automatic. I think automation is key in everyone's institution. In addition to that, we get some data back into slate that we care about, like the colleague ID for each person we Passover, that's automatically brought back and then duplicates when we pass a person over. Axiom will.

Look for potential duplicates in colleague and alert us to them. Actually, they send us an e-mail saying hey Mark, you got 3 duplicates out of the people you push today. So we'll go in, we'll look at that and see if it is a duplicate or if it isn't, and there's criteria that's set up to determine if a person really is or isn't a duplicate and then they're pushed through.

On top of all that, from the slate side, we push all changes in the last 24 hours each day. When we do that, it isn't a whole ton of data going to colleague. Axiom is smart being in the middle, it only passes the changes, only passes the deltas.

Over to colleagues, that's a big help. On the colleague side, they only get the changes they need. On the slate side, I don't have to write some complex stuff to only pass over if an address changed. I'll pass over gently wholesale person related data if it's changed in the last 24 hours and axiom will take care of the middle.

So talking about the future with Axiom, So what else we have? We've had slate for five years. We've had also student success for a couple of years.

With student success, we have one of the we have like every student forum outside of colleague is in slate. So we have a lot of opportunities where we have data insight that sometimes we need to get that back to colleague. I want to run through an example with you.

So the example is we have.

In the student version of Slate, we have faculty. All of our faculty use the slate reader.

Um, for advisor, minor and major updates. So for example, if a student goes and adds a major biology, it might have to get routed through a couple different people through approvals. And once it is approved, ultimately that change biology needs to be added to that person at that last step in the workflow. That's a human right now going in and making that update into college.

From talking to Connor and the whole Axiom team, we're looking to as well as soon as we can here, look a little deeper at that and see what we can do to make that an automatic feed into colleague.

So that would be a huge win for us, save quite a bit of time and less room for error as we can do it through the advisor major and minor updates. So when I just want to mention that axiom is very willing to explore those new boundaries with us and that's what really got us excited and really tipped the scale on why we went with Axiom. The least talked to us, we'll go through and review with us. It might not be something they've done before and it might, might be as well. Ultimately they're willing to go.

Through and have those conversations to think about these things. Another example that's coming up for us soon is on the HR side. So very similar on the last screen where we talked about passing over student data.

Uh, we're considering using slate to gather a person applies for a job. We get that information. Ultimately, they accept the job. They come here, they work at Saint Lawrence. We need to get their personal demographic data into colleagues. We can use Slate to collect it all, use axiom to push it over into colleague, and that's a huge win for us. That's all. It's a very manual process for us right now that we're looking to improve upon.

So with that, I hope when we get a bunch more questions, I'm starting to look at the chat and I'm going to jump to questions next.

Uh, let me navigate to the next slide and.

So Connor and Jeff, if you're able to.

There you go, Connor.

Hey Mark, so there was actually a colleague specific question that just came through from Jacqueline the manga. She said how is the elf process? How is the elf duplicate process different than the axiom duplicate process?

You know.

So good question and I also want to mention that as I answer this, we no longer use it help in pushing anything to colleague. It's totally taken, it gave it up really they gave it up to a person in admissions and slash financial aid to monitor that.

So before this axiom upgrade, I really can't speak into detail about how exactly that those duplicates were managed. Is all managed on the IT side every morning. It was a very manual task they got duplicates in. Now for us, we pushed twice a day so we could see potential duplicates twice a day. If axiom flags someone as a potential dupe, it holds them, it will not push him in, and then it'll make you take action to determine if the person is a duplicate or no. They're a brand new person. Once that happens, they get pushed through.

And then you're good. Once that's happened once, action will remember it. It'll pass the ID back into slate. And so the next time it goes through, you're passing the ID number for that student over, and so it won't ask you a second time, if that helps.

Yeah. And they kind of expand on that a little bit too, Jacqueline, is we completely bypass the elf process, right? So we're using the axiom import process. It's proprietary to the axiom product. And we have a database that could set up within column that allows us to kind of follow all the colleague rules and then push the data directly to the tables. That does allow us to leverage our import process over the health process as well.

Yeah, very good question.

And it looks like there was a banner specific question which, yeah, hang on, let me scroll up and try to find it.

Is it possible to update GPA, fields and banner socalled prior college table for existing schools on record? Jeff, do you guys currently do that?

We don't do that and that is that's basically one of those data points that very few people on our campus needed access to. So sending it in to Banner was not a priority for us. I will say that we've essentially prioritized giving slate access to individuals on campus who need certain data points that we're not sending down to banner that would include our academic advising team, folks in our in our registrars office, folks in financial aid.

Um, and another question I want to jump too far ahead Connor. But another question I saw was about BDM and and same thing there we essentially store transcripts and materials for for applicants in slate and we don't make much use of BDM anymore. It used to be something that we did do especially when we were we were collecting common app data directly into banner we would store transcripts and things there. I think we've made, we've made.

The decision that slate is the system of record for enrollment management at Stonehill and so any anything that that needs to be stored on an applicant record is generally stored there and and we we don't send it to banner unless it absolutely has to be there.

OK. Thanks, Jeff.

Yes, I did see that BDMS question. That was Debbie. So we do have a process in which we can auto index the image file into BDMS. It works very similar to the sleep process. So it would just depend on how you would prefer to do that to me.

Look here and Jeff and Nicole are all night with answering these questions.

Do you use the colleague API to insert or update statuses or test scores? If you do not, how do you take into account multivalue fields and POS fields? Mark.

We currently don't take or bring test score data into colleague, but I think in other situations we do bring in multi valued data over into kind of like for financial aid and there's a few different items for that.

One in particular like you go through the template that Axiom gives you to kind of give you a jump start on all the different fields. So say it has 40 fields in it you're bringing over for financial aid information and some of those, if you have any things in particular you need to add it in. And as well, it's really no big deal. You'll be working with a person to help you out. So say there's five other fields you want to add in, they'll work with you to build out something to push those in for you. We had a situation where we had to bring in a multi valued.

Field actually needed all the pieces brought in.

To colleague. And so we set up a delimiter in between to make sure that happened. So, um, honestly, it turned out to be very easy for us in working through Axiom to get that data to colleague.

Thanks, mark. So I do see kind of a duplicate question here. How does it determine changes? Really, that's going to depend on kind of your own individual business processes on how we're making changes on the data. Jeff did answer kind of broadly that we do have procedures that are set up in the database or in the schema and that'll compare and contrast the data and kind of make those updates accordingly. But it's really going to depend on what data you want updated versus inserted, right, and what we're looking at.

Rather consistent record level and directionally. So we don't necessarily want to keep the data In Sync, but we do want to make sure that at what part does this record is slate this system of record versus when the student system is and then we'd make those updates accordingly based on the data.

I just want to mention timing. So if you're thinking about a project with Axiom and you might be considering, OK, how long is this gonna take? How long is it gonna take from beginning to really getting up on my feet?

Now of course it will always depend a bit, but every institution is different.

Uh, for us? I can't say exactly. I think it was roughly a month or maybe a little more, but definitely not working full time on it.

You will set up some weekly meetings with your axiom person or persons that you're working with, and they'll set up a timeline with you. They'll outline fields, they go through really nice testing process to make sure it's all right. Incorrect.

And then when you're done, you really should feel good about the thing you're implementing. We started off with Axiom on premise, for those of you who are on premise, and then we did also convert everything axiom included up into the cloud.

And so that was a change for us as of late.

And while we're waiting on a few more questions, guys, if you do have any questions now, it's definitely the time to ask them. While we have some customers who are hopefully doing the same thing you are. But I do want to kind of make an announcement on the axiom side. So we are currently in planning for our First Axiom summit. This is going to be a virtual summit for the first one. And then based on on how that goes, we will be planning an in person summit for the following.

Here we're shooting for end of February for our first summit, and we'll be sending out more information on that very soon.

That's great.

So I'm just going to put my information in the chat in case people do have questions after the fact. Feel free to reach out and happy to do what I can to answer those.

Yeah, I'm gonna do the same. I'm going to add mine here. I already put them in chat a few times, but I saw they kind of got buried.

Hmm.

Hey, Dave. So it really depends on kind of slate. By default Axiom, we'll can look for work as frequently as once a minute from data sources. The slate export process I think is limited to five times a day, if I'm correct there.

So we we could do it to match the slate exports, or if you're manually pushing out the files at any interval of 1, once a minute.

And so, Connor, if someone's looking for maybe a deeper dive after this conversation, just have them connect with you and then you'll arrange that.

Yeah, Yep. So I put my information in the chat and you can reach out to me or go to our website which is just axiomhired.com. There is a request more info button on there on the top of the page. So if you want a documentation or how somebody requested pricing in the chat, I can send you that, no problem.

Great.

Any more questions while we have a few more minutes?

OK, well I'm a big fan of giving people time back and not taking a full hour when we don't have to.

So if there's any more questions, please feel free to reach out to anybody on this. Either mark or Jeff could also put you in touch with me and we can get you guys started.

All right.

Yeah. Thanks, everybody.

Thanks guys.

Take care everyone.