Latest Contributions by PNWGuy

Hi @MichaelBroadbent. Here are some use cases.  Directly we would integrate with the following systems (and use cases) as of this time: Monday.com - We use Monday.com as a task and resource management system for my staff. Staff record all assigned tasks and note progress here. A large amount of the work we do is GIS, so having a link between the two systems makes it easier to automatically track GIS workload without manually entering it into Monday. Skyward.io - We use Skyward as our drone (fleet) and mission tracking platform. However, we use the GIS to record where clients want drone missions to occur. Linking these two systems together via web hooks allows a seamless continuity of data from mission request all the way to mission completion. Microsoft Power Automate - We are a Microsoft shop with innumerable workflows build on top of Microsoft products. Power Automate allows us to easily "stich" not only Microsoft products together but many other external systems right out of the box (Survey123 is supported out of the box). It also can send and receive webhooks making it extremely flexible. Our GIS system is part of many of these Microsoft "heavy" workflows, however we have to rely on manual\human intervention for to connect the GIS to the rest of the workflow. Hope this is helpful. ... View more

Hi @MichaelBroadbent, This is great news! And I do have some ideas! I also posted a hypothetical workflow on this idea: Allow AGO and Enterprise to be a Webhook Receiver. We integrate between may different systems including other SQL and Oracle databases and online work management tools such as MS Flow, Monday.com and Smartsheets.com. I know that Integromat and Zapier are really popular too, but I don't have direct experience with those. So three main ideas: It would be wonderful if the webhook payload contents could be somewhat defined by users (for webhooks going out of Workflow Manager), rather than just a one size fits all schema. Perhaps a standardized or "recommended" json object could first be presented, but allowing flexibility on what to include in the payload adds a ton of value. I have seen this done really well by GUI's that allow the user to pick (or omit) which fields or other data from the object  they want to include. The reason for this flexibility is really to streamline the parsing on the receiving side. Including only relevant data not only helps the json be more efficient, but can streamline and clarify communication between the people and teams representing the systems involved. The destination system might be handled by a completely different group of people that those managing Workflow Manger. The second idea is related to incoming webhooks to Workflow Manager. There should be a tool where you can paste a sample json object from the origin system which will auto-parse the object for the user and decipher fields of data within the object. (Microsoft Flow has this ability for example and makes it super simple to use the resulting data.) These data fields could then become available in Workflow Manager to perform other tasks\logic against. And the third idea is really to spoon feed security between systems. (This is more of my point of view, rather than a idea.) It should not require a IT Networking guru and a dictionary of Networking terms to get a webhook into Workflow Manager nor get a receiving system to recognize a webhook from Workflow Manager as legit. (It seems like tokens is usually the authentication measure used most often in these APIs, so it should overall be really easy to generate and manage tokens.) I have noticed that a what sets apart these kinds of integration systems from "lousy" to "great" are those that really take the complexity out of the json objects as well as spoon-feeds setting up the authentication between systems. In my opinion, if you alleviate the "pain" in these two areas, users will be able to spend more time on optimizing workflow problems rather than spending hours trying to get systems to "talk" or interpret json. Offloading the json parsing and authentication onto the user without any help (which I have definitely seen in other system "integration" products) comes off as lazy and diminishes why a org might invest in that solution in the first place. It has amazed me over the years how many software "solutions" have done nothing for me but add more complexity because the vendor didn't want to do any heavy lifting. Not saying that ESRI would ever do that btw. Looking forward to seeing these capabilities come to life!!!! ... View more

Not seeing anything for road signs or data? ... View more

Trying to bump this question again. Is this something a AGO or Portal administrator can see? ... View more

That's excellent news! Thanks for clarifying. Your initial response seemed that maybe this wasn't something you were thinking about. Glad this is not the case. Very happy this is on the roadmap!!!!!! ... View more

Hi Jeremiah Johnson‌. I appreciate the comment, though I have to disagree some as not having feature parity between the web app and the native app proves logistically challenging. When I talk about the "office", I am also talking about home offices. We only have one iPad, but everyone has access to a PC. Sometimes the person planning the mission might not necessarily be the pilot. We keep the iPad with the UAV. It becomes a pain having to to shuttle a iPad back and forth for full mission planning capabilities (particularly when everyone is working from home in this Covid world). Obviously, we could buy more iPads, but that's hard to justify on the cost side. As someone very (very!) interested in purchasing Sitescan, I would appreciate feature parity. This gives us the best value and flexibility for mission planning. Honestly, the product becomes confusing when functionality doesn't match. The web app should have all the same flight modes\tools and LAANC authorization as the IOS app. ... View more