The Art of Automations

Hello and welcome everybody. We will just give folks a few seconds to kind of be able to chime in. Say hello and chat. Feel free to you, know the usual things where you're from, how you doing. Hopefully everyone's having some good weather today.

No, we were in New Haven, but it's gotten a little bit chilly today, which makes me sad.

Beautiful OK?

So thank you everyone for joining today to our latest slate stage event. Today we have the great fortune of talking about the art of automations. As I was saying to these fine folks before this, I've been very fortunate that we talk about a lot of different things that I love, change management financially, and now Lastly automation. So very excited for this presentation. Joining me is Abigail Molen, Susan recent, Vanessa Thomas, and I'm very going to let them actually introduce themselves a little bit more in a moment. But we have as always.

Some housekeeping to do?

This webinar is being recorded and will be made available for viewing within 24 hours for Slate Festival Passholders and it will remain available until July 31st. Closed captioning can be enabled by clicking the CC button at the top right hand corner of the share screen. Full screen viewing can be enabled by clicking the expand button in the top right hand corner of the share screen and if there any reason at any point, you need to rethink your audio and or video. Please refresh the share window and of course feel free to post your questions in chat. We got a few good questions in before this session.

Because there will be time for a Q&A at the end and before I get turn it over, I just want to say a quick thank you to my fabulous colleagues. Erin Gore who's behind the scenes helping moderate chat and of course Leah Dudley who is in there so hard to make all of this possible.

Yes, always ABBA, ABBA forever. This will not be our Waterloo not today.

OK, and so here are fine presenters. As I mentioned earlier, we have Abigail Molen from PHB and integration consultant and from the Thomas Jefferson use University. Both Susan Reeves and Vanessa Thomas. Thank you for taking some time out of your day to join us. And with that I will turn it over to you.

Thank you Cody and thank you technicians for having us. We're so excited to be part of the first ever virtual slate stage events. I am able and as I said earlier, I am the newest integration consultant at PHB. If you don't know about VHB, we are a higher education marketing consultancy. Been around for 30 years and in that time we've helped over 200 clients with enrollment management, institutional marketing, Executive Council and of course technician slate services from.

Late, we offer implementations, advanced builds, diagnostics of your current system, and ongoing strategic support like we do with Thomas Jefferson and my colleague Susan Ann Vanessa here. So we are talking today about automations now. I think the first question we need to cover is what do we really mean by automations? There's a wide range of things that people understand as being automations.

In Slate, we're really talking about anything that used to be manual that your staff used to have to touch. That is now going to be completed by the system. So there's like I said, a wide range you have your bread and butter automations, the stuff that comes default with slate. You should all be using these if you have a slate system. Your deliver mailings using internal forms to manage your processes using checklist groups, then you have kind of that next level up when you're managing data. You have field rules you have retention policy's. You have scheduled exports.

Then finally, that last level, which is where we'll spend the most of our presentation today, is talking about complex automated process when you have automated decisions that you want to complete or an I-20 process, or a scholarship process, how do you design that process outside of the system and then bring it into slate using all of those different areas?

So why is automation an art and not a science? You may have gotten a little teaser to this if you were in the change management presentation with my HP colleagues yesterday. There is always going to be a human element to process design. You can't just design A process and put it in the system and it will work forever. You're always going to need to have people assessing whether it's working to maintain it from year to year to do quality control and all of those different stakeholders are going to have different opinions about how it should be designed, right? I know that later on in the presentation will talk about how.

Something and then you need to tweak it after a year or two, and that's totally OK. Not to mention you have to manage that change within your institution anytime you're automating something, there's going to be people who say, well, we do it manually because or we prefer it not to be automated, because and you have to be able to show them that slate can do those things and accommodate those manual interventions.

And the final question, the key point today what can be automated versus what should be automated? That is a question that no computer is ever going to be able to answer for you. That's that human element that's always going to need to be there. And that's why it's really an art. It's about strategic choices, not just doing what is best practice, because it's going to differ by institution.

So I said to start off, you know you have your bread and butter automations, the things that come standard with the system and you should implement as many of those automations as you can because those are low hanging fruit that you can save a lot of staff time if you're a slate captain, you can get people off your desk by implementing those automations. One of the most common automations we see when we're implementing with new clients is field rules. You have your standard field rules that you know, OK, you're an international student and I'm going to put you in this population or.

