Automate Workfront user account creation with Fusion

Transcript

Welcome everyone to my presentation. I’ll be talking today about Automate Orkfront User Account Creation with Fusion.

Our agenda today, I’ll give you a little bit about me, some of the tools that you’ll need to actually make this Fusion scenario work for you. I’ll give you a little background on the use case that we have for JP Morgan, and how we came to develop this solution. We’ll talk about work front form that we’ll need as the starting point for our overall automation. We’ll talk about the user management API and how to set that up so that you can connect to your admin console. We’ll talk a little bit about the admin console and the groups that you’ll likely have or that you use today for your users. Then we’ll get into the me, which is the Fusion scenarios. I’ve broken that down into a few different pieces, so they’re a little easy to digest. Then finally, we’ll do key takeaways. A little bit about me. I’ve worked with Workfront and Fusion for about six years in general. I am a Colorado native.

I have a lovely family of four, two college-aged daughters, as you can see. A fun fact about me is I’m an identical twin. If you can’t tell, I am the one on the right. If you want to connect with me, you can use the QR code and that will get you connected to my LinkedIn profile and we can chat offline as part of our network.

Today, the tools that you’ll need. You’ll need access obviously to your work front environment. You should have access to a work front Fusion environment and be able to build scenarios. You’ll also need access to your developer.adobe.com console. You get that basically by having the developer role attached to your account in the admin console. Then finally, you need actual access to your admin console so that you can create users with your scenario. Our JP Morgan use case, this is what started it out for us. We use work fronts across our company, mostly in marketing areas. We support about 9,000 users across those multiple instances that we have.

Now, our specific use case today, and what we’re going to talk about is the challenges that we had. So we had issues in terms of needing to have data input into multiple systems. Our company does require us to use ServiceNow as an IT process for all requests for all software. So that’s always the starting process. For a user to request access. From there, it then gets passed off to basically the application owners, someone like myself for work front to basically do the work front potential pieces that are needed once you have a company approved approval. So we would have to take data from that system, put it into work front, put it into admin console, come back to the work front environment, profile of that user and put things like teams, groups, schedules, all that other good stuff. So for us, there was a lot of cut and pasting and a lot of bouncing around to multiple tabs and multiple systems. We’re not allowed at least today to use auto provisioning for what they call line of business applications. So that was an option we just didn’t have to be able to connect our Active Directory to auto provision users. We wanted to also provide a little bit of self-service. We do get a lot of requests for folks to put in requests to our marketing teams. We have a lot of teams that we work with across JP Morgan. So being able to allow users to do a little self-service, was also one of the challenge we’re trying to solve.

Ultimately, what happened for us anyway, is as we built this scenario, we had some significant impact. We took roughly about 22 minutes to create a user. All that cut and pasting from various systems, reopening, work front, editing, adding all those different teams, schedules, things of that nature roles, would take us. I’m not the fastest typer or the fastest cut and paster. So took roughly about 22 minutes and now through the automated process, it takes a little less than 60 seconds. We provided basically the ability for users to self-submit, so to speak, and be able to create their account using this process. It helped us also improve some controls just inside the company. Having the automations basically attach groups, teams, so on and so forth, so that the right access was essentially done by a system as opposed to a human. So let’s take a look at what we’ve got.

Let’s jump in and let’s go. So the first part, building a work front form. So we have a very simple form for the most part, that basically has the required fields needed for our scenario. Things like first name, last name, your email address.

We’ll see this in a little bit, but the user management module does require a two-letter country code. And so that was a new field for us. We also provided basically a URL for our users to be able to find the country code, because not everyone knows the two-digit country code for every country that we have on the globe.

Outside of that, most firms also have SSO established for the users. We do too. So we needed some information for our SSO as well. But in general, our form looks just like this. First name, last name, our country codes, the email address. And then for us, we had a role, and then we denoted whether this was a user inside of our payments marketing team or whether they were an outside user. That helps us identify what group we want to put them in for admin console. Our step two is connecting to the user management API. So this is the step that you’ll go to developer.adobe.com. You will see a prompt basically on that screen or a little icon that basically says create a project. You’ll click on that. You’ll see another little icon on the next page that says add an API, add a plugin. You’ll click on add API. From there, you’ll get a list of basically all the APIs that are available to you, and one of those should be the user management API. You can scroll to the upper left corner. You’ll see a check box that you can check and then a button for next to basically add that API module to your developer console. You’ll then be asked to name your credential. Give it a name that’s appropriate, that makes sense to you.

You’ll have a button that will come up asking you to generate a token or if you need to generate a token. And the key pieces that you’ll see on the screen, and you can see what those pieces are on the right, the items that you’ll need for the Fusion scenario, the client ID, your client secret, and your organization ID. Those three pieces will be critical, so make sure you make note and at least know how to get back here so that you can get those items to use in your Fusion scenario. From there, you just need to click the edit project button in the top right and give this project a name that makes sense for you, something like user access creation. That’s it. You’ve now created basically a connection for your environment to use the user management API.

So let’s move on to step three. This part should be pretty straightforward if you’re already using Admin Console and you need to be using Admin Console for this to function.

You should already have likely established groups for your users. So you’ll go to adminconsole.adobe.com, click users up at the top, and you’ll see on the left-hand side a selection that you can choose for user groups. And that should give you a list of all the user groups that you have. In our case, we have two main groups that we use. We have a group for basically regular users or your standard users, and we have our group that we use basically for contributor or requester users. So for us, just two groups. And what we need are basically the IDs for those groups. So you can see on the right-hand side or my right-hand side up on the URL the ID for one of the user groups. This happens to be our collaborator or our requester group. And that’s the ID that we need to get.

And then I would navigate basically to our standard user group, get the ID for that, and I would have basically the user groups that I need. Step four, this is the overall Fusion scenario. The first part that I’m going to talk through is basically we need to create a couple of data stores. So you can name them what you want, mine are console user groups, and the other one is for a work front profile. The second part will be the actual creation of a Fusion scenario. This is the front part of that Fusion scenario. This basically will go through and look for our form and that we’ve submitted that form, and from there it will do a few different things, which I’ll talk through, to help us create our user in admin console. From there, it will break into basically an upper path from the create user in admin console. We’ll have an upper path for a requester, and we’ll have a lower path that will be for a marketing team member, someone that has basically a standard license. So in general, four parts. Let’s keep going.

So building the data stores, these are pretty much straightforward.

The information that we talked about just a little bit ago for user groups, those IDs that we got from the URL, this is how we create those. You basically will go into data stores, click create a data store. From there, you give it a name that’s appropriate. Here, I use console user groups, and then it will ask for a data structure. So you’ll click on add, and you basically give it names of fields that you need to create. We want a group ID, we want a group name, and we want group type. So those are the three items that you can see on the screen. You’ll click save, you’ll click save a second time. Also pay attention to your data storage in megabytes. That’s typically defaulting to 10. Go ahead and change that to one. This won’t take up a lot of room, and we don’t want the data store to be big in size when it doesn’t need to be. On the right-hand side, or my right-hand side, we will then create a work front user profile. In this case, we only have one key request profile which is for a requester, or those folks that come in and put in the marketing items. We have another way to get folks that are on the marketing team, and I’ll show that to you in one of the other slides. But this is just to create the information that we want all of our requesters to have. So for us, it’s things like the company ID. We have a specific layout template for requesters. We have a specific home group, a team ID, a role ID, and a few other fields that are required for our requesters, but they’re all the same. So this will always be created the same, which makes it a lot easier for us and saves us time.

All right, let’s get into the B option, which is basically building our trigger and setting up our user management module. So for B, we have a couple of key pieces. The first one is listening for our work front form. That’s our first module. Once we submit, it will listen, see that we submitted a form, and it will read the data. The part that’s on the top is if we chose to mirror one of our marketing members, the top part will go through and read the field that has our mirrored users, and it will get that user’s ID. It will then bounce to the bottom track. And for us specifically, we have a very unique scenario for JP Morgan, unique, but we are a large company. We’ve done a lot of purchases, so over time, we have a lot of different email domains. So I have a switch statement here where we use JP Morgan, JP Morgan Chase, Chase.com, a lot of different variations that we need to basically have an output of something like JP Morgan.com to be able to use for our domain for our create user and admin console. So I just wanted to show you guys what that looks like. For many companies, they only have one domain like etsy.com, and you don’t have to worry about anything else. But for us, we have multiples, and so we do have to identify where the user is coming from in terms of their domain. The second part is actually looking at the create user and admin console. Basically, all that information that we gathered at the front part, things like our email address, the domain that I just talked about, for us, we have a unique user ID that was on our form. That’s what we use for our SSO. Most SSOs either have a unique ID or they’re using email address. So our login type is domain-based. The other option underneath login type is email. And so for a lot of folks, email will be the choice, and you won’t have as many fields to fill out. But for us, it’s domain-based, and so we need a domain. We need our unique standard ID, and then we need items like the first name, the last name, the items that we basically pulled from our form. And that’s basically it. We will also set up our connection. So the admin console connection that you see up at the top right, you’ll click add, and when you do so, it will ask for three pieces, your client ID, your client secret, and your organization ID. Once you load those in, you’ll click save. It will validate, and your connection should be set and ready to go. So let’s look at our step C.

Step C is our flow for our requesters or what we call contributors.

For this, we’re basically going and pulling our user group ID for a requester. So that’s our first item that you see there. We’re reaching into the data store, and we’re getting that ID. Next, we have basically our Adobe user management, and so we need to add the user group to that user. So you can see here that’s exactly what we do. It’s a few fields. It basically wants to know who the user is. There’s the domain field again that we had from the first part, and then the third field is just the group ID that we grabbed from the user store. We then put our job to sleep for 20 seconds. Part of testing that we did, there is a little bit of a sync delay at least in our environment between something created in admin console, and then it’s showing up in Workfront. So we give it a little bit of a delay, and then from there, we look for our new user. We find the new user that was just created, and from there, we call the data store to go get that user profile with all the information like team, group, schedules, all of that stuff. We can now apply that with the update requestor record, and then from there, the one thing that we noticed in all of our jobs is because we use an automated service account, it adds the home group of that automated service account, which for us was our Workfront admin group. We don’t want users to have that, so the last two pieces basically remove the admin group that we have. So we’re basically going through and doing an aggregate of JSON, we’re basically going through and looking at the home user group, and then we’re making, it’s not really a remove, but we’re making a call where it says remove Workfront admin, that’s an actual custom API call, it’s just doing an update, and in the body, we’re basically giving it user groups in that JSON string, and it will remove that group for us. So let’s move on to our final module, the one down below for the marketing user. Again, very similar. We are calling our user group number to find out what our user group is for our regular standard user. So we call that first. Same thing again for the Adobe user management.

It’s the exact same thing. We’re calling the user, we’re getting that domain output, and then we’re attaching the group. We put the job again to sleep for 20 seconds, and then this time, we noted a user that we mirrored on the Workfront form, so we are getting the information of that mirrored user now, and we’re going to use their home team, their manager, their groups, all their information since they’re in the same team to populate our brand new user that we have.

So the next is we search for our new user. We search for the mirrored user, and we do updates.

At the same time, at the very end of this flow, like the other one, we also need to remove basically that Workfront admin group. We don’t want folks from our marketing team in the admin group because we do do other things with that admin group. So this time, we do a little bit of an iteration because users, standard users, may have a lot of work groups, so we’ll iterate through the work groups. We set a filter, basically looking for our very specific number, our Workfront admin group number, and then we do the same thing. We do the aggregate JSON, update, and remove it. So key takeaways for all of this is you guys can do this. It’s really saved us a lot of time. It looks complicated, but for the most part, it’s not too difficult. You guys can follow the steps that we have. The key items, make sure you have a Workfront form. Make it simple, that users can fill out, the information that you need for the scenario job. Make sure that you create your user management project in your developer console. That’s basically your gateway to be able to make your Fusion scenario run. So make sure that you get access to that. And then keep your scenario simple. I showed you two pieces, basically a requester and then a marketer. You could do more, but for us, the requester is probably make up 80 percent of what we do. And so that was probably the one that we needed the most. But we did go ahead and figure out a way to get our marketers also support in terms of using that mere access on our form. But for the most part, these are the key takeaways. And now I’m excited to turn it over for Q&A and see what kind of questions you guys have. Pert! Okay, before we get to questions, I don’t want to lose something that you said at the beginning of your presentation. And I think we could absolutely start there.

This Fusion scenario, which by the way, amazing, also super step by step, please give praise in the chat because we love that.

You change, like you lowered the time from 22 minutes to like under 60 seconds. Like this is the dream that we all want. How did your stakeholders respond to that? Like tell us all about it. Well, it was both I’ll say stakeholders, but also for us as admins. Like a lot of us admins, I mean, we’re kind of all told to do what we need to do, right? So creating something like this sometimes looks scary. For us, we have a lot of different systems, like probably a lot of companies. We have a system for someone putting in a request, then it comes to us as a line of business to kind of get it fulfilled. And in the old way, we had to do a lot of this stuff manually through the custom form, right? So you have to populate the data from one side to a custom form, put that in, go over to admin console, add that stuff into admin console, come back over to Workfront, open up the user. And we had some additional fields, kind of like what Monique said, we have some user custom forms that we fill out as well. Then you have to add all of that data as well. When that was all said and done, it was taking us close to 22 minutes. We actually stopwatched it going across systems. So now, with the process, it’s a simple form. We put in some information for the most part on our users, and then we kind of let the systems through Fusion kind of do what they need to do. It goes to admin console, not me anymore. It does the sync between admin console and Workfront, not me anymore. It fills in all the data that we need for a user, not me anymore. And so, yeah, that’s how we got it down basically to roughly a minute now for the automation side. I mean, amazing. And I love, like, just as a tip, like he didn’t say this was a tip, y’all, but like they timed how long things took. So just when you’re having those conversations, I think that’s a great tip also. Okay, let’s get to the questions. So the first question up that came in is, how many admins do you have to manage those 9,000 users? So if you guys didn’t know, JP Morgan is a huge company. It’s about 350,000 people.

We have 12 instances of Workfront in the company, one being the payments that I have. So 9,000 plus users are not necessarily all on my instance. We have closer to 3,000 users for our instance. So to answer the question across those instances, we have about 17 to 18 admins across those 12 instances. Now for my area specifically in payments, there’s myself and another teammate. Wow. And how did you learn Workfront Fusion? Are you self-taught? Did you take formal training? What’d you do? Yeah, so like a lot of folks out there, I am not a programmer. I don’t write React or Node or anything else like that. I essentially was just kind of a tech person for most of my life, but I was volunteered or volunteered into Workfront, became an admin, saw a lot of things like what we’re talking about now in terms of, hey, this is kind of manual for me or manual for my users. What can I do to try to make it better? We had Fusion and I basically started dabbling there, didn’t really understand it right away. I did take formal training through learning at adobe.com. I did take the Fusion class. I would highly recommend it. That got me kind of over the hump in terms of, I’ll say more understanding the modules, more about the API Explorer and kind of learning a little bit more about the API. Plus the benefit was in the three-day class, you have a lot of exercises that they hand walk you through, kind of like what I did on the slideshow. I want you guys to be able to take that and be able to walk through each of those pages and say, hey, I was able to create that. That’s exactly what we did in training. For me, that was the best opportunity to learn. So I would highly recommend that. From there, there’s also stuff in Experience Leak. There are files that you can download. There’s tutorials that you can kind of go through. I will say just in general, because I do use a lot of this stuff out on Experience Leak, Fusion is a big concept. So the written material is sometimes difficult to understand, much easier if you come to a session like this where someone hands-on kind of walks you through maybe how to do something, kind of like Monique and the sessions that they had, reporting and all that stuff. It’s much easier when someone’s kind of showing you. So I would recommend formal training for the most part, just to kind of help get you started. Tell the boss, I will make all kinds of cool, great automations, time savings, dollar savings, if you just pay for me to go to this class.

And use this scenario to make that case.

So let’s talk about, I mean, this is definitely related to your scenario, this is something that as all system admins as we’re bringing in new users is questioned. Let’s talk about your decision-making process, like the license level and the access level. When you’re bringing people in, how are you making those decisions? Everybody is different. So just what are your thoughts on that? Yeah, everybody’s different. And similar to the previous guest, Monique, try to keep things simple. So the biggest part of requests that we get are requesters. So we do have folks inside the business, outside of our marketing area that sales, product, teams like that, that need to make requests of the marketing team. So those are a lot of the users that we add. So in general, we do have a standardized setup for those folks. We have a single user group that we have set up in the admin console. That user form that I’m talking about in terms of the information, we have a certain set of information that we gather or that we have for a requester type user, outside of name, email address, things of that nature. Most of that is standardized. And so that’s a huge benefit because that’s a majority of what we get. People just kind of coming in and they need a quick request. They can now fill out that form and they’ll basically have their account created. The harder part was the marketing. And so if you guys go back, look at the video, one of the ways that we got around that is we ask for a colleague. So in the form, when people are filling out the form, we say, hey, do you have a colleague that you work with? And someone might put in, yeah, Cynthia Boone, I work for, I’m on the same team as her, put her name in there. The job will go through and we grab all of the information from say Cynthia on the work front side and we populate that new user with all that stuff. It saves us a lot of time. So it gives them the same roles and schedules and teams and groups and all that stuff. So we didn’t have to go in and do that manually like we used to. So again, kudos back to Monique on her session, keeping your users and everything kind of tight and managing all of that stuff. If you’re doing that on a regular basis, a job like this will be much, much easier because as you go through and you ask for a colleague, it will have all the data already mapped. The job will do it for you. It’s just, that’s brilliant. I love that, like mirror this person because we did get some questions.

And I think that it’s sort of buttons up against this is like, okay, now that they’re in, how are they requesting changes to that access? Are you using Fusion? Are you using a request queue? Like I’m getting this basic access, now I want extra.

Yeah, so probably like a lot of you guys as Workfront admins, we do have a queue. So if folks do need something unique, maybe they’re covering a project for a different team, a new team, we do have them kind of go through and input a request so that we can kind of make changes. Somebody may need a new job role. They may be on a team for just 30 days, maybe for a special project. And so obviously at the start, when we created their account, it could have been a month ago, it could have been a year ago. We may not have all of that stuff, but yes, going forward, a lot of that stuff, like Monique said in the previous talk, a lot of that stuff you could do very quickly manually. I mean, could you automate that? You probably could. We could probably expand our form for the most part. My team member actually took a lot of the stuff that we created for the users and reverse engineered it and basically set up kind of a job where we’re deactivating users in a similar fashion. So again, a lot of people will run reports. That was another way for us to kind of use the automation where it’s like, hey, why don’t we just have the fusion job do it? So if somebody hasn’t logged in for a certain period of time we’ll send a notification. If they don’t respond to that notification, we’ll turn them off after seven days as an example. So we can kind of go through and reverse engineer it that way. You know, I love that, right? You just put like, again, you just put the hammer down too. I love that.

So, okay, really like, I think this is one that like, it feels like the developer console is like this mystical, you know, ambiguous place. Like a lot of people are like, okay, I’m not really sure. So tell me about more about the developer console and then what is needed to, you know, create that project, like your process through that. Okay, yeah, so it was new for me too. So this is the first time that I’ve actually done something I’ll say, connecting up to the developer console. So I learned as well. So you do need to be in admin console for any of the stuff that you saw today. You do need to be a part of admin console. So it is assuming that you guys have migrated as an organization into the admin console and you’re basically having all your users created there in the admin console.

There is a special type of user. So the admin of your admin console, it could be you or it could be someone else in your organization like IT. You do need to be added to a developer role. There is a specific role in the admin console that allows you basically access to be able to kind of see what I showed in the video in terms of getting to the developer console, actually having access to the APIs and being able to set some of that stuff up. So that’s where you would go is essentially your admin console and your system admin, or if you’re one of those folks, set yourself up basically as a developer user. It’s one of the choices that you have underneath users, developers. So let’s talk about, and it’s related, but it’s a question I know you get asked all the time and a lot of people like, let’s talk about how we decide what’s the right number of system admin or group admins for instances. I know you have several instances and I know you have opinions. So what are your thoughts on that one? Yeah, so I mean, for our instance, we have two work front admins and I think everybody’s different.

Some people gravitate to the org or their group admin role and others do not. We have not had a lot of strong success in terms of developing group admins. So you have to have people that want to be in work front that really want to learn it at a deeper level. So I would say that’s who you would wanna focus on. If there are folks that continue to ask you questions and like, hey, how did you do that? Is there a way that I can help automate or do something for my team or my group? Those are the people that you want to kind of activate on in terms of saying, hey, maybe this person could be a group admin for their particular area and we can give them a little bit of training and knowledge. So I don’t know that there’s, I wouldn’t say that there’s a specific number. I mean, it really depends on whether you have people that you can groom or not for the most part for the role. So we do have two group admins right now that are in kind of infancy that we’re working with and they’ve been really, really good in terms of they want to do more for their teams and we’re giving them more to do for their teams. So it’s fledgling, but it’s getting started. So I don’t have an exact number, but key on the folks that really keep coming to you and wanting to know how things are done. Those will be your best group admins.

Totally agree with that.

That’s 1000%.

The last sort of big question is it’s a compromise time. So the question is like, is this significantly different from copying a user and like what would be the argument of not just copying users versus like building this scenario? I know you have thoughts. And so, I mean, for me, it’s time savings. I mean, some people, I have seen people that can data entry into Excel sheets or forms like nobody’s business, but for us, it’s kind of a set it and forget it. We now have folks that can kind of come in, input their information into the form and we know that it’s getting created exactly in the standard that we want. So even as an admin myself, I’ve been in Workfront for almost seven years. I have mis-keyed stuff when I was doing it manually. I have mis-copied stuff where I’ve missed stuff and it impacts basically the user’s either access or maybe they didn’t have something access wise to a report because I forgot a slash that was at the end of maybe one of these fields, I’ve done it. So it’s a way for me to basically say, I know it’s getting created the same way all of the time and I don’t have to worry about it. So for me, it’s more of an OCD thing and I’m like, okay, I know it’s getting done right every single time. I’m letting the bots do it. I love it and I agree. And it’s also like you start with that and then Fusion becomes so many different things. Okay, last thoughts for today. I know you did your takeaways on the slide but people are gonna leave here today. What are you thinking? What do you want them to do? Yeah, so yeah, my takeaways would be experiment. I mean, try, if you guys have not dived into Fusion and looking at automation, do so. It will definitely help your users. So experiment, jump into it and give it a shot. You won’t be disappointed, so jump into it. Kurt, you truly keep raising the bar for all of us. I’m so glad that you are willing to share your successes all the time. Thank you.