51ºÚÁϲ»´òìÈ

Transcript

Hey everyone, good morning. Looks like we’ve got about five people so far. So just in case anybody’s working out any logistics, do you guys all want to just put in the chat where you’re from, what company and where you’re visiting us from? Okay. Wow, from Scotland. Thank you for joining us. Time area. US Bank for Minnesota.

Spend a lot of time there. And then as we get started, if you just want to pop into the chat something you’re hoping to get from today, that would also be super helpful. And then I’ll just do a little bit of housekeeping and you and I will get started. So with today’s webinar, we will it will be in kind of presentation format and we one of us will be monitoring the chat at all times. So if I’m talking you and we’ll be monitoring if and vice versa. But please, if you have some burning questions as we’re going through a topic, please don’t hesitate to raise your hand or just pop in with a question. We’re here to help. So without further ado, this will be recorded and we will share out the deck and the materials after this is done. So if you don’t you don’t need to write notes furiously or anything like that. And if you miss a part, you will get the recording afterward. And if we start a little bit early, any late people will get the very beginning of this. So as we get started, I’m Tyler Holt. I’ve been with Workfront for 12 years in November. As you’ve probably seen in my bio, I’ve been using Workfront for 16 years now, I think. I was a customer prior to coming to Workfront and I’ve done implementations, strategic work, pre-sales, post-sales and Workfront is just a lot of fun for me. So Ewan, did we just? Yeah. OK. And then if you want to go ahead and introduce yourself, Ewan. Yeah, I’m Ewan Ruska. I’m based in Seattle. I’ve been working with Tyler for about three or four of my five years here at Workfront and 51ºÚÁϲ»´òìÈ. And before then, I was also a customer. I was an IT manager for a while. Marketing. Yeah, the whole gambit. All right. So today we’re talking about really the system admins and group admins and the guardianship of your system. And so we’ll talk about the difference between those two roles and some best practices, like you said, Quentin, around those two roles and really what to know when you’re setting up your system for future scalability. How do you build your Workfront instance so that future groups, when they’re coming in, it will be neutral enough that there won’t be any issues when you’re setting up the data. You want to do future reporting. You might have integrations that you want to do. And it’s going to be really a builder friendly and user friendly environment for everyone. So when we decided to throw this idea of a hierarchical system admin image into Firefly, and this is what it came up with on this image. There’s like five or six different options, of course, and you can kind of generate through more. I thought I did all right. Not too bad. We’ve got a couple layers here and you can see the different organizations and I did have to call out that there are both males and females. I couldn’t get images that were just males or just all I got were images that were just males or just females initially. So but eventually I got to this image and pretty happy with it, honestly. But where we’re going with this is actually looking something more like this. This might look a little complex. Don’t worry, we’re not here yet. We are focusing in on two of these areas. The sysadmin level in this conversation and then the group admins that are right below that. But this is part of a larger ecosystem. When you have a fully evolved enterprise work for an environment, it looks something like this. This is something that we typically see with some of our larger, larger customers. Many of you may have have an organization like this. One of the things that I like to call out on this is that while you have two sysadmins, typically there are kind of two roles within that. One is more process oriented and the other one is more technical, tactical. And that’s per instance. You really need somebody who’s really familiar with the instance that they’re working with. So if you end up with multiple instances in your organization, you may end up with multiple groups of those sysadmins. Anything else to add there, Tyler? I think you hit the nail on the head. This is aspirational. Some of you may be here already. What we’re really trying to say here also is that I think it’s really important to establish a really strong foundation of system admins and group admins. And doing so really does set you up for really strong governance. If your system admins are really empowered, then they’re really able to make the decisions of, is this going to put our system at risk? How is this going to impact us six months from now, six years from now? And so I really think it’s important not to underestimate the importance of truly valuing the system admins and the group admins. Especially within this practice. And so what we’re talking about here today, obviously, are the Workfront system admins and the group admins. So I really like to start to distinguish between those two roles. And so I’m just going to point out the differences that I perceive once you do build out that solid foundation. So I see the Workfront system admin, once that solid foundation has been built out, as really becoming a more strategic role within the organization. As you know, they will really execute the 51ºÚÁϲ»´òìÈ Workfront use cases. They’re typically the initial group that will build out your initial implementation. They’re really looking for the talent of the people that might become group admins. They’re the system guru with all the Workfront knowledge. Drive and change value and adoption, I think, is also really important. They’re the enable expert and the escalation point. And they’re the primary point of contact with Workfront support. And they may not be the person doing all the integrations and automations, but they really need to understand what integrations and automations are happening and be right on top of that within everything that’s going on in the system. So to make sure that nothing is conflicting with those. But wait, there’s more? Yes. And on that strategic side, I was talking about the really governing Workfront to make sure it’s scalable organizationally to minimize that risk, to preserve data integrity and to protect that usability. They’re an advocate for Workfront to both the executive stakeholders and to the end users. They have that ability to communicate the why, identifying the value of Workfront, and they’re truly a system guardian. So as I’m sure everyone knows on the phone today, the system admin role is the only role with full control and permissions in a Workfront instance. One thing that I did when I was running our Workfront practice was considering, I considered the sysadmins as an internal consultant. The more they felt like they were consulting and less administering and those administrative operations and tasks were delegated down through to the group admins, the better they were able to perform those more high level objectives and needs of the organization. So that’s one thing that I would take away from this is that the more you can elevate that role, the better. That’s a great point. A lot of companies are now calling them the product owners and elevated roles like that. Correct. And so the group administrator, while strategic for their own groups, it’s more of a tactical role. They’re meeting all the training requirements at 51ºÚÁϲ»´òìÈ. In order for us to be system admins, we have to take a best practices training. We have to become Workfront certified before we can even touch Workfront, the admin side of that. And I think that’s really important. The group admins really need to understand the impact of what they’re going to be doing if they’re making changes. They maintain the configuration, obviously, for their own groups. They understand the process needs of their business owners and their end users. They’re communicating any problems or any requests coming up from their business owners and their subject matter experts. So they’re really taking the heat off of the system admins, as you can imagine, with the large organizations we have on this call. If you had all of your end users coming to you, and you might right now, with all of the needs of the organization, it becomes overwhelming extremely quickly. But wait, there’s more, like you said, Euan. The high level strategy side of a group administrator is to really serve as the key contact config expert and adoption champion for the groups they support. And to act as that liaison between the groups and the system administrators to drive that positive change. Like I said, it’s really important they have that Workfront knowledge to be able to know what may put systems or the user experience at risk before they just start changing things. How to stop your group admins from going wild. And it’s important that they are able to communicate messaging to their end users about upcoming changes, releases, required training that the system admins may need them to be able to communicate to their users. When Tyler and I migrated over to 51ºÚÁϲ»´òìÈ, I think we were both sysadmins in our older system, and we moved into group admin roles. But the way that I think about this is that this is more process, they’re like process admins. If you think of them as being the people that are more in tune with the individual processes within Workfront and the sysadmins, and that differentiation between consultant and process admin are kind of ways that I think about these. They’re not necessarily official terms or anything like that, but that might help you distinguish those two a little bit more. And it kind of goes along with that distinction that we talked about when we showed you that diagram. I’m extremely process heavy. That’s my expertise. And Euan is extremely technical. He’s very good at fusion integrations and that kind of thing. And so talking about the process expert system admin and the technical system admin, he and I pair really well together in that aspect. So how many people do we need really here is one of the big, big questions. We typically will say two sysadmins, for instance. This has been a standard for quite a long time. We do recognize that there are often, you have a global organization, and so there may be some exception to that. But really be thoughtful about keeping that to a very minimum. A third is often, a third individual is often all you need to really cover a global footprint. Other considerations are how large are the groups? If you have really large groups, maybe you need to look at either breaking them up into smaller groups. Maybe you need to look at having multiple group admins for that size group. If the group’s really small, maybe a group admin doesn’t have to just have that responsibility. Maybe they can have responsibility over multiple small groups. Certain things like that are some things to keep in mind here. When it comes to scale, the number of users relying on the group admin is a key thing to understand. Other things that I think about here are the risks associated with it. The more processes, the more complexity in process that you’re dealing with, the more risk you have. So keeping that to a minimum, as with anything. One of the things I like to think about too when we’re talking about this, we’re talking about work front from beginning to end here. This applies to any system of record that you’re looking at. So if you really want to take this conversation and extrapolate from it, maybe you’re managing multiple systems. A lot of our customers, the same group that manages work front, manages all of their 51ºÚÁϲ»´òìÈ stack, or maybe even other third party tools. This same practice can be used for those. What we want to do is provide you with that same kind of armor. Now, they don’t always have the concept of a sysadmin and a group admin. But things like this, like understanding, keeping that small, avoiding risk, understanding the complexity in your organization, they really apply to any tool that you’re working with. That’s one thing I’d like to add with this point. Did I miss anything here, Tyler? Yes, I agree. That’s one of the most common questions that we get asked is how many do we need? It’s just not one clear cut answer. These are just some of those factors to really look at and consider when you’re trying to answer that question about how many do we need. Really, this slide is kind of your takeaway slide from this last section. Understanding that Administering Workfront is an ongoing program. It’s not a project where you just set it and forget it. Build for the long term success and expect the change. Take the time to find the right caretakers and anticipate that kind of change.