Maybe you have an address in an outside country and I'm going to mark you as an international student, but then there's also field rules where you can just migrate data from one place to another. Say you have a stealth applicant, apply for accounting, they don't have a prospect scoped academic interest, and you want to move that data there. Well, you can have a field rule that says take this application scope, field value and move it over to the prospect Schofield value. That can save you a lot of time with moving data around and you only need one rule to manage.

Hundreds of programs in your system, so that's a really great example of easy automation. But there are lots of other ones that you can put into place. I think Vanessa is going to tell us about some of those.

Yeah, as Abby mentioned, you know missing document emails. This is probably something that you know everybody has in Harrison's already. Part of your implementation. You know, setting up these emails, potentially by level. However, you need to slice and dice the contents, but again, the automation is pulling the recipient list and then deciding you know how often the email should deploy. You know, every month, every week.

And again, this is something that we've set up. You know, part of your baseline implementation. We can set it and forget it. Maybe look at it, you know. Look at it yearly with your cycle prep. But something counselors don't have to worry about.

Yeah, and another example we have is our generic source format process. So like other schools we have a variety of different data files that come in from different sources. You know, maybe it's one ofyou. Generally these are when it's actually from faculty. Maybe they found a conference and they bring back a list. Or maybe we purchase a onetime search list so we did want to create individual source formats for each of these files, either due to the size, there's just not many records or we just receive it too infrequently. So we came up with a standard generic.

Course format template and then we take each of these one up files and standardize the data in Excel to work with with this generic format for tracking purposes, we add an interaction code upon import and then we can query on that which is really helpful. So overall this is just a huge time saver for us and from a data integrity standpoint it just keeps things consistent and definitely a lot less room for error.

And this is just an example of, you know, over a three month period or so, all of the different generic you know one off files that came in for us. So varying in size or maybe 9 records going up to over 7600. So you can see there's just a variety of data coming into us, a lot of different data sources, and so you know this just kind of gives you an indication of how much we we have to manage.

And then this is just an example of our mapping of our generic source format. So for those of you that have worked in source formats, we've done mapping before. Just kind of give you a little indication of what we do.

Thank you Suzanne, so that next level we talked about was data management. When you're maintaining those custom elements in your system, custom fields, custom processes, but it's not necessarily a whole process, you're just using one area of the system. We definitely think that you know this is the key point where you're starting to decide. Should I automate this or should this be done manually, but that most of that is going to come later.

Yeah, we have a number of automations that are set up to streamline processes and workflows at Jarvis and one example of this is our common app field rules. Some students may start this late application or submit it and then later on they submit a common app so when that data imports will common app. We just didn't want it to just overwrite the existing data. So to preserve that slight data we created some common app secondary fields that we import into then rules will copy data from the secondary fields into the primary ones.

But only in cases where it's blank. So this just allows us to preserve the original data, but then only appends the new data where applicable, and then when the counselors in the review process, they can actually see both sets of data and then they can decide how to address it at that time. So it's definitely time saver for us.

And another example in terms of data management are some field rules that we created for deposit deadline. An application deadlines and we decided to build these out in these processes out to help mainly with our communications. Whether it's a merge field in a letter, but more importantly to drive our communications and deliver, you know at the our instance has freshman transfer, grad and conditions continuing and professional studies. So we have a lot of different.

Populations in here and specially with the grad population. It's they have a lot of different application deadlines we have. You know, we have 100 programs or more and they all seem to have different types of deadlines. You know, maybe over all of our 100 programs we might have 30 different applications that lines or more, and so we needed to figure out a way to drive people to these deadlines and in a way that is manageable that you know that we can maintain it and it's not going to be someone's full time job.

So we decided to do this via. You know, creating a field roll where we would, you know, build, use a custom field of an application deadline and create various roles based on program based on term and based on a student type to drive an application deadline and then we use that field and that value in that field not only as a merge field on the letter but as the driver. To automate these emails six weeks out from this date, four weeks out from this date.

One week out, a day after and so we were able and delivered to really, you know, keep the types of emails manageable and it helped us on the deliver end. You know, with the maintenance now, we decided that we were going to have to maintain it in the rules, but we felt like that was a better trade off then doing it and having a million email messages.

