51黑料不打烊

Transcript

Welcome everyone to my presentation. I鈥檒l be talking today about Automate Orkfront User Account Creation with Fusion.

Our agenda today, I鈥檒l give you a little bit about me, some of the tools that you鈥檒l need to actually make this Fusion scenario work for you. I鈥檒l give you a little background on the use case that we have for JP Morgan, and how we came to develop this solution. We鈥檒l talk about work front form that we鈥檒l need as the starting point for our overall automation. We鈥檒l talk about the user management API and how to set that up so that you can connect to your admin console. We鈥檒l talk a little bit about the admin console and the groups that you鈥檒l likely have or that you use today for your users. Then we鈥檒l get into the me, which is the Fusion scenarios. I鈥檝e broken that down into a few different pieces, so they鈥檙e a little easy to digest. Then finally, we鈥檒l do key takeaways. A little bit about me. I鈥檝e 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鈥檓 an identical twin. If you can鈥檛 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鈥檒l need. You鈥檒l 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鈥檒l 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鈥檙e 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鈥檚 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鈥檙e 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鈥檛 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鈥檙e 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鈥檓 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鈥檚 take a look at what we鈥檝e got.

Let鈥檚 jump in and let鈥檚 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鈥檒l 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鈥檒l 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鈥檒l click on that. You鈥檒l see another little icon on the next page that says add an API, add a plugin. You鈥檒l click on add API. From there, you鈥檒l 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鈥檒l 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鈥檒l then be asked to name your credential. Give it a name that鈥檚 appropriate, that makes sense to you.

You鈥檒l 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鈥檒l see on the screen, and you can see what those pieces are on the right, the items that you鈥檒l 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鈥檚 it. You鈥檝e now created basically a connection for your environment to use the user management API.

So let鈥檚 move on to step three. This part should be pretty straightforward if you鈥檙e 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鈥檒l go to adminconsole.adobe.com, click users up at the top, and you鈥檒l 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鈥檚 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鈥檓 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鈥檝e submitted that form, and from there it will do a few different things, which I鈥檒l 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鈥檒l have an upper path for a requester, and we鈥檒l 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鈥檚 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鈥檚 appropriate. Here, I use console user groups, and then it will ask for a data structure. So you鈥檒l 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鈥檒l click save, you鈥檒l click save a second time. Also pay attention to your data storage in megabytes. That鈥檚 typically defaulting to 10. Go ahead and change that to one. This won鈥檛 take up a lot of room, and we don鈥檛 want the data store to be big in size when it doesn鈥檛 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鈥檒l 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鈥檚 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鈥檙e 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鈥檚 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鈥檚 our first module. Once we submit, it will listen, see that we submitted a form, and it will read the data. The part that鈥檚 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鈥檚 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鈥檝e 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鈥檛 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鈥檚 what we use for our SSO. Most SSOs either have a unique ID or they鈥檙e 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鈥檛 have as many fields to fill out. But for us, it鈥檚 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鈥檚 basically it. We will also set up our connection. So the admin console connection that you see up at the top right, you鈥檒l 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鈥檒l click save. It will validate, and your connection should be set and ready to go. So let鈥檚 look at our step C.

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

For this, we鈥檙e basically going and pulling our user group ID for a requester. So that鈥檚 our first item that you see there. We鈥檙e reaching into the data store, and we鈥檙e getting that ID. Next, we have basically our 51黑料不打烊 user management, and so we need to add the user group to that user. So you can see here that鈥檚 exactly what we do. It鈥檚 a few fields. It basically wants to know who the user is. There鈥檚 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鈥檚 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鈥檛 want users to have that, so the last two pieces basically remove the admin group that we have. So we鈥檙e basically going through and doing an aggregate of JSON, we鈥檙e basically going through and looking at the home user group, and then we鈥檙e making, it鈥檚 not really a remove, but we鈥檙e making a call where it says remove Workfront admin, that鈥檚 an actual custom API call, it鈥檚 just doing an update, and in the body, we鈥檙e basically giving it user groups in that JSON string, and it will remove that group for us. So let鈥檚 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 51黑料不打烊 user management.

It鈥檚 the exact same thing. We鈥檙e calling the user, we鈥檙e getting that domain output, and then we鈥檙e 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鈥檙e going to use their home team, their manager, their groups, all their information since they鈥檙e 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鈥檛 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鈥檒l 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鈥檚 really saved us a lot of time. It looks complicated, but for the most part, it鈥檚 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鈥檚 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鈥檓 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鈥檛 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鈥檒l say stakeholders, but also for us as admins. Like a lot of us admins, I mean, we鈥檙e 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鈥檚 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鈥檚 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鈥檛 say this was a tip, y鈥檃ll, but like they timed how long things took. So just when you鈥檙e having those conversations, I think that鈥檚 a great tip also. Okay, let鈥檚 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鈥檛 know, JP Morgan is a huge company. It鈥檚 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鈥檚 myself and another teammate. Wow. And how did you learn Workfront Fusion? Are you self-taught? Did you take formal training? What鈥檇 you do? Yeah, so like a lot of folks out there, I am not a programmer. I don鈥檛 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鈥檙e 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鈥檛 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鈥檒l 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鈥檚 exactly what we did in training. For me, that was the best opportunity to learn. So I would highly recommend that. From there, there鈥檚 also stuff in Experience Leak. There are files that you can download. There鈥檚 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鈥檚 much easier when someone鈥檚 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鈥檚 talk about, I mean, this is definitely related to your scenario, this is something that as all system admins as we鈥檙e bringing in new users is questioned. Let鈥檚 talk about your decision-making process, like the license level and the access level. When you鈥檙e bringing people in, how are you making those decisions? Everybody is different. So just what are your thoughts on that? Yeah, everybody鈥檚 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鈥檓 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鈥檚 a huge benefit because that鈥檚 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鈥檒l 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鈥檓 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鈥檛 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鈥檙e 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鈥檚 just, that鈥檚 brilliant. I love that, like mirror this person because we did get some questions.

And I think that it鈥檚 sort of buttons up against this is like, okay, now that they鈥檙e in, how are they requesting changes to that access? Are you using Fusion? Are you using a request queue? Like I鈥檓 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鈥檙e 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鈥檙e 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鈥檚 like, hey, why don鈥檛 we just have the fusion job do it? So if somebody hasn鈥檛 logged in for a certain period of time we鈥檒l send a notification. If they don鈥檛 respond to that notification, we鈥檒l 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鈥檓 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鈥檝e actually done something I鈥檒l 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鈥檙e 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鈥檚 where you would go is essentially your admin console and your system admin, or if you鈥檙e one of those folks, set yourself up basically as a developer user. It鈥檚 one of the choices that you have underneath users, developers. So let鈥檚 talk about, and it鈥檚 related, but it鈥檚 a question I know you get asked all the time and a lot of people like, let鈥檚 talk about how we decide what鈥檚 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鈥檚 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鈥檚 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鈥檛 know that there鈥檚, I wouldn鈥檛 say that there鈥檚 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鈥檙e working with and they鈥檝e been really, really good in terms of they want to do more for their teams and we鈥檙e giving them more to do for their teams. So it鈥檚 fledgling, but it鈥檚 getting started. So I don鈥檛 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鈥檚 1000%.

The last sort of big question is it鈥檚 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鈥檚 time savings. I mean, some people, I have seen people that can data entry into Excel sheets or forms like nobody鈥檚 business, but for us, it鈥檚 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鈥檚 getting created exactly in the standard that we want. So even as an admin myself, I鈥檝e 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鈥檝e missed stuff and it impacts basically the user鈥檚 either access or maybe they didn鈥檛 have something access wise to a report because I forgot a slash that was at the end of maybe one of these fields, I鈥檝e done it. So it鈥檚 a way for me to basically say, I know it鈥檚 getting created the same way all of the time and I don鈥檛 have to worry about it. So for me, it鈥檚 more of an OCD thing and I鈥檓 like, okay, I know it鈥檚 getting done right every single time. I鈥檓 letting the bots do it. I love it and I agree. And it鈥檚 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鈥檛 be disappointed, so jump into it. Kurt, you truly keep raising the bar for all of us. I鈥檓 so glad that you are willing to share your successes all the time. Thank you.