One of the most common questions that we get is how much access does a group admin have or should they get? What is really the level of access? Usually the question that comes to us is how much access does a group admin have? To really understand that, you have to understand that group admin is accumulative. It starts with a very base level and then you build out from that. Without any additional access, a base level group admin is really kind of limited. It basically gives you a view into things. There are a few things you can do like for your group you can recover things from the recycle bin. Other things like that. You need to understand that you can add on to that.

I consider the base group admin as if you’re in a situation where you need to assign a group admin and they haven’t gone through training. You can give them this level of access with a very brief training to get them started. But definitely limit additional levels of access when it comes to things that can actually make significant changes to processes. You definitely need more advanced training. When you look at group admins, the basic group admin, most of the toggles are checked for locks. When you look in the system, there are a number of different settings. They all have these lock toggles. They look like this image here on the right here. If those are toggled on, they’ll turn blue and the lock icon will turn unlocked. Basically what that’s saying is that now those group admins have access to change those settings. It gives you as a sysadmin delegation and it gives group admins more access to those settings. When you look at limited group admin access, there’s really two places to look. There’s those toggles that I just mentioned. There’s also access levels. You can allocate admin access to certain different areas. Just make sure that you look into and you understand the ramifications of providing those access. Some of those are quite significant, I’d say. I would agree. You can use that allow administrative access to enforce them to be able to only view the companies and groups they belong to. You can look at this to see what some of the high-risk areas are. There’s a lot of people that really want to regulate their custom forms, for example. In this picture, custom forms is not checked. Those are just the kind of policy decisions that you’ll want to make as you really look at honing in on what group admins can and can’t do. Then there’s some that will have a policy decision that you’ll want to make as you really look at honing in on what group admins can and can’t do. Then there’s some that will have a group admin one and a group admin two or full or limited or something like that. They really limit the amount of group admins that can touch custom forms, especially those with integrations.