And I love what Vanessa just said about tradeoffs. Whenever you're automating these processes, there's going to be some situations where it's like. Well, if we automate it here, will have to maintain it here. And if we automate it here will have to maintain it there. You're always going to have to keep that in mind when you're designing these automations. Now, one other type of automation that's great for data management is the retention policy editor. If you have not been in that tool yet, it is really powerful. Think of it as rules that eliminate data from your system, but the retention policy editor has gotten a makeover in the last few months.

And there's a lot more you can do with it. It's more user friendly I think, and you can actually eliminate data elements from your system. So not only can you wipe records and clean out fields, but you can remove entire inactive fields, prompts, forms, events that you are no longer using in your system, which is of course going to help with your system efficiency and with your staff use because it's going to be easier to find what they're looking for instead of looking through a whole big list of things that are no longer relevant.

So coming up next, we talked about the easy stuff that mid level stuff without those complex processes, the things that require multiple areas of the system coordination with a large group of stakeholders and often some trial and error. We talked about tweaking processes in future years. You're not always going to catch everything the first time you go through designing a process, so there is a main question you need to ask yourself.

Do you automate this or do you not automate this? That's going to be the first thing you need to ask yourself when being approached with the new process, and there are different ways that you can get approached by that. If you're in year 234 of your implementation and your staff is more familiar with it, you don't have as many fires to put out. You can be a little bit more proactive. You can be in a meeting and say Oh well, you know it's late, could automate that for you. Wouldn't that be a great time saver for you and your team and it can help build that trust and confidence in the system.

If you have the time and ability to do that, but not everyone is going to, especially not year one. Institutions like Thomas Jefferson.

That's right, Abby. You know we're just approaching our one year slate adversary, and so you know, we're still Susan and I still consider us like we're in our implementation phase. Although we're really chugging along, and we have a lot built out. We're now at the point where we're putting a lot of these other little pieces, or these other little processes to get going. So for us, you know, when we're assessing requests and working on our priority lesson when we get a request to automate something, or to build something.

You know Susan and I need to take a step back and kind of kind of look at the big picture. And you know these are kind of our checklist that we're we're going through. You know, is is this, an emergency is something broke, is something existing, or the current process just can't go on in the way it is and we need to fix it. Is it a priority? You know, we have our list of priorities, but you know, we all know something comes out of left field and you just need to. You know you have to manage to it and you gotta squeeze it in and do it.

Is is this something a request that would save you know significant human resources? And is it something that you know if the first year team is coming to us, can we use it in transfer an grad you know? Can we really kind of build it out where a lot of areas can benefit? If so, you know that's a plus. Does this request have a good return on investment? You know to Abby's point just because you can do it doesn't mean you should. You know, is this a request for an email? And when we do further digging?

There's only 10 people impacted, but by the time we set that up you could have you know the counselor could have emailed 10 people individually, right? You know we're just not at that stage yet. Where we could do that, it would take it would take too much time.

You know, and for us, is this a nice to have you know, is there something for us? Is there something already working and this is the kind of like an add-on, and if so, we need to kind of consider that in the scope of our other priorities and and more importantly, you know we see a lot. We get a request for something like hey, we have this special population, can you create an application form for them? Will sure, but but what happens after that, right? That's kind of really where you know the rubber hits the road where we can create this form? But what's the process after that?

But you need it. You need a custom checklist. Oh, you need a custom workflow. It doesn't. Maybe it doesn't fit in our current automations and you have to build up tweak automations for that. That's really, you know when when it starts to kind of balloon up and we have to decide, is that something that we have the bandwidth for at this point?

Great and you know when deciding how to proceed. You know this is our philosophy, at least in the end of year, one of our implementation. You know, we hate to say no and but if we do, it could be for a variety of different reasons, some which that's already touched on. You know, it's not a priority or we already have a process in place that works.

We don't have the bandwidth to support it. There's little or no return on investment. You know only a few records are affected. There was too much maintenance involved or it's just not a fit. You know, a request came in from another area outside of enrollment, and we're just not ready to address it. So you know, those are just a few of those reasons. But when we say yes, because we've determined it is a priority, you know it's relatively easy to build and maintain, and it's going to benefit multiple areas. You know. For example, we can apply it to our first first your team.

