Group Focused Call: Permissions in Shared Databases

Hello hello everybody, how's it going out there? Happy to be here.

All the all the housekeeping items off.

That's fine, thank you. Sorry I was a minute late. I was actually on another call. Sorry bout that. Hey everybody. Yep standard, here is who we are. Where are you from? What the weather is like in the chat? That's always fun.

You know, I hope those on the I was just uncalled somebody from from the state of Oregon so I hope all you on the West Coast or stay safe and.

And.

You know, and it's a It's crazy time out there so.

Cool.

So.

Alright, we got every yeah people are still coming in.

Awesome Yeah Transy. Hello Transy. Hey Noel from Barnard.

Hope things are well down in Lexington.

John.

Nah, it's well. Yeah not saying that Oxford my Oxford OH isn't cool but it's different. Miami Miami University of Ohio expert.

But it's cool to Miami. of Ohio is absolutely a cool spot.

Yeah, sure. So over the next, appreciate everybody. Hate being here what seanan I want to spend the next hour ish talking a little bit more about with the folks who are interested and we saw it from obviously who everybody who's here and a lot of where we posted in the advancement kind of sub forum and student success subform is because we think this is probably definitely highly applicable to the folks who are operating in a shared database and with Sean and I both know that that.

Are a lot of advancement folks in a lot of student success folks sharing with admissions or student success? Sharing with admissions an advancement so relatively recent enhancement that's been made that has a really fantastic effect, effect, or capabilities on permissions and populations and querying abilities, we thought it was very, very applicable to this group, which is why we kind of posted in both of those areas to say let's get on and talk about it.

And we're going to cover some stuff that is probably new to most of you because it's relatively new in the database. But then we're going to go over some kind of standard I think are probably more best practice permissioning.

Conversations as well, so we're going to talk a little bit about the recent enhancement as it relates to configurable joins, and we're going to dive into base permissions.

Query based permissions, essentially how how to maintain or constrictor control? Who has users who have access to which query basis joins permissions. So same concept, how you maintain access or restrict access to various configurable joins will talk a little bit about population permissions. An population access and then.

Permission or access to all the way down to the field level as it relates to configurable joints. All of this is part of this big conversation of we have now folks in slate that are it's crossing divisions. It's crossing offices. It's crossing different departments and we're constantly in conversation about best practices. Who should what Department should have access to what? What users or.

You know user levels should have access to whom, so on and so forth. So that's really what we're talking about. We will provide some examples were going to jump into slate a little bit. Shawn's driving the bus. He's going to be clicking around in slate to show you some really cool practical examples, and then obviously we're going to answer questions along the way. There was an opportunity for you guys to put questions into the RSVP in your registration form. We will answer as many of those as we can, and then I'll keep an eye on the chat on the left hand side. So if you're.

Typing questions into the chat. Please feel free, go ahead if it's applicable for when we're on a certain slide or we will answer it right there and then. Will save some time at the end to answer as many questions as possible. Does that sound good to everybody? Sound cool, everybody's here.

Joe.

Rock and roll.

Yeah, and most if not all of your operating in that admissions plus right. So admissions is the primary user. The initial user of this late database, and then student success folks, or joining or advancement folks are doing. There might be rare cases where were all three of those user populations exist in the same database. But yeah, we're will segment out the relationship in terms of like two of the three sharing the same database.

Yep.

Yeah, you know what we're talking in. Student success. We talk a lot about person status effect, what we're talking about, or for the scope of the conversation today is underlying kind of the next layer, deeper than persons desk as person status is that big. Very, very high level of record categorization or identification, right? What we're talking about is, let's say for the student success example there, attending slate University or Barnard or Miami.

Ohio, whatever they might have the data point there that might capture them into this population or qualify them for this rule would be, you know, do they have an enrolled decision, right? So that they have the decision that they went through the admissions funnel for and then they're attending? Fill in the blank slate University, but yet to have a confirmed graduation date. So this would be kind of utilizing the schools information or the schools table to help categorize as a useful datapoint for pushing folks into these populations.

Yeah.

Yeah.

Correct?

Yep, really, really common conversation. I think for Shounen AI with any of the folks that we talked to, you know, when is it appropriate for admissions in this case to stop being the owner of kind of this data or this record an when is it time for student success to kind of take over ownership of it? Who should be the quote? Unquote? The owner of the record is really.

Another kind of important point to talk about when we're talking about exclusivity groups and that might be it doesn't electron set. It doesn't have to be 1, right? You might have admissions populations or admissions users that still need an should have access to a currently enrolled student records or data points there, so it doesn't have to be exclusive. But certainly Sean and I always talk about kind of conceptually big picture.

What kind of zoom out and think about who is the owner of the record at that time? Is it admissions? Is it student success or is it advancement?

Yep.

Good strategic conversations to have.

This slide actually, or the creation of these records, actually took the most time. First, when we're thinking about this, what can we name our sample records?

Yep.

Yep.

Yep.

Folder structure is always important you if you remember back from launchpad or those who have attended learning lab. Don't forget folder structures always really really important.