Group admins can make group-specific changes by selecting their group name under the setup. If you go into the groups, it’s a long setup. If you go into setup for the main menu and you go down to groups, then you can see the groups that you have access to. From within that, it opens up a panel that looks kind of like this one that we have shown here. This is an IT group. From the left-hand nav, you can see that there’s a number of different areas that they have access to that they can change the settings for. Typically, you want to look at group members. You want to look at layout templates to start off with and which kind of bookends that list and then move into the center is the way I think about this. All of the areas are good to review as you’re setting up groups and making sure that they’re configured properly for your organization.

Also, a nice one-stop shop if you want to see all the portfolios that belong to your group, all the programs that belong to your group, those kind of things, instead of having to build in home group filters or group by home group and those kind of things. If you’re just really looking to audit your group, this is a really nice place to be able to go and do that as well.

When it comes down to right-sizing your sysadmin practice, you need to look at the size of the organization. You need to look at the access that’s provided. The question may be that now we’ve seen this distinction between system and group admins. Are there those opportunities for sysadmins to become group admins? Can you downgrade their permissions, I guess, to group admins? In order to secure your environment, keep it controlled, right? Are there areas where you can train a group admin on sysadmin permissions so they can act as a backup? Are you seeing the opportunity to distribute more of the effort to those group admins? Okay. I’m missing anything here. There’s just typically two kinds of people. You’ve got the system admins who are just completely overwhelmed, and they’ve got another job completely on top of it. There’s just so much to do. Really learning that the power of the group admin is eye-opening to them. I was one of these. There’s the system admin who’s worked endlessly and tirelessly to build this instance that they care so much about, and it’s their baby. They’re terrified of allowing group admins in their instance because they don’t want people to break stuff. It’s this sense of letting go of control in your baby or your instance. Really learning that, oh, okay, so I’m not giving away full keys to the kingdom. I’m really just getting myself some help so I can continue to do the really strategic stuff I love. That’s why we just really like to show you that you’ve got a lot more control than you may know. Some of these enterprise controls are really only two to three years old at most, and some of them are even newer than that. I wish I had a lot of those settings when I was trying to run my org before coming to Workfront for sure. Really the key thing here is just not letting your sysadmin staff turnover become a major event, a five-alarm fire, if you will. Having those group admins well trained provides a safety net. It provides you with that protective layer. So you’re prepared. Your organization is ready. It also brings career growth for everybody. It helps you develop your skill, gives people something to be proud about. And it also helps the ecosystem. It gives you that someone who’s a little bit closer to a process the ability to own and run their operations. And that’s what Workfront is built for. It’s built for managing your processes. Absolutely. So as we talked about, we’re just going to cover some of the foundational knowledge that you need to kind of know when you’re going to be opening up possible group admins or just sharing some of that knowledge. So when you’re building for enterprise scalability, some people may be asking, like, what does that even mean? It just sounds like a buzzword, another corporate buzzword. It’s really just looking at how do we assess the long-term impact for future group onboarding? How do we avoid configurations that are going to limit adding new group processes? And how do we build standardization for our data, our data-driven decisions, process autonomy? And then how do we follow best practices to just avoid costly mistakes as our organization grows, to avoid rebuilds, to avoid having to go back and bring in more consulting, to be able to have to really rethink how the structure was thought of in the first place. So this, I won’t read this whole thing. This is just really a one-sheeter to be able to look at a very high-level summary of the primary work components. A lot of people just want to know, how do I use these? What’s the best use case? These are more just a summary of pretty much the most common use cases for each of these objects. And we’ll go into more about companies through job roles. I don’t really discuss portfolios and programs here because there are so many unique use cases for different companies.