And also transfer and grab and then oftentimes instead of saying no, we really try to meet in the middle with a hack, so this would be like a short term temporary solution with the assurance that later on we're going to build it out further, maybe in Year 2, maybe beyond so. An example of this would be, you know, when we had a set of special population application. You know, right now it's just very very bones, you know, limited automations. But again, the plan is in. Your two will expand it and align it with some of the more complex process.

Yeah, so as we said earlier.

Yeah, better.

I'm sorry we're going to design these processes outside of Slate 1st, and when you're doing that design, you have some choices to make one of the first things and we talk about this all the time at VHB with our clients is building for the majority. You want to design that process to handle most of the situations for the most common students there are always going to be exceptions and outliers that you should not try to automate into your process because you will create loops you will drive yourself bonkers trying to catch every single individual.

Situation that may or may not come up, and it's just going to slow your system down. If you have lots and lots of rules that are only looking for one student amongst thousands right? So make sure that when you're designing your processes, it's accounting for most situations, don't get bogged down in the specifics in those individual cases, you're going to have some manual intervention. That's where that 8020 ninety ten rule comes in that we spoke about earlier. You also want to keep in mind that when you're building these automations, they need to be maintained.

And so you don't want to design A process that only works for this one year. You want to design it in a way that it will be sustainable that it is not a lot to maintain things like term specific filters. If you can find a way to get those mortar round keys or maybe use prompt categories to leverage those filters instead of using a specific individual term prompt selection. Choices like that can really affect how effective your process is in the long term. And then of course you're going to have your institutional governance.

If you're in your own slate instance, great. You can do whatever you want, but if you're like TJ, you where you are in a shared instance across multiple areas of the institution, you need to make sure that whatever process you're designing is not going to impact those other areas, and it's not going to mess them up. They're not going to see it using permissions to manage what people can and cannot access within the system, as well as just knowledge amongst your slate captains of what those fields are, where they go. Please don't turn them off right.

So I think that Tju is going to walk us through a case study here of making these choices in an automation process. They have a very complex cast process that we help them design an I will pass it over to Vanessa.

Thank you Abby. Yeah, so when we were working with VHB.

Through the I guess last spring and last summer building out our instance, we were really busy. You know, getting our slate app done and you know getting all the processes tide to that. But we also had. We also bring up. We also use liaison CAS applications, national cast applications where we have thousands of applications over 9 separate casos. You know, PT Cassity, castform pass etc and we needed to account for them and slate.

An you know the scope of an implementation you know is it's lot. It's never ending. It takes you longer than you think, and so we were in a position at Jefferson where we needed to figure out how can we account for these applications. We don't have a lot of time and just due to the scope of what we have to get done in the time frame change management we just we could not get all of it in slate. In our ideal state in your one. So we had to figure out.

You know trying to manage the technical piece and the person the person piece, you know staff and faculty. What's the best case scenario for your one? And so we had to meet with? You know our admissions team we met with our strategic communications team and we decided a couple of things of, you know the priorities. So one was that we were going to keep the file review in Cass. The faculty, you know, admissions does do. Part of the file review, but the faculty are in there a lot, and so we just said, let's keep him in there. We don't have enough time to do it.

Any other way we're going to keep the file reviewing casts, but we're going to do the last part of the prop of the file.

Release of the decision. In Slate we're going to do interviews and Slate so we can leverage the scheduler in the event module. You know we're going to let them see their decisions. See their post post enrollment checklist in Slate so we can use the portal. We're going to decision out of Slayton for communications. Anything pre decision we're going to kind of keep in. We're going to keep in cash, so if you're working with your in progress applications, that's going to stay.

In cast and then anything that's related to your decision or your interview or communications post.

Posted, Matt is going to be in Slate or and or events. You know, if you're invited to an event that's going to be coming out of Slate as well. So once we kind of had these lines of demarcation, we needed to figure out the process and you know, we needed to leverage, you know, the source. You know, source formats ended up building out custom formats for each of our classes because we just had to build them as we went. That was kind of our timeline. We have some pressure around there and we ended up leveraging.