Yeah, and we were cut. Sean and I were talking about this a little bit like who might qualify for that even in our fake use case here you know your students. So for the student success folks on call, there's probably not anybody that may fall into this category because anybody who is a currently enrolled student, you know who they are. You know who that population is, right?

Donors and advent in the advancement world. Maybe a little bit less so, and then certainly in admissions you might have at the very very top of the funnel, kind of your prospects or the purchase names. Those would be the ones that would fall into this sketch alright, where?

The student success folks, almost all of them should would likely be identified because of the purposes of Student Success. There they enrolled students. You know who all of them are, basically.

Right?

Right?

Yeah, yeah, this is kind of our, you know our example use case which also spans all three in the same exclusivity group were talking admission, student success and advancement. So the order became really important for us when we were thinking about doing this to make sure that the records were segmented appropriately for the purpose of the example. But think about this, you might not have.

All three of these.

Are these different categories in the same exclusivity group? You might only be worried about tip, or it might be entirely within admissions. Let's say grad versus undergrad. You might not even be thinking about student success and advancement yet at all.

Yeah.

Oh yeah, look at Sally.

There she has worked **** ** it so.

That's good, yeah, sure.

You can see that in terms of the record segmentation grouping she Sally, this record hits the first one, which is great. The student success because if we take a look at her record individually.

We see that she's got, you know, the upon first look mental. Well, wait a minute, you know she's got an application. So what's going on? She does an it's for a, you know, a previous term, but it's an active term, so we know for those shared databases. For the student success purposes, they've gone through the admission process already, so that's a good thing. So she checks that box. She has that, but also under her profile we have added, or in this case you would have added XY, zed University that she's currently attending and does not yet have a.

Conford

date or graduation date, whichever is, is your nomenclature, so that categorizes her an fits her into qualify for that rule.

Yeah.

Only thing I was going to say is that you know, we again thinking about this use case that we're using. Specifically, we chose those data points because they were, you know, we thought through this and said OK. What are some simplified data points? The underlying data points that we can use. Note that these are practical, right? But they don't have to be for you. You don't have to copy these.

Structures verbatim were just utilizing these data points as an example, and if you have questions, type into the chat so that we can see him and answer them along the way. 'cause next we're going to move into. So we've got our records segmented right? That's kind of the first step. How we're categorizing them. The data points that we're using to evaluate them in the rules and push them into these populations by student. Now we're talking about, OK, let's move into.

The user world now how are we structuring the user configuration so that the right people have the right access to the right population or person record?

So.

Sounds like everybody's cool with the records, or it looks like everybody's cool with record segmentation, and that's good because none of that's really new, right? You know, you guys are aware of exclusivity groups you're aware of population and rules being dependent codependent, so that's good.

Are you sharing?

Magic screen.

I'm sorry, Sean. I'm sorry to interrupt, so we had a question Jack. I think back in well it said Aiken record being two populations. For example, we want current students that have donated right. So the student success plus advancement example I said sure, multiple populations can exist. Olyvia most apropos says well, wait a minute, let's talk about exclusivity groups, right? Because isn't that kind of jam get, you know, in that record, then going to get jammed up in the exclusivity group.

Right?

Yeah yeah Jack Jack. Good question Olivia. Great call but then you know, let's you kind of zoom back out to say OK, do they? If they're going to be in two populations? Do we need multiple offices to have access to them? Therefore you say, does this record need to be pushed through this exclusivity group? So backs out to process? And this is where it's case. By every case is going to be different.

And in that case it would be different than our our showcase example here. So good call. Good question, good comments, yeah.

Yep.

Yeah.

You can go ahead and start sharing again.

That's really all that I'm here for.

Right?

Right?

Yeah, so it's impersonate, right?

And Jane needs to see, you know the admissions folks James James standard accesses to, let's say Alex Admissions, and we see that nothing looks too different here. That that's appropriate, right? The way that we structure this. So far so good change should have access to this record and should be able to view it at a person level, like a record, look up or person look up level. You can see either in the.

Look up option or the upper right search the Omni Search where Alex would come up. So let's say that.

Jane grad admissions should not, however, have access to somebody who's currently enrolled somebody like Sally Success, who has is, falls into that record. Segmentation of student success population.

You can see it shows up right, so just a quick. This is a small you know tidbit here, but you might say, Oh well, we can search on me. So I just saw Sally success. So that means, you know we can access or actually it doesn't. So the the error or the stop comes up right when she tries to open up that arrived on trying to open up that record as Jane from grad admissions. So that part of it great structure works perfectly. It limits record access as a whole. There's no reason for Jane to view Sally's.

Record in its entire T, you know, not look, not even talking about different tabs or different data points or anything. We just don't want Sally to be able to look at. Excuse me, we just don't want Jane to be able to search for or look. Look at Sally's record in its entire T, so it worked.

Right?

Should be there somewhere.

Yeah.

Yeah.

Right, so there's you know, in this database entirely, there's something like 105 or 100 and 6000 records. So just based on this base level population per person by population.

