UFG Success Story Video: United Fire Group on Enabling Self-Service Automation

I have over twenty years in the IT industry, ten of it in IT management. Started at Gateway two thousand for those of you who remember Gateway two thousand. But since then, I've done desktop administration, server network, security, backup, all those administrations, infrastructure and operations supervision, and a little bit of DevOps experience. What is United Fire Group? Is it a fire station? Why do they need IT people? No. UFG is actually an insurance company. Stands for United Fire Group Insurance. It's headquartered in Cedar Rapids, Iowa, and it's publicly traded on the Nasdaq. We're an insurance company with zero debt, which is really hard for companies nowadays to be at a zero debt company. And we have around twelve hundred employees. That, over the last five years has almost doubled. So we went from five or six hundred five years ago to twelve hundred now. Why we chose Stone Branch? We had a lot of interesting challenges and drivers here. We have an environment that's mixed. It has Windows servers. Originally, when I got here ranging from two thousand three to twenty sixteen, but now two thousand eight to twenty nineteen. We have a Unisys mainframe, and then we have a bunch of Windows PC and Macs. The mainframe itself already had a scheduling tool. It's called BL Sched, and we continue to use that today. It's been very effective in that environment. But what we found, you know, we were able to centrally control it as an operations team, and we could run a few windows tasks with it, but it didn't have a lot of additional functionality to do all the Windows tasks that we now have with our Windows servers. Let's get into our business requirements a little bit. For us, it really came down to trying to get a centralized solution, something where we could pull everything together and see what was going on in our environment. We wanted some newer technology, not something that was built strictly on the mainframe, but something that would cover potentially all Windows servers and then potentially, the mainframe as well. So the newer technology we wanted needed to cover PowerShell scripts and batch scripts, SQL stored procedures and SSIS packages, Cognos pass, and then do FTP because a lot of our file transfers between the mainframe and the Windows server environment are all done via FTP as well as many third parties still send and receive files with us via FTP or SFTP. We additionally needed security to protect the IDs and the tasks that are being run. We need to make sure that somebody from, say, our digital web team isn't necessarily going to be able to use the SA account on SQL and run some query or run some tests they shouldn't have access to. So security was big at the forefront of this. All right. So let's talk a little bit about business services and security. Groups are key. In fact, groups are a requirement. Here, we're using a little bit of a hybrid where we have a group that people can have access to that gives them access to the StoneBranch application, but doesn't give them access to any task. We then would add them to a local group at that point to give them access to the tasks and the things that they need access to. So groups are key. Local groups are the best way to handle this because you can keep control of who has access to those kind of things. Just some some key point to keep in mind there. We wanted to limit visibility. Right? So business services themselves allow us to do that. We can set people in a group with a business service, and the only thing they're gonna see is what's assigned to that business service. And we can do that from multiple perspectives. We can do it from just the task level. We can do it at trigger levels. We can do it at, even agent levels or calendar levels, those kind of things if we want to. And then we want to make sure we utilize naming standards. Within this system, it's very difficult from our perspective it was very difficult to just turn this loose without having some sort of naming standard. The reason for that is twofold. Number one, you want to make sure you understand who's really utilizing the system and number two, you can't have identical names. So by using a naming standard, you're going to try to prevent people from trying to create tasks with identical names and then getting frustrated because quite honestly they don't don't have what they need or they aren't able to save what they want and it just kind of gives them that I don't know what I'm doing and I don't like what I'm doing. So setting up access and functionality on a business service there's really two pieces to doing this, and and these apply at the group level, their roles and their permissions. Roles is basically groups of permissions. So maybe it's a a role that deals with the dashboard, but these are permissions that deal with what you can do on the dashboard. Permissions are the fine tuned piece of this. So permissions are the individual sections or pieces. For example, you can create a task, but you can't execute it. Or you can read a task and you can execute it, but you can't update it. These are all permission level items where you can do specific things to something, but you can't do everything you wanna do. And and they get very granular. Permissions themselves, as well as roles, can be applied both at group and user level. But let's actually get in to Universal Controller. I've actually signed in here already. So let me get back to the dashboard. And as you can see it in the development environment, obviously, things are gonna fail all the time because that's what they do. That's what development's for. But let's talk about this environment a little bit. Talk about how much as an administrator we can see. I mean, there's a lot of things here that we can see, from all the tasks, instances, triggers, those kind of things. You get into dashboards and reports here. You get into agents and system stuff. You get more into system configurations. A lot of this stuff, your bundles and promotions, a lot of the stuff you don't want the end user to be able to see. It's going to confuse them. It's going to make them look at this and go, I have no idea where to start. I don't really wanna do this. And the end goal really here is is really democratization, right, of the product because the point being you want people to be able to utilize this and to utilize the automation within it to move their business forward. So you really want to reduce the complexity of it and the views and and how things are done so that you can enable them to do what they need to do effectively. In this case, like I said, as an admin, there's a whole bunch of things we can see. Now for the purpose of this demo, I also created a test user, and I'm gonna show you what the test user is going to look like when we actually put them into a group and put them into a business service. But before we go there I want to talk about how you actually set up business services to start with. So business services themselves are all under the administration tab and under security right here. And really when you look at business services, you're setting one up. There's really nothing to it. It's a name and a description. That's it. There's no security. There's no way to add people to that business service. This is all there is to it. So to accomplish the security piece of this, you do have to utilize groups and groups are right next to in the services here under security. So when I look at groups and I'll look at the digital and then and then digital non BS, and no, that does not stand for what you think it stands for. It's non business service. But as I look at these, I'm gonna talk about the roles a little bit here and show you the roles and the permissions and and how they can change and how they're different. So as I look at the digital non BS or non business service group, let's start here at the control navigation visibility. This is where you control what they can see in this navigation pane. Back to where I was at on the administration page, your business services, your groups, and your users are all listed under security of of the administration page. Your business services are literally a name and a description. That's all you can do to create a business service. You don't actually set your security on the business service. You set it on the group. So when we get into groups, I have two groups here I'm gonna take a look at. One's digital and one's not digital non b s, which is not the BS you think it stands for. It's not business service. But as we look at this group, you put your name, you put your description in, but we wanna control what they see. And you control that navigation visibility right here on the group by hitting this check box and then coming in and selecting the items you want them to see. Now there are certain things that I know they're never going to use, like Linux and Unix task because they don't have any Linux or Unix servers that they're going to use or ZOS tasks or SAP and PeopleSoft. So you really want to, not show those kind of things because it's just more clutter that they would have to go through. But there are things like file transfers or manual tests and timer tests that you want them to be able to handle and be able to do. So those are the ones you select and whichever you have selected here is what's going to show up on this left side when they sign in. And we will look at that here in a minute when I actually utilize my test user to sign into the environment. Now group roles. We talked about roles a little bit earlier, and we talked about how they're a group of functionality that you can utilize. So in other words, you don't have to put individual permissions on things. You can actually grab a group of roles that already identify what you want to do. For example, there's a dashboard group right here and a filter group. So the filter group lets them do filtering, and a forecasting view group lets them actually see the forecast of jobs that are going on for their for their tasks. But these are groups that I felt for our environment made sense for what we wanted to try to do and what we tried to want to accomplish here. And then when we get into permissions, this is where it gets really individualized and and very much, I guess, you you identify what you want them to do and don't want them to do. So for example, as we look at this, this is the type of task, and obviously there's all of these different things that you can add. Right? But the type of task and I can tell them, if I only want read, well, then I just give them read access. In this case, this is a development environment. I don't care if they do anything they wanna do with their work. I'm all good with that. But additional, besides create, read, update, or delete, you can get into commands for what can happen on this particular type. So as we see here, you can copy a task, launch it, recalculate forecast, so on and so forth. Well, these commands are going to change based on your task selection. So if I go back and do agent, for example, this is all I get for agent. Or if I go into triggers, then I get this for triggers. So this is all going to change based on whatever type you select. And this is how granular you can get. Now, the interesting part here is that I have one type all the way down with the exception of calendar, which I have two. And the reason I have two for that is because I have one that's for anything that they create that's a digital calendar, But then I have a set of universal calendars that they can just use and not have to worry about them changing. They're always gonna stay the same. So I give them read access to the universal calendars because a, I don't want them changing the universal calendars if people are using them. But then for their own digital calendars that they create, I'm giving them the ability to create, read, update, or delete. So you can have multiple lines in here for the same type and allow them to do different things for different types of items that they're working on and whatever business service or name they're working on. Now if we look at this again as a task and continue down I give them all access to all the commands by default it's set to none. So you could give them create, read, update, and delete, but they could never launch the task because they didn't have that command. So these permissions can get, very tricky a little bit. You're gonna have to work with them a little bit to make sure you're getting what you want out of them. But if all I want them to do is launch, I don't choose all. I just choose launch. The name is what it's going to allow the task to be. So in this case, I'm saying, give me tasks or let them utilize tasks that all start with digital and then anything else after it. And that's good because I don't want them seeing maybe something that's SQL or something that's maybe HR. I want them just to see digital. But notice as this is the non business service task, I did not add the business service here. I left it strictly as a naming. Now that's great if you can get everybody to wanna continue to name their things exactly the way you're asking them to name them. And and by doing this, they're required to have digital something. But in our case, maybe we're not going to have agents that are digital, or we're not going to have calendars that are digital, or we're not going to have, scripts that all start with digital. And that gets a little trickier because if I come in and I say, for example, my credentials, here's a great one. Credentials. You're not gonna say digital dash this credential. You don't typically say that. You just wanna put down this credential. So as I'm setting these as a individual or setting this for this group, I would say, well, then I want any any credentials. I can do anything on this. Well, that's a problem. Right? Because if SQL team puts in an SA credential, you don't want them to be able to do that. And most times you can say, no, you know what? If you wanna use credentials, you have to do it this way. If I look at the digital side, the now the business service side of this, I still control visibility and I control it right here. But then as I look at my roles, they're all the same. As I look at my permissions, they're very similar. And I'll say similar because they have all the same operations. They have all the same commands, but the names are all asterisks. So first thing you're thinking is, they're going to see everything. Well, not really. Because if I look at the triggers, they have to be in the digital business service in order for them to see it. So I took away the need for them to have a certain name at this point, but just said if it's in digital, you can work with it. All right. So a lot of talk. Let's kind of look at what this looks like from a, user perspective. My users are actually pulled in through active directory, and I have a test user that I actually created, that is strictly a local user on StoneBranch, but I wanted to kinda show you an equivalent of what that's gonna look like. So right now, my test user has no user roles. They're not a member of a group, and they don't have any permissions. So what I'm gonna do is I'm gonna add them to the business or digital non business service group just so we can take a look at this. Now as you see, when I added them to that, there's some user roles that popped up. Those are all coming in, and it tells you where they're getting those user roles. So when you add them to a group that has roles already attached to it, they're gonna show up under that user so you can see where they're accessing or getting access to particular roles right away. What you're seeing here as well is you don't see permissions because these permissions, when I add permissions in here, are for this user and not for the group. It would be kinda neat, in future enhancement requests, that if we were able to actually pull in the group inheritance in here as well. So you could see what permissions were inherited by groups if they're if they're still using them. Alright. So we've added them to non digital our digital nonBS user group. Let's go ahead and let's pull up an incognito window so I can sign in as this test user and put in my super secret password. And the first thing we're going to notice is because I limited the visibility, we only have four tabs up here instead of five. I didn't give them access to the bundles. But even looking at these, you don't see the ZOS task or you don't see the SQL tasks in here. You don't see a lot of those extra things that you don't want them to be able to see. I go over to reports, they can see reports. I get into the system and wow, there's only three here compared to what we saw. And let me go back and show you again in system. All of these were originally there, but now because we reduced that view, we only see the email templates, the database connection, and applications. So that's what the limit visibility option is doing for us, which is is a really good thing. And then all I have is audits and video classroom. So there's no way for them to add to the group or add a user or, you know, basically add a business service if they want to. This is all they're gonna get. So this makes it much easier for them to see what's going on. And they can also see only the things that are actually running or waiting in this case in their group. So this is just digital. So they have a digital task. Right? A file monitor, agent file monitor running. They can see that. Now if I look back at the administrative side and I went to the dashboard, there's actually seventeen different things that are running right now. So you're you're really reducing that footprint, really reducing what people are going to see, and that's a that's a good thing. It helps keep the clutter down. Let's look at the tasks. So when I look at this, there are only three tasks here. Reality, and and some of this is tweaking and setup. This is not all the digital tasks that are out there. In fact, there's a number of tasks that are out there just because they're business service digital tasks, but they're not showing up here. So I'm gonna flip over now, and I'm gonna show you what that looks like when we go to a business service and utilize business services. So I'm gonna come back over to my groups. I'm going to refresh because my test user and you can do this from the group level or the user level. But my test user is in this group, so I'm gonna edit and take him out. And I'm gonna go to the digital group that is utilizing the business service, and I've got two people in there already, but I'm gonna add my test user to this group. And then I'm gonna flip back over, and I'm gonna hit refresh. I'm not even gonna log out because I switched some groups. I'm just gonna hit refresh. Now it's applied as new security as a business service and I'm seeing thirty seven tasks in here and every one of these tasks have digital assigned to it. Okay. Well, now you're looking at it and say it, okay, well, is all great and good. And what happens if I have a task and everybody has these, but what happens if I have a task that covers multiple areas or covers multiple applications that covers multiple business units? Very easy. They can actually add that by clicking on the business service and adding that other task. So for example, I could add this to SQL DBA and now SQL DBA group and the digital group would be able to see this task. That works out very, very well for tasks that, you know, multiple groups need to see. Now, the other side of this is, okay, what if you have that user kinda like myself, who has been a jack of all trades, and not only are they doing digital work, but they're also doing SQL work. So they need to see all the SQL stuff, and they need to see all the digital stuff. Well, in that case, you're not gonna go to every one of those tasks and add SQL DBA to these tasks because you don't want the rest of the digital people to be able to see the SQL DBA test. You just want, this this one person to be able to do that. So I'm gonna get rid of this. I'm gonna go back over to the administrative one, and we're gonna say, okay. Well, you're part of digital now. Let's add you as part of SQL DBA as well. So I'm gonna come into group members. I'm gonna add them, and I'm gonna pull down here to the test user, put them in. And now that I'm in here, I'm gonna go back. My clicking's a little slow this morning. And as we started with thirty seven tasks, I'm gonna refresh again, and now we're up to forty six tasks. And what we can see is we have digital tasks, but we also have a couple of operations tasks that showed up. Why? Because digital was part of that. We have SQL DBA tasks that showed up because we've added them to that SQL DBA group. So now this person who does multiple jobs or covers multiple areas can now operate within both of those areas. Now one of the issues we had with the initially with business services and, and really rolling this out to, to the end user populace is when they would create a new task. For example, let me go to a windows task and I'm just going to call this test. And I click on the dropdown for business services. I see every single business service that's in here. Okay. That's great. What happens if I clicked on SQL HR and says SQL DBA and I'm not part of that group? Well, when I would try to save it, it would tell me, well, than the fact that I don't have an agent field. So let's put an agent in here and a command field. So I'm just going to say test that back because I'm very creative that way. I'm going go ahead and hit save and it's going to kick me back and duplicate value task name must be unique. Well that's my number one problem so let's do test for digital or in this case since we're doing SQL SQL. Let me save it. Operation prohibited due to secure security constraints. Well, why is that? Because this is not a group I'm a part of. They can only select a group they're a part of. I selected again. I hit save. I still have security constraints. So there's other things in here that I've selected that they don't have access to. Okay. So to give, to go back on this a little bit, but to look at, business services, there's a lot of business services in here. There's a new feature in six dot eight, and thank you to Stone branch for doing this, that allows under the system properties to restrict the visibility of business services unless you're a part of them. So if I come in and change this to true, k, and now I go back over and I refresh. Yes. I know it's been modified. I'm gonna refresh. Now if I come back in and I can look at a common this a common one. No. I can't look at a common one. I must have to do a new one. See here. Now it's reduced them to just the stuff that I have access to. So there is no need to, scare them with all the business services. You can now reduce this so they're only gonna see what they have access to. With that being said, that's it. So thank you very much.