So for organizational setup, we first talk about companies. The things to know about companies is that they are tied to organizational structure. Why that matters is because you can’t have a person that reports to a manager in a different company. So if you want any kind of manager approvals or manager timesheet, that is an approval. If you want any kind of reports that say for your managers, we have a manager, people manager dashboard right now that just came out as a blueprint. If you want anything for your people that report to me, all of that would be broken. And so that’s a really important use case for companies. And then other potential uses for companies are any external people that you would work with. So contractors, freelancers, agencies. And then you may have people that will have billing rates that you may be using. So you can add different billing rates for people in different companies so that you can estimate project costs or you can see total project costs. And that actually helps sometimes even if you’re not billing out. So you can measure in the future what kind of cost, what kind of project costs are we experiencing? And how can we save on some of those project costs just to have a really good data point? When we look at groups, they’re kind of the next level down in the organizational structure.

Really the key things to understand is that you need to understand groups. You need to understand the way that they’re built out. Understand that they’re not an assignable object.

It can restrict user access to information relevant only to that group. The objects can be shared with those.

A lot of times they’re the highest level department. They’re also lower level departments. So you can have up to 14 groups, group levels. And so those are set up hierarchically. A lot of times you’ll have like a marketing, you know, if we’re using the marketing use case, for example, you have marketing and then you have your creatives. A lot of times they’re underneath that and then your studio and then your designers and, you know, and it could be those could be your groups. Not to get confused with user roles. So be careful. And teams. And or teams, right? Teams are assignable. Teams can be cross organization. They’re an assignable object is really the key thing there. Anything I miss here? Yeah, it’s just you do want to be careful about getting too granular with your teams if you’re using them for access. Because your subgroups are just going to inherit the permissions of the parent group if you are not going into every single subgroup and changing specific settings. So just knowing that groups are really departmental. They may be different user type groups, but you really like you said there, you can’t assign work to groups. You can assign work to teams and job roles. So that’s that key distinction. We really look at using groups for access and the group admin function. And then we do resourcing by teams and job roles. And you can find a few of the groups that can be added via the Blueprints area. So you can do some of the setup directly from the Blueprints area. It’s a good place to start if you’re not sure where to begin.