Permission it then alters right just the record segments are record segmentation that Jane from grad admissions is even allowed to query on, so it's as if you know, not as if I mean technically it's as if those other records that she does not have access to kind of don't exist in her in her worldview right now within slate.

Right?

Yep.

Right?

Nice and fancy. There you go.

Yeah, and if you have questions, type in the Czech as we've kind of, you know we've made it transition from Alright record segmentation. Cool, now we're getting deep into the deep end of user configuration, right? And it brings up the point when we're talking about join permissions and base permissions, it goes back to that strategic.

Thought process where you say who does this user need access to these bases and these joints having that conversation prior to building this out all the way down to the.

Individual user level are things that you want to start thinking about who should have access to which joints and whom should have access to which pieces, right?

Danielle does Jane need sequel level permissions in order to add that subquery for address data?

Rep.

It's.

Sorry, so in the example of like starting from a different base giving, let's say that Sally success while she was enrolled her junior year, gave to the student government fund or something like that. Sean, right?

If you're searching on the gift level right, the gift base, which is again one row per gift.

Sally would show up in that query.

Her record might not be accessible, but in terms of query results in what's being pumped out, that there is a need for that gift and all the information associated with that gift. A Sally's name or other exports that might be tide to Sally would be available in pull accessible through the query if we're if we are. If you need to report upper out or reconciliation showing brought up, you know we were talking about this. If you need to balance the books.

That gift is important. You don't. You don't want to lose access to the gift information. You just won't have record access to Sally, but would be. She would be associated with that query, something just something to point out. And Steve. Good question. This is being recorded.

Right?

Right?

Yeah.

More alright, we got about 10 minutes left.

And couple more.

Slides to go through. We talked about joining permissions. We talked about custom field permissions, right? You're you guys are familiar with a couple of the excuse me we haven't talked custom fields permissions as the last one you're familiar with some of the things on here already, right? So the new ish right? Or or touched territory would really be those based permissions to join permissions and then finally you say OK this is great. This is cool. What about you know down to the custom field object right? I need custom field.

Level permissions and access and query access, so that's going to be the last thing that we showed you and then we got time for questions, obviously.

Right?

Yeah.

Yeah, so if you want to show the screen, yeah, so you know in the student success conversation a lot of processes surround.

Pretty high levels of security and sensitivity were talking about Ferpa sensitive information. Sometimes HIPAA sensitive information for talking bout student well being or mental health, and those need to have in a lot of cases somewhat of a locked down on identity right where you say this is. This is it very, very sensitive information, so we were really, really going to go at a granular level to make sure only the people who absolutely need to see this information or query on this information can do so.

Bye.

Yeah.

Under disciplinary export.

Right?

Machine.

OK.

This customer permissions back.

Yeah, but technically yes. So yeah, I mean yeah. So you just need to create the custom permissions 1st and then apply them specifically to the users that you want to have both or neither or all.

And then Sarah asked the good one, which we thought might be brought up.

Olivia yes, correct so you can pick more than one from the field level, but put you can put users in which you said exactly correct. Do the custom field permissions persist throughout? You know? Kind of this late universe. Let's say look record look up queries which we just showed the example of our report, something somewhere else right. Record view would probably be the one that would be most common.

Yeah.

Yeah.

Drive.

Yeah.

Yeah, yeah, I would Sean painted beautifully, but you know you can see the field down here in question. All the way down at the bottom of this tab is that conduct disciplinary hearing. It's viewable. However, it would again kind of that zoom out. Let's talk a little bit larger scope about that tab. You know are there multiple tabs structures that you can have where fields like that? Well, the sensitive nature can all live together for viewing based off of these custom permissions and then not viewable the entire tab.

It's more about kind of where those specific points of data live and that can be attacked in a different way or managed in a different way as opposed to you know, not having that field just itself disappear. From this tab even though I have access to the tab.

In time. Yeah.

So we got like 3 minutes left just being cognizant of everybody's time you had really good questions there in the chat keep em coming.

Sean at the one that we wanted to talk about. I'm researching best practices for segmenting records within a single database. We're considering adding only currently enrolled students in Slaton, weighing pros cons of adding them as a separate database versus continuing the use of their person record any info. You can provide on this would be greatly helpful.

I think the the the use case that we just use kind of leans to the latter right. The the pro of persisting through the student record not creating a separate database. But in fact, having the student record take on different shapes and forms an user access based off of where they are with these underlying data points or person status is or what it really becomes is a combination of those things that way. You've got one record as it persists through this entire.

Student life cycle from admissions from pre admissions to admissions to currently enrolled all the way through to alarm and it allows you to aggregate. The data in a super robust way and then report on those data points, so anyway. That would be the short answer to that question apro or there are a number of prose or benefits to having that single person record persists as opposed to creating separate datasets.

Yeah.

Yeah, to keep talking with Sean and I are there on there pretty regularly. If your if your use case is really really specific and technical, jump on to the service desk, right? If that's more appropriate, but keep the conversation going. We're happy to keep the conversation going on RN. Thank you guys for being here too and listening and watching this.

This case we hope you found it helpful for sure, and you know we look forward to more conversations like this in the future actually.

Bye guys.