Scheduled automation for everyday ArcGIS Pro users

[Bud]

I'm a GIS power-user (PL/SQL development, Python, attribute rules, data owner etc.). But I'm not in IT. 

I come from the IBM world, where regular users can create:
- Scheduled emailed reports (via the UI; no-code)
- Scheduled jobs to pre-compute fields and tables (via the UI; no-code or low-code)

That functionality is available OOTB to all applicable IBM Maximo users -- as part of every IBM Maximo implementation. That is a really big deal. IBM Maximo users are empowered to do their own automations...right through the frontend application.

It would be great if we could do that sort of thing in ArcGIS too --  create our own scheduled automations via Pro. (No, I don't want to set up scheduled geoprocessing tasks or scheduled Windows tasks on my own computer...which would only run when I'm logged in. That's too fragile and uncentralized…I'm not interested in that.)

I'm aware that Esri has ArcGIS Notebook server, which can be used for automation purposes. I've pitched ArcGIS Notebook Server to my organization, but their immediate response was: "It's an administrative tool meant for IT staff only, it would take political will to buy it, and implementation would take time that we don't have. So, no. We have no plans to implement ArcGIS Notebook Server, and even if we did, we'd only use it for IT administration."

I think there is a missed opportunity here, which is, empowering everyday users to automate their work...through OOTB tools in ArcGIS Pro. It could very well be that ArcGIS Notebooks can actually achieve the kinds of automation that I'm referring to (although scheduled/emailed reports probably aren't as easy as they ought to be -- and can't be done through the UI). But the point I'm trying to make is that IT departments don't see ArcGIS Notebook Server as a "tool for the people". They see it as an IT-admin tool.

The result is: power-users like me are stuck in the stone age...without automation tools. To me, scheduled GIS automation should be OOTB...built into ArcGIS Pro/server, and available to power-users as part of standard ArcGIS implementations. 

Is there anything Esri can do to make scheduled automation more easily available to everyday users?

[SarahHartholt]

What sort of automation are you looking to perform? I have a simple model that I created in ArcGIS Pro that automatically runs every day at 1pm. Schedule geoprocessing tools—ArcGIS Pro | Documentation 

[Bud]

Thanks Sarah. I think that functionality uses Windows Tasks Scheduler on your local computer and only runs if your computer is turned on and logged in. I’m looking for scheduled automations that are server-based, and can send emails, etc.
Similar to these examples:
- Scheduled emailed reports
- Scheduled jobs to pre-compute fields and tables

For example, if there are any construction projects in a FC where the status is FUTURE and the date is <= sysdate, then the GIS server should send me an email to tell me about it (aka a report).
Or, on a nightly schedule, re-populate a HAS_CURVES field in a polyline FC, since we can't get that information via Arcade attribute rules or SDE.ST_GEOMETRY.

I don’t really understand why there isn’t functionality like that…baked right into ArcGIS Pro/Server…that power-users could manage on their own. There is clearly an application server being used by Enterprise / ArcGIS server. It seems to me that power users should be able to to utilize that server to set up scheduled automations (without using windows scheduled tasks on our local computer, or dealing with IT by begging them to manually set up a scheduled task on a server somewhere).

As data owners, we can do all sorts of other things in Pro, like publish layers to AGOL/Portal, do lots of things in the enterprise database like create tables, views, triggers, sequences, etc. Why not give us scheduled automation functionality too? Right in the layer properties in Pro? (or something like that)

I’ve been told that most enterprise systems have functionality that lets users set up their own scheduled server-based automations. But when I tell people (who work in other enterprise industries) that ArcGIS doesn’t have automation functionality built in, they’re usually quite surprised. A direct quote from a lead IBM developer: "…that lack of automation in ArcGIS sounds painful. And it's a good reminder of some of the things IBM does well, that others don’t."

Automation is normally included as standard functionality in enterprise systems. But it seems like an afterthought in ArcGIS -- and isn't practical for non-IT users.

[JonEmch]

Bud,

Thank you for logging this idea. I understand that automation is important to our users, and we have taken steps and strides to implement automation into ArcGIS. As we've discussed on a separate thread, ArcGIS Notebook Server, as well as the notebook capability in ArcGIS Pro (which is completely native, by the way: notebooks in ArcGIS Pro do not need ArcGIS Notebook Server to run) have the capability to create tasks that can be run under a variety of conditions. 

I disagree with your IT dept's assessment of ArcGIS Notebook Server as strictly an IT administrative tool. I think that although it can administer certain parts of ArcGIS Enterprise, its exposure of the ArcGIS API presents a huge opportunity to power-users to create complex automations that can now be triggered with webhooks as well as being exposed as web tools. I believe that there is an education opportunity for your IT dep't using the resources we have produced on this topic (some of which is documented here: https://enterprise.arcgis.com/en/notebook/latest/administer/windows/automate-notebook-execution.htm).

Feel free to DM me if you would like to discuss this at more length.

[Bud]

@JonEmch Thanks for your comments. Fair points.

Maybe my organization should request a demo from Esri Canada about automation in ArcGIS. Will give it some thought. I know there are resources from Esri Inc on Notebook Server.  But a more general "Automation in ArcGIS" session might be more appropriate...rather than pitching a specific product.