Teams are one of the primary functions of primary functional areas within Workfront. A user typically has a home team as well as a normal as well as multiple teams that they’re assigned to. I have like 15 that I’m assigned to for some reason. Not sure why. It’s. You can only ever have one primary assigned team is a key thing here. And they don’t appear in the Workload Balancer. So if you want to manage your work, you need to manage it by the individual. Within that, if you’re using most of the resource management tools. What are some of the other key things here on Teams? I’ll just call out the different types of teams. You can have that collection of functional job roles. So the back end development team, the program management team. You can have the request intake team. So those that are fielding requests from a request queue. You can have team members that are dedicated to products or customers. So I saw someone from PNC on here. So the PNC product launch team. And then you can actually use teams as distribution lists. So a lot of people really still want to look at emails. We are trying to get people out of really relying on emails. They get missed. Some people just kind of get so many too many notifications from Workfront. And so they tend to just delete them. So we try to get people relying on dashboards and their notifications in Workfront. So people will start putting their distribution lists as teams in Workfront. So that can be really super helpful. And the last part that I really like to just put on here is because you can assign work to both job roles and teams. I really like to put team at the end as a naming convention because those little icons at the beginning of the job roles and the team names are so small that it’s really hard to distinguish sometimes when you’re making that assignment, which is a job role and which is a team. So that helps project managers and others who may be making those assignments that they’re making an assignment to a job role and not a team or vice versa. Good tip. So then job roles are the functional working roles. Multiple roles can be assigned to a user. There’s typically a primary job role and then there are additional ones that are assigned. Roles are kind of a key function for advanced resource management. Even some of the basic resource management. Also for assignments, if you’re using templates, assigning job roles to template tasks is a really good place to start because you can then get an understanding of the impact of those projects. And then you can just reassign from within those roles. You can actually use the people tab inside of a project to assign to those roles, which is kind of a thing that’s been lost to time. But it’s a nice function to have actually because you can actually do all the assignments all at once that way. And what is this exception we’ve got here? If roles are skill specific, technical program management, creative, make sure that you assign them separately. This is essentially what this is saying. So statuses. There’s going to be a lot on statuses because you can really, really mess up statuses. So we’re just going to cover this. I’m going to go over this kind of quickly just for time. So when creating new statuses, there’s just going to be a few things you’ll want to keep in mind. You’ve got the three digit key. And it’s important to keep in mind that that three digit key when you are using reports, sometimes the three digit key, you’re going to need to know that. And it’s also used in the API when you are doing status work triggers reporting that kind of thing. So you will want to make sure that when you’re creating new statuses, you pick a key that will kind of make sense to you. And sometimes the system generates a key that has nothing to do with the system or the status that you’ve just created. So you can change that before you save it. And another thing you’ll want to make sure when you are creating new statuses is that equates with column. I’ve done this many times, just in a hurry trying to get stuff done. You’ll also want to make sure that the status equates with the correct status. So if I create a request queue status or a queue status, I’ll want to make sure that that is equates with current and not new because that will impact the way that that project functions. And so if you do that and you save that status, it will actually, you can’t go back and change it. So then you have to delete the status, go back and make it equate with the correct status. And speaking of that request queue status that I would be creating, it’s really, really important to just talk with admins and with group admins about semantics and personal preferences. If we’re wanting to create similar custom statuses across groups, let’s just collaborate. If someone’s wanting a request queue status, someone wants a queue status, someone wants an intake status, someone wants a request status, let’s just get together and figure out one status for all of those and make that stick at the system level. Otherwise, when people are scrolling down through the statuses, it can be a complete mess. Also, when people are doing status reporting, the options can be very, very confusing if there are a lot of custom statuses in the background. And so here, again, I’m just saying don’t let personal preference drive the statuses that are being creative. This is just kind of talking about the required locked and unlocked statuses. So your required statuses are the statuses that you do want everyone in the system to see. The locked statuses are the statuses that you do want. You’re making sure that required locks, you’re still making sure that everyone will see them. If you’re just locking them, you’re making sure that group admins can’t go in and change them. And if you don’t have them locked and they’re not required, then that makes it so that group admins can go in and customize them for their own group. So this can get messy. That’s where you could have an instance where if you have that request queue status at the system level, and it’s not locked, all of the different groups could go in and customize it to be 60 different versions of request queue. So if they’re going to be statuses that are used at the system level that will apply to all or most groups, I would just lock those. And so you won’t have that kind of mess there. And the other important thing to know is that unlocking previously locked statuses will impact the historical data and it will change to the changed statuses that you have that are now reflecting in Workfront. Yeah. And so some people aren’t just sure what default required and optional statuses mean. This is just saying that you only have to show active, planned or complete. Active is the same as current, so you can choose that. And then your optionals are dead, requested, required, on hold, approved, and idea. So if you want those dead, people hate the word dead, so we’ll typically do canceled instead of dead. And then if you want to, people will often show canceled and on hold at least within their process. So that’s a way you guys can just go in and say we want an equivalent to some of the optional statuses to show up in our list as well. So that’s really here just also just to be able to coordinate and make sure that you guys are not adding to the list as well. And you kind of have agreed on which of these statuses do we want to use moving forward as well. This here, again, is just really saying if the group statuses are being created, I think I just have overemphasized this talk as a group. This is just showing where it’s kind of an educational piece. This slide and I believe the next are just more of a guide of how to do these. And it’s more for the group admin things to know if this starts to occur, customizing statuses. So this is just a navigational guide also. So with this, this is another object that can get very out of control. And so I’ve just put together a little guide on a good way to think about access levels and layout templates. There are a lot of similarities between the two. So at the top here, I’ve got some things that are in common when laying out your access levels and templates when creating them. It’s the best to not delete their originals because they are created for a reason. And then when you are creating custom, think of them at the persona level. Don’t create them for each job role or team or individual. Don’t let reporting drive your access or your access levels. It’s typically not necessary to customize them by groups or teams and then keep a documented log of the settings of each to prevent duplicates and over complicating the settings. And also use the description field to specify what makes each unique. And the reason we say this is because when the group admins go in, they don’t know some of these exist. And as I’ve gone through with other customers, we’ve seen like five, six, seven of the same exact access levels and layout templates being created because they don’t have, they don’t want to click into every single one and see like, is there already one that I need? And so they just create new ones. For the access levels, we showed you this earlier when giving a cumulative access to the group admins. Using that allow administrative access for and set the additional restrictions does provide those greater controls for both limiting what users can access and how group admins can support. And then using the above settings can partition the information and separate companies and what companies will see in Workfront. So if you do have external companies in Workfront, you can lock that down. So you’ll completely be, they will not be able to see anything unless you have shared it with them. Same practice really for layout templates. Recommended personas are listed to the right. You can look through that list and then if you have any questions, you can always just reach out and ask. We’re going to skip ahead a little bit here due to timing constraints, but we will make this, I think we’ll make this deck available for folks. There are a few more slides that talk about enterprise controls, custom data and how to deal with custom data. But we wanted to make sure that we covered some of the blueprints that are available. We have a number of blueprints that are available for system administration. These span what we call the core value dashboard. They’re focused on getting the most out of Workfront, essentially the core value. The review and approve dashboard is focused on people that are doing approvals, if they’re running approvals through the system. Client facing services are for agencies and other teams like that. If you have any external vendors, there’s some value that you can find out of that particular dashboard. And then governing compliance, which is really, it’s managing the, you know, if you’re in an organization that work compliance is really important. Take a look at all these. One thing with blueprints that’s really important to understand is these are, there’s a number of best practices, but they’re built for a broad audience. You may not need to use all of them. You may, but you will likely, I would say, find value out of, you know, one or two reports out of each of them at least. So, highly, highly recommend looking at blueprints and these various dashboards that we have built out. And the client facing services dashboard, the only thing that makes that client facing is that the reports are filtered by not the, it’s another company. So there are some really helpful milestone reports in there and a few finance reports in there and some resource management reports on there. So I would definitely take a look at it just because it is really helpful. It’s just filtered to be an external company.