The cast local status field. If you guys are familiar with that and make creating a custom field in slate, that kind of wasn't equivalent to that and that local status drove a lot of the automations and slate in particular. It drew. We had its own workflow and it drew it. We were able to create, you know, custom Ben movement roles based on exclusivity groups that were able to move applications back and forth and just due to the complex nature of the review process for some of these.

No, not all of the files would always move from left to right. There was a lot of back and forth between some of these bins as like holding places, so we had to just be mindful that we really understood the process so we could get these right. And, you know, we didn't always get it right, but we'll talk about that later. But you know, we had to be mindful of that. The other thing we needed to be mindful of in terms of the automation was our communications. We had to really kind of do an audit of our communications to decide.

You know when was happening, we would bring these files in daily, but you know there are some files that we brought in that we didn't want those applicants to know that they were in slate yet, right? You know? But there are some where we needed them to know that they were in slate and we needed them to create an account so they could sign up for an interview. Or so they could view their offer of admission. So we had to be really mindful of like when are we sending out this account creation email and when are we not? What are those local statuses to automate that?

We also had to, you know, just be mindful of when we have our decision released queries and we do that process of making sure that we are accounting for the nuances with the cast. We decided for students where we had where we are unable to offer them to admission. We didn't want them to go to create an account, go to the portal to kind of get bad news. If we just felt like we were twisting the knife a little bit, we decided that for those we would just kind of send them an email with the news. So we decide to be very mindful when we were.

Releasing decisions that we were gonna sign a letter to those and we looked aside a denial letter to the slate app so we had to just be very mindful that we were being minding all of these nuances in the processes between the slate app versus.

The Casa and you know some tips and tricks you know. I think, for us we really had to take a step back and work closely and map it out and understand the process and really work with admissions and let them know. Kind of how slate works. You know when we created these mappings for the source formats we said listen guys like you can't make your colon 2 dash went once this is built like you're going to things won't work then. Or if you add a new local status you have to tell us where that data is not.

I mean, in an it won't work, so we you know we had to just make sure we were on the same page and you know, as I mentioned before, be prepared and I think this happens in anything you do in slate. You know you're going to troubleshoot and you're going to refine. I woke up one morning. I had 2000 files in the wrong bin, so something was wrong. So you know, we had to figure out and maybe reorder our explicit useless exclusivity groups. Or we had to, you know, add some type of bin assignment equals this or doesn't equal that we had to do some refinement.

During during the process, we're going on in year two. What are we going to do differently? Not too too much because we have a lot of things that we want to build out and slate or launch and slate, so we're going to kind of keep the overall process the same, but we're going to try to go down to one source format. Right now. We have nine source formats, is absolutely bonkers the way we did that. But you know, when you're two months since late, you don't know what you're doing. Really, that's what we did, and so we're going to try to get down into one source format. We think that will help.

Obviously, and will be bringing in Progress apps, but we're going to keep the structure of the same and hopefully in your three we want to bring everything in, and we know schools are doing it. I've, you know, I've attended some webinars about it and I think in the end bringing everything in will be actually easier because maybe we can just download things one time and less complicated, but we're just not ready for that yet. We know that techno lutions and liaison or working. I saw an email come out.

So we're going to be, you know, researching those standard formats that they're developing and see if that can assist us, but you know, for us we were, you know, we really utilized PHB's brain on this and try to figure out how how we can do this and and get it done with a limited time frame an you know where we could kind of meet in the middle and get this done.

Thank you so much Susan for that case study, I think that was a really good example of you know how you need to assess that from the beginning to end, and then of course, after your year one, you need to think OK, I've got all these automations in place or I've got new requests for automations. What do I do with them? So Susan is going to tell us about the plan they have at tju.

Thank you Abby. Yeah, so you know like everyone, we have to address the day-to-day or short term requests and issues that come in. But we also have to plan ahead for Weston, a common. Keep things organized in a way that you know just keep things moving forward. And so for day-to-day requests we have essential email address that we used to take them in from everyone in our division. And then we just divide those requests, amounts or technology team. So we found that that's just a really way an essential point that people can send those types of things.

We also have a slightly group that meets Bi Weekly to discuss different items that are a little bit more complex, so you know we can talk through processes or issues and make decisions as a group, and then this would basically be anything that you can't really handle by email for the long term. We have our slate priority list, so right now I have some carryover items from year one implementation, but it also has our year two and year three requests that we've been taking it from our slate lead, so you know, as as reviewed with this lately group, we set our priorities and that's based on.

Things some of things we've mentioned before, but you know, strategic priorities. Return on investment available resources. You know the assessment of whether something is nice to have or you know, is this a need? Or is this something that's really going to be a game changer for us? So this list then becomes our road map and we really try to minor list. You know, of course, there's always a high priority item that comes through and we have to be flexible and pivot to address it, but that's always to be expected enrollment. So this is just a few ways that we manage things in Jefferson.

Awesome Nikki season. You know most of our clients will implement these complex automations during their cycle prep period. You're easy automation so you can kind of turn on at any time. You don't need to worry about those schedule and you deliver mailing, build a new new field rule that's great, but for those complex processes, if you have a period of cycle prep between your application cycles, that is the best time to implement those processes. You're not going to affect life records. Your staff isn't in the system poking around, so you can test.

Even in your production environment and see how things go. Not everybody has cycle prep, though. I know at my former institution, the University of Delaware we were rolling, the application was on all the time. We had different rounds going so we had not a cycle prep period, but I called it the slate construction zone. I would make an announcement via Slate. Send it to all my users and say hey, we're implementing new processes this week. Here's what you can expect to see in the system. So just setting those expectations, making sure you're communicating with.

Everyone who is involved in slate, including the people outside of the system who may be affected by changes to the process, making sure if I'm adding a new financial aid portal this late, that everyone in the student Financial Services Office knows communication is going to be super key. When you're implementing those new slate requests.

And of course, there's no one size fits all approach, as you've heard on this call, there are different approaches at different institutions. Whether you're in year one year, three year, 10, and how much you want to accomplish inside of the system versus how much you have going on outside of your system. So you really have to look at this again as an art and not a science. You have to sit down with your team and go through each of the steps that we talked about today. How am I going to design this process? How am I going to implement this process and how am I going to maintain this process after it's built?

Those are the key pieces that you need to think about when you're designing this automations.

So that is all we had for today. For our presentation. We are going to get Cody back on the line. I'm sure he has some Q&A questions for us, but we have really enjoyed presenting for you today. Thank you so much.

Field.

Awesome, that was a wonderful presentation and also just happy sleep versary the first year. Both feels like it's been a ton of time and at the same time, no time at all, so it's a really great milestone and I've really loved what you and working with the folks at our age. We have been able to do in a year because it seems really daunting, but what?

Impresses me the most is just how thoughtfully this whole thing has been built out. It's definitely about automating with intelligence and sustainability in mind, which is exactly what's happened here. So this is really been an awesome kind of look into a really well created and crafted process. Just one thing to reiterate on that, I really took home with him, probably as it also came up yesterday. Was the idea of that again, that 8020 ninety ten sort of rule is at some point down the line there is going to be a human who needs to be involved.

And that's OK. It kind of keeps things fresh and make sure that you are doing things sustainably correctly time after time, and the only other thing that I'm just going to mention out of as a former automation team member technicians was the retention policy editor is an amazing tool if you're unfamiliar with it, though I recommend even though you don't have to do it in test first.

Just try it and test to make sure you get exactly what you want and then go back to production. And with that I'm going to now get off my soapbox and start asking some questions.

OK.

Let's see here. Can you talk a little bit more about kind of automation maintenance and documentation practices that you might have? Sometimes it kind of goes back to that thing. If you were saying, if, like when you know you're designing well, maybe don't think about specific term. Maybe think about trying to migrate or ground key or around themselves consuming talk a little bit more about how you practice that sort of maintenance and upkeep and keeping those things in the back of your mind.

Yeah, I can go ahead and dive in on that one, so documentation is kind of my specialty. If you've seen my slate presentations in the past, then you know that I love documenting my training, resources and process documentation is something I got into right before I left. The University of Delaware. I think it's really important as an internal slate manager. Whether you're the captain or you're just, you know, the captain of events. Maybe write down those processes right down from top to bottom. Here's what this process does.

