Description: An organization with a single domain should be enabled to separate their products across multiple Administrator Consoles.
(Of lower priority, a separate idea is that - once an organization is forced to share products on a single console - there should be a single point of contact at Adobe to help manage shared issues caused by console sharing.)
Why is this feature important to you: We are a multinational company with a very distributed organizational structure. The R&D department has little business reason to interact with our Marketing department, for example.
The introduction of the console has created a lot of work, the unnecessary need for added coordination, and layers of authorization/access because of the current Console constraint that a domain can only be controlled by one set of primary owners - and those owners are arbitrarily the first group of administrators to have migrated over to the console.
Until the admin console, it was very possible for separate business units to set up SSO for their own products and manage their Adobe products without the need to coordinate. This efficiency goes away once all units migrate to the console. If one group migrates to the console first, they essentially own the admin console. They gain decision-making authority for who can use the company's "claimed" domain. These admins are understandably reluctant to share their highest privilege in the console if it means granting access to sensitive or confidential information in their own applications. Furthermore, at least make all decisions at the highest level going forward as to who else can be added to the console at the highest-provisioned level.
- Applications owners whose users later migrate to the console are now required to get authorization from primary owners to either share ownership (e.g. Application A's primary admins must decide whether or not to let Application B admins become global admins within the console) at this primary level, or grant permission for the new application to use the claimed domain to set up SSO for the Adobe product being migrated.
- In addition to the efficiency loss, Admins of one product lose the ability to completely secure their sensitive information from the admins of other products if those Admins "own" the primary console. Using the same example above, R&D information can be highly secretive. Another group should not have the ability to give themselves access to your R&D information simply because of the current architecture of the Admin Console.
- Furthermore, to set up or migrate accounts for users, the owners of the Primary console must have the SSO-enabled users first created on the primary console in order for the users to be set up on the secondary console. This creates a lot of work for the primary console owners, as well as duplicative work for the downstream application that wants to set up users with SSO.
- Because 2 or more business units in a company have different products, the units deal with different Adobe representatives who do not connect nor mutually solve a company's overall issues with the console migration. This causes delays, ambiguity as to the root cause of a problem, misinformation, ambiguity with whose responsibility it is to solve the issue, and the need to communicate repetitively.
How would you like the feature to work: Let each business unit have a separate console regardless of whether or not they need to set up SSO for the same domain. Do not force groups with separate contractual relationships with Adobe to have to coordinate and set up a governance model simply because of this technical limitation that dictates 1 Domain/1 Console.
Current Behaviour: The admins of the first application to migrate over effectively (and arbitrarily) gain global management rights to all applications later on-boarded onto the Admin Console.
Later application owners to on-board must request permission to either become global admins themselves or to use the already-claimed domain for their own SSO implementations.
Any user who is to be set up with SSO in that domain must first be set up at the global level (by the Adobe "global admins") at the company before being added as users to any application where SSO is enabled and this increases the administrative and coordinative burden.