This one, we’re going to just highlight the main thing here is really, make sure that you ask the right questions about your processes and how they’ll be managed. And document those, really document what those outcomes are. We also want to just note that we have, we had about 15 slides on request queues here. We just want to make sure that you understand that there’s request queues available. We recommend actually using request queues for your admin work and those requests that come in for both your group admins and your sys admins. It’s a really good way to manage your work within Workfront. It makes it so you don’t have to go to a different system or keep a log someplace or something like that. Just build it into Workfront. Use the tool that’s in front of you. Because we only have, we only have nine minutes left. I want to take a chance to look at people’s questions. Tyler, do you want to wrap up on these last few slides here? Yeah, I think the answers, I think the questions have been answered. You can take a look at the last one in the two system admin model, would you expect? And then I’m saying I think it’d be an internal process, but if you’d like to add to that. And then I will just hurry and touch on the, there’s also system maintenance dashboards as well. So there’s a cleanup schedule dashboard. Then there’s also a system administrator maintenance dashboard. Oh, sorry, Workfront usage. So those are also very helpful, especially if you’re doing a system audit. There’s guidance on building out a maintenance schedule. This is basically, you’re basically building out a roadmap for your sysadmin or group admin work. So you make sure that you check everything throughout a calendar year. Basically the recommendation is that throughout a calendar year, you’re looking at every part of your system and you’re going through some kind of an audit, some kind of depth. We also have another funny image from Firefly and a sample admin agenda. We’re not sure exactly what she’s holding in her hand, but it looks like fun. Projector thing. When you look at, when you’re getting started, sometimes the agenda can be really useful for understanding what are some of the typical things that we need to look at at a recurring basis is really what the key takeaway there. And then as far as what the next step is, the system admin journey is establishing governance and building from that. Without sysadmins, you really can’t build out governance because you don’t have anybody to maintain the system. And I think this speaks to your question, Jonathan. As admins, I do think you’re really building out those requirements and the ways to build out new request queues, templates, dashboards. But as you evolve into a governance committee, I think that then evolves into a higher level process. Kind of both that request queue you showed, are we having people request new request queues be built? Are we, the request queue kind of showed, are there things that can be built that just, it’s information only? Are there some things that can be built that we just need the approval of the group admin? Are there things that can be built that just need the system admins approval? And so it really is going to evolve within your organization. And then, so we want to leave you with a couple more events that are coming down the path. August 22nd, we have the fundamentals of AEP Marketo integrations. August 23rd, we have the content acceleration with AI empowered copywriting. And on August 26, we have the real time customer data platform getting started. These may or may not apply to you, but let your fellow employees know about them that are maybe a little bit closer to those processes. We have a lot of materials that our teams put together and they’re worth checking out. When it comes to this presentation, we want to thank you for your time. If you can fill out the survey, the QR code should be on your screen now and as well as the link to the form. You can fill that out. That’d be greatly appreciated. I’m going to leave that up and see if I can look at any questions that may be coming in. If you have any questions, please put them in the chat at this time. If you haven’t already. There’s the link in the chat as well. If anyone has any issues with the QR code. Any burning questions about group admins or sysadmins for that function? I’m curious what any of your models are currently. Do you guys have mixtures of system admins and group admins? Are you system admins only? OK, well, it looks like people are dropping off now. I want to thank you for your time and we will see you next time. Stuart chimed in. OK. Very good. That’s probably one of the hardest things to manage is the skills that different users have. Sure. Thanks for chiming in there, Stuart. There is a slide on there, Stuart, that does show some enablement and a link to our enablement site as well. So hopefully that can help you. You can always speak with your account representatives as well if you’re looking for anything like boot camps or certifications or anything like that to level anyone up. Thanks, Felicia. Good to see you on here. Thank you. Appreciate you all. Right.