Here the bin rules here, the bins. Here's the population rules that manage those bin permissions. Here are the forms that relate into that bin. Here's the application. Here's where the application link is on the website. I had a process document for everything, honors international scholarships, financially portals an it helps because when someone had a question I could just point them to the document. We used Google Drive, which you know if you have a cloud server, put those documents on the cloud and then you can edit them, update them.

You can say hey, I made a change to this process. I don't have time to update the documents. Can somebody else go update that for me or just tag somebody in a specific instruction that they're looking for that was huge for me to write all of that down in in some kind of way and then thinking about sustainability? What would often happen is I would write that document near one. I would build a process, maybe not to my own best practice using term specific filters. And then in year two I would go back and say OK. Which of these rules can I now change?

Now that I know it works for fall 2021, how can I update this to make sure it runs for every single falter? And I love prompt categories for that. We used prompt categories on our terms at udita say fall 21, fall 22, Fall 23. They're all a fall category and then you can filter on there which is really useful.

Awesome, just get back my document up. I apologize. I'm looking off in the other direction. I have my notes on the second monitor.

I'm going back to retention policies for a moment. How do you recommend using retention policies while also preserving data for reporting? How do you prioritize or consolidate?

That is a very good question.

You have to make an institutional decision of how long you're going to report out of Clayton, this funny. I just had this conversation with one of our K through 12 schools the other day about their life cycles. A little different. They need like 18 years of data versus standard college. Office may only want the last five to seven years of data, so you have to start with your institutional policy. Where are we reporting out of? Are we reporting out of Slate or are we using maybe another system of record like a student information system? And then once you've determined that?

You use that window to determine when you're going to retain that data and when you're going to use a retention policy to get rid of it. In terms of storing things for the long term, you have a choice of which retention policy is to run. Maybe you need to get rid of all your events, but you want to keep the applications. The retention policy editor allows you to do that.

Excellent, I mean it is a really kind of robust tool and it's one of those things that I both love, but I also find a little bit terrifying at its core.

It is absolutely terrified.

I'm but I have the way that I'd like to describe that to people. Is it's a healthy degree of terror, you know, it's all good.

A question came in for Vanessa and Suzanne. Can you explain sort of how your positions work within your relative offices and how you kind of manage both implementation and maintenance over this product?

That's a great question.

Yeah, so we have, you know our core technology team. We have two campuses where we have two different teams at the moment and so right now we meet and we go through issues. We any of the.

It just said before that come in through our email. We then distribute, but again, we're always constantly meeting and discussing issues and working through keeping lists, deciding how we're going to manage things, how we're going to implement with kind of timelines and deadlines we have. And he's going to run point, so I think it's just constantly our team working together to work through those.

Yeah, I mean our team. We have a core team that you know works on building and troubleshooting and you know it was we won't, you know, I'm sure everyone has those. It's hard, right? It's you know. Specially you know for us when we were first learning. I'm like I'm trying to understand Slate. I'm still building, but I'm also the help desk. Like I don't know. I think it was a lot, but you know, just we haven't. There's a six of us that you know, pull together to do that, but we also have our strategic communication team where there are now four people and they really focus and deliver an events.

So even though Susan and I are the slate captains, we have our counterpart over an enrollment strategic communications who really kind of runs that we don't micromanage him and his team. There are experts in that area and, you know, we do work together. We need to be aware of what's going on there and potential impact. So we, you know, we are all constantly talking or they need our help and building a rule or looking at a recipient list so we work together but.

Awesome. One of the things you talked about kind of in earlier on in your presentation was this idea of knowing when to say yes, knowing when to say no and knowing when to meet.

And then something that I love because you know, it's not always fun to say no to people. And sometimes you really have to do that. But this idea of meeting in the middle, I think, is incredibly beneficial, particularly for schools that are newly implementing because it's one of those things where you kind of keep in mind that sort of versioning idea of I just need something functional. And then I make it pretty later, but sort of with those kinds of projects. And this is thinking toward the future. It's also amazing that you all have a plan for what you'll be doing in year three, even.

Big ups for that. As we all know plans.

Well, you know 2020 happen, but I'm so how do you? What's your plan on sort of making sure that you kind of get back around to those meet in the middle of things that maybe now need a little bit of extra work.

Our goal is to handle it in cycle prep. Now you know, I don't know how that's going to go down, but you know, that's our intention, you know or we understand, you know, we had. Maybe we had this process that we kind of hacked in and it didn't. You know it happened around April, so I know for next year even though I want to manage it during cycle prep, I don't. I really have some buffer where I need to. Maybe start paying attention to it closer to when it needs to kind of re up and kind of work backwards and make sure.

That we can build it out. We may decide though, hey, you want you want to do these new things and slate or we're going to beef this up can you? Can we live with this hack job for another year? And sometimes the answer might be yes, so you know. But we have all these lists of priorities and we really try to mind to mind those lists.

And I want to add that like this flexibility is coming from our division, right? It's coming from the top from our leader, but it's coming from all of our admissions directors and our counselors in our our visit center like they understand, like the amount of work it takes to get a system built right. And so they, you know their flex all this flexibility is coming from them and their understanding, because, you know, we hate to say no to people or even hate to hack something we want to give them the ideal state from the beginning. But that's just not possible or it takes a lot longer.

For us, because we're new, so that flexibility is just their understanding and their you know we don't tell them. This hack has to stay, it said it's a conversation and we is wearing a team. We're in it together to say as a team. As a division we're going to live with this for another year because this is the focus. So it's not necessarily just us, it's everybody in our division having that kind of mentality.

I love that that is the best kind of place to be when you are doing something as a team. Do you have any tips on sort of managing your review of the rules? There are people who would sort of like just add almost date to review, so can you give any advice on that one?

So I used to have a quarterly review of specific rules, like I knew that my major roles in my population rules only needed to be touched in the summer, so I had like July 15th set to do that in my brain all the time and I would start talking bout cycle prep to my colleagues in May and I think it drove him bananas, but I would always be like what do we need to update in July? The other thing is each quarter and like OK, the honors processes in the spring. So in January I need to look at the honors stuff. OK, the visits.

Are special in the summer, so I need to look at the summer visit sometime around April or May so. Kind of you get into a calendar almost.

Our office started to develop like a process timeline that was like a Google Calendar that had those dates on it. That's one way you can do it. I also love to leverage the notes in the rules, noting that I already reviewed this On this date so I don't go back and do it again. It saves you some time and you can query off of those notes I believe, which is awesome.

Alright, and the last question that we have again for Susan and Vanessa is can you talk a little bit more about the emails that you have about missing items and sort of how are those structured? Are they listed in the email through various exports? Is it just pointing applicants directly to a portal and what's going on a little bit over there?

Alright, I mean I'll take that one.

We definitely are driving people to the portal. I believe in your one I have to actually look again. This is my strategic communication. Are strategic communications team really handling deliver? But I think in your one we're just driving them to the portal. Basically, you know it's going think it might be going every three weeks or something. I'm not sure of the deployment, but it recurs. It drives him to the portal saying thanks for your app, but you're still missing something. You know, in an eloquent way, go to the portal and check it out and then the portal will have the checklist item, but I'm sure.

But our goal is right in your two is to be able to drive in those materials to say so. It's in the body of the email. Hey, thanks for your app. We're missing your high school transcript, you know, go to the portal For more information, and then eventually we would like to then deploy an email saying thank you. We got it, but this is still missing. Go to the portal so you know we we're we're building it out but again in the year 1 get it off the ground we're just really constantly driving people to the portal and for that we like that because we want to get.

That we want to train our Africans to go to the portal for everything. So you know, in some ways it may be intentional that you know some schools intentionally may not decide to put the missing materials in the email and just drive to the portal. 'cause I kind of want to train people to just to go there all the time for everything.

Awesome, that brings us to the end of our questions, so I just want to take a moment to say thank you. Susan, Vanessa and Abigail. This is been a wonderful presentation and I think one that's actually really important. It's the kind of functionality that everyone is looking to accomplish, but I think we can all admit unique items on. It's very easy to kind of go off the rails and either under automate or way over. Do it so we think this is provided an excellent insight into what you were doing at tju with help of PHB.

But also just good lessons for everyone in general. So thank you to the three of you for joining us today. We do have another session today, so doubleheader day I believe the next session is on sourcing and tracking inquiries and applicants with my colleague Jordan. So that is it. You don't have to see me anymore this week, but thank you all.

Thank you.

Thank you.

Thank you.