Navigating Workfront Admin Console migration in a large enterprise
If you are in a large company where different departments separately purchased products that each group manages separately, and you all enable SSO for your products, how has your Workfront migration gone or how is it going? Our migration to SSO has been fraught - to put it mildly - as the architecture of the Admin console places some serious limitations on our ability to manage our sensitive Workfront information independently --- far from the prying eyes of unrelated departments with whom we're suddenly forced to share the console.
I've already created a related submission under the Ideas forum, so I won't re-hash everything, but if you are experiencing similar pains at your company, I ask that you cast a "Like" for my idea in order for it to gain traction and help others who still have to complete their migration. And to summarize, here are our pain points with the ongoing Adobe Admin Console migration:
We've learned the following from the Adobe reps who have been working with us on the migration:
- all products that require SSO must share a console if they are on the same domain
- the first product team members that migrate their product over to the console arbitrarily become global admins of the console and the de-facto owners of the domain (!!)
- they must then give approval via the console for any additional products added to the console to use the domain for SSO or any additional
- if Workfront gets added to the console after another product, the global admins get to decide if a Workfront admin gets to become a global admin of the domain. The Workfront team in this scenario has no say in whether the global admins can create accounts for themselves to access the sensitive data inside of Workfront.
- any Workfront user who will log into the console via SSO must first be created at the root or "global" level of this console before they can be added to Workfront. If Workfront admins are not granted roles as global admins (because again, this is at the discretion of the first product team who completed their migration) then the Workfront team has to request that the global admins add the new users first in their area of the console.d\
In our case, the first product owners had a really rough time with migrating to the admin console because their SSO implementation caused an outage and disruption, so they're understandably reluctant to grant the approval for Workfront to use the domain for SSO implementation. (Now that they have SSO working for them, they don't want to do anything that would destabilize their implementation. Furthermore, they don't want to proceed until my team lays out documentation of our administrative processes to essentially prove to them it's safe to share a console with us. And finally, neither of our teams really want to proceed with sharing a console until we mutually hammer out a governance plan for sharing one that includes roles, responsibilities, escalation paths and what happens when new groups on-board the console with new products or product instances.
So with all this, my Workfront team has lost agency to move forward with our own migration. We're beholden to another department that we've never had a valid business reason to collaborate with. The migration has created a great deal of work for us with no tangible benefit to our operations. Our data will soon become far less secure. The autoprovisioning user experience is going to worsen. And with the added overhead of having to coordinate with this other busy team, we do not feel we are at all close to the end of a successful console migration.
Has your company had any similar experiences? We couldn't possibly be the only company with separate groups managing their own Adobe products who suddenly got thrown into the same console. I do wonder if this scenario was at all considered when the console was designed and if somebody at Adobe decided that this likelihood would be a trivial matter for their customers to resolve. It is definitely not a trivial matter on our end.