Hi Kelly,
I would like to echo Pat's comments. In particular, the lack of support for automatically assigning a default set of entitlements to a new enterprise login. In other words, the first time an enterprise user logs into a component of the ArcGIS platform, they would get immediate access to a predefined combination of ArcGIS Online, ArcGIS Pro, GeoPlanner, Business Analyst, Insights, etc. They would get the access when they need it, rather than placing a barrier in their way, and generating an extra, per-user administrative burden on the institution. (This is for enterprise logins, not arcgis logins.)
Addressing that need (as it sounds like you might in the next release?) will also eliminate a number of related issues; issues which typically only occur as a result of people struggling to deal with that simple piece of missing functionality.
Whether an institution implements scripting or manual workarounds for that missing piece, it generates a number of additional failure points and/or extra work. Not what one expects from software sold as an enterprise-class, scalable, Software as a Service (SaaS) system.
The introduction of User Types perhaps is a step toward solving the problem, but it doesn't at the moment. I suspect the introduction of user types is setting up some longer-term changes? Otherwise, like Pat, I find it to be confusing, and I am failing to the see the benefit at the moment...
If you do not plan to implement a way to specify a default set of entitlements for enterprise logins in the next release, then perhaps the user type capability can be leveraged instead? Since you can specify a default user type for a new enterprise login, will you be adding the ability for administrators to define a custom user typer?
That would lead to a relatively simple, yet powerful, workflow for Administrators: they would create a custom user type, set the desired combination of entitlements for that user type (from all available in the instance, not just Pro), and then set that user type as the default for new enterprise logins. Then, when a new enterprise login hits the system the first time -- and automated join is configured -- they can start working right away, without being stuck waiting on an automated script or manual intervention by an admin.
On the enterprise login configuration page you can specify that a new user can join automatically, and default values for Role, Group(s), credit quota, Esri Access, etc., but not a default set of entitlements. To get around this oversight, some institutions, including mine, periodically run an automated Python script to provide the missing license auto-provisioning capability.
Requiring an institution to have to perform this task using a script is, I believe, the largest, single barrier to broader adoption of the ArcGIS platform in the educational realm. (I suspect it is, or will be soon, a barrier for any large customer, education sector or otherwise, that needs to automate things, after they enable enterprise logins.
Having to know scripting to have a scalable system, that provides a basic level of functionality, is not a typical expectation for SaaS. Furthermore, many people tasked with ArcGIS Online Administration, in education or otherwise, are not possessed of the level of scripting expertise required. You cannot have thousands of users dependent on a script hacked together from examples in the ArcGIS API for Python. Such a script needs to be to robust, secure, scalable, provide logging, handle exceptions, etc., if it is to be successful and reliable in an enterprise environment.
Additionally, if scripting isn't an option for an institution, then the manual management requirements scale linearly with the number of users. The more users, the more administrative workload; again, not a typical expectation for a SaaS system.
If the issue with automated licensing/entitlements were addressed, then the requirement for scripting expertise and/or cumbersome, manual management would be eliminated, or significantly reduced. This change would enable the many institutions with ArcGIS administrators, who don't have the time for manual tasks, nor the scripting expertise, to empower all their members with access to ArcGIS.
There will always be the occasional exception of course. This functionality, however, is about setting the majority of the institutions implementing ArcGIS up for success, rather than failure, as they scale-up access across their organizations.
Enabling enterprise logins, or Single-Sign-On, is also a barrier for some institutions, however, it is one with a clear solution, once the right people at an institution are involved in the conversation. Simply enabling enterprise logins, however, without also being able to auto-provision entitlements, still leaves one with the significant barrier of manual effort or scripting to support broad adoption.
Currently many institutions are trapped by the "more users, more time commitment" issue. That approach does not scale. Rather, it sets up an institution for failure; or, just as bad, forces them to implement a digital divide; creating an environment of haves and have-nots, where, even though they have an institution-wide license, some users get access while others are denied.
Thanks for reaching out here for input on this topic. Hope you find the above helpful as you plan the next release!
Cheers,
-peter
