Expand my Community achievements bar.

Do you have questions about the migration to Adobe Business Platform? Come join our upcoming coffee break and ask away!
SOLVED

Single Sign On - Auto Provisioning Pros and Cons

Avatar

Community Advisor

I'm wondering if anyone out there using Single Sign On for Workfront has gone down the path of Auto Provisioning licensing/user accounts and if you could share any pros and cons to the scenario.

 

Background: For our instance we already have SSO enabled for account access but we still have to create the accounts in Workfront to connect with our SSO provider. Group Admins are wanting to have auto provisioning enabled so that they no longer have to go through the action of manually creating a Workfront User account and it can be birthright access upon hiring (similar to other company wide SSO platforms)

 

@CynthiaBoon - I believe you have spoken about SSO in your previous roles. Not sure if you have any take aways from those scenarios. 




1 Accepted Solution

Avatar

Correct answer by
Level 8

Our Workfront instance is used almost entirely in just our Marketing department, which is a fraction of our company. Requests, however, come from across the company. As long as the queue is set to be accessible by anyone, the system will let anyone in SSO in. This generates the super basic autoprivisioned Requestor access. We could (and have historically) stop there, but, like @Madalyn_Destafney mentioned, I prefer giving all users Reviewer access. At minimum, I would recommend moving users from the default Group to one that better fits their company alignment. We keep our Group structure as flat as possible unless that group has users that need more than Reviewer access OR if we need deeper reporting insights.

View solution in original post

13 Replies

Avatar

Level 10

I used to do auto-provisioning until I discovered it was a LOT easier to duplicate an account and change the name and email than to set it up from an auto-provisioned account. Now We just find an existing user that's similar to the new user and duplicate the account so the exsisting setting match fairly closely. Saves a lot of time and mistakes.

 

TIP: if this solved your problem, I invite you to consider marking it as a Correct Answer to help others who might also find it of use.

Avatar

Community Advisor

Thanks Randy. I agree that creating users isn't hard but unfortunately others find it time consuming. 




Avatar

Community Advisor

I definitely recommend autoprovisioning if you have any request queues that are open to anyone in your company and if someone submits a request that hasn’t before, they are automatically created as a requester license. It saves a ton of time. I’m not a fan of requester licenses so each month I had a WF report I had on auto send to myself if anyone in last month created from this and I’d bulk edit their license to be reviewer.

 

If we had a new hire in the org/department I managed, I created them myself with other settings. The provisioning was great for ppl not in my org but needed to submit a request and become users from that point on.

If this helped you, please mark correct to help others : )

Avatar

Level 8

I echo @Madalyn_Destafney's point about request queues and upgraded requestors regularly.

When someone needs to join Workfront, I guide them to the site so the system enacts the autoprovision (it's a 60-second activity for the new user), then I promote them accordingly. This approach ensures I capture the right email address (because case matters), which reduces instances of account duplication.

As a result, the only time I need to manually create an account is for external users like contractors or freelancers.

Avatar

Community Advisor

@Lyndsy-Denk and @Madalyn_Destafney  - do you use your system enterprise wide? Curious how the requests queues are working to create the accounts for the enterprise and how that worked with whatever system you used for Single Sign On.

 

 

 

 




Avatar

Correct answer by
Level 8

Our Workfront instance is used almost entirely in just our Marketing department, which is a fraction of our company. Requests, however, come from across the company. As long as the queue is set to be accessible by anyone, the system will let anyone in SSO in. This generates the super basic autoprivisioned Requestor access. We could (and have historically) stop there, but, like @Madalyn_Destafney mentioned, I prefer giving all users Reviewer access. At minimum, I would recommend moving users from the default Group to one that better fits their company alignment. We keep our Group structure as flat as possible unless that group has users that need more than Reviewer access OR if we need deeper reporting insights.

Avatar

Community Advisor

Yup same situation as @Lyndsy-Denk - a queue was open to anyone in the company in order to submit requests to the marketing department and if they hadn't submitted a request before/wasn't already a user, they're automatically created as requestor, which I changed monthly in bulk to reviewer.

If this helped you, please mark correct to help others : )

Avatar

Community Advisor

That was one of the first things I tackled when I took over our instance. I'm the only admin and sorely needed that off my plate. It wasn't too hard to work with our SSO team to figure out the necessary mappings for a request license. It was such a huge relief, no more checking in while I was out of the office. Now, anyone from our company can at least log in and make a request. I still get reports to alert me when someone only has a request license, so I get a chance to see the new users. I'll switch them to a more user friendly layout template and change them to a reviewer, but having their basic user set-up has been so helpful. I can still manually create users, but our federation IDs don't follow a standard format, so I have to have access to other systems to look that up - it's much easier if they just log in, then I can fix their user ID later. The one con for me is when a current user has a name change. They'll get a new auto-provisioned account and wonder where their stuff went. That causes a bit of work to deactivate their new user ID and edit their existing one, but that doesn't happen very often for us. All in all, it was well worth it for us.

Avatar

Community Advisor

Thanks Sheri for the insight. The hope is that it will help alleviate some of the user management for our teams. And since we use Workfront enterprise wide, we can be adding 2-3 new users a day. 

 

I've taken note of the "con" cause I've recently had issues with single sign on with that same scenario without auto provisioning. 




Avatar

Level 5

Auto-provisioning by itself is a little bit crude. As mentioned, in many ways, it's easier to clone existing users instead of having to manually alter newly created users.

 

That said, if you're using Fusion, auto-provisioning can help a LOT. We have Fusion apply a basic user's necessary license/group/company/custom form/etc. upon autoprovisioning. That way, the beginning of the work has been completed.

 

You can also create a "clone request" for new users, where you can take a newly autoprovisioned user and have another user's attributes applied to the new user. 

 

Plus, if you want to do a bulk import of new users, you can take Workfront's basic user import form and make it actually more fully functional. Again, that tool is rather blunt without Fusion assistance. 


Having had to create users "by hand" in my last position, auto-provisioning (with Fusion) has saved my sanity. 

Avatar

Level 4

I wanted to add one point to the discussion about SSO, from what I've experienced it seems like accounts created via SSO are automatically added to whatever group is alphabetically first in your groups list. It's a little crazy that you don't see to be able to specify this in the SSO setup (if I missed this, please let me know!). It sounds like most people make a group that will always appear first, like '! All requestors' or something like that. We didn't realize this until it was too late and had hundreds of users automatically added to the wrong group.

Avatar

Community Advisor

You're right, I totally forgot about that! I believe we just stumbled on to that with our implementation specialist, and we ended up putting an asterisk before the general group where we wanted users to added by default. I'm not sure it is documented anywhere 

Avatar

Level 10

I had a group called AAA_New Users and a "AAA_New Users" report emailed to me everyday with the contents of that group. I could then place them in the right group manually, and I'm reminded to do it by the email.

That is… before I decided it was a LOT easier just to copy an existing user to create new accounts.