Latest Contributions by ScottPrindle

Hey Thomas, Archiving isn't required for offline workflows to be supported. When it comes to feature services and sync, the requirement is either enabling archiving or versioning on the datasets. At a minimum, one of these is needed for sync to function. It sounds like there are two processes that we should separate to address the issues you've encountered: Offline edits being synced to the "child of the child". Unregistering the replica, and rec and post of the edits in the "child of the child" to the child, then to DEFAULT. If your edits from the runtime geodatabase (.geodatabase) aren't appearing in the "child of the child" version, then there is something going wrong during sync. Number one should be verified before attempting to delete the offline map. During your testing, do you see any edits making it back to your enterprise geodatabase? If we can examine this part of the workflow, we can determine if there's a problem getting edits from Pro to EGDB. Number two above is primarily a cleanup process. The replica that gets unregistered when you delete an offline map is maintained by ArcGIS Server and the geodatabase. Once you remove that, sync can no longer be done with the runtime geodatabase you had downloaded previously. As you noted, removing the offline map in Pro will also delete the runtime geodatabase from your machine. It is possible to make a copy of this file to back things up if you think things aren't going as planned (ex. location: C:\Users\username\Documents\ArcGIS\Projects\projectName\featureServiceName_GUIDvalue.geodatabase). Based on all of the details you've shared so far, I would be curious if there are any errors or additional information in the ArcGIS Server logs at the DEBUG level. Information about the sync process will show up under the SyncTools GP service. This will purely be focused on figuring out what is going on with your offline edits, and isn't necessarily related to versioning yet. At the end of the day if everything is working as expected, but the versioning management is still a headache(450 may get tedious without automation via Python), you might consider sticking with only archiving, but splitting out your regions with separate feature services. This would cut out any version trees you'd need to manage, where a region's data is dictated by a definition query on the layer (ex. based on a "region" field). This is just another approach to consider, but it could directly address your concerns about "child of the child" versions building up in your database. To somewhat cover how ArcMap is editing with "Create local copy for editing": this client is taking more of a web editing approach to offline editing. It will query the service to place all of the data in a file geodatabase in your user profile. Any editing is done against that local data, which is technically offline. The difference is when you go to synchronize your offline edits, ArcMap will submit an applyEdits operation. This is essentially how a web application (Web AppBuilder, ArcGIS Online, etc.) will edit in a connected environment. The big difference between ArcMap and Pro is that when this "Create local copy for editing" process successfully syncs, the local copy is removed from your machine. Pro is using a more complex process (with versioning/archiving and all that), but it will actually synchronize rather than submit an applyEdits request. Additionally, that offline map will persist, allowing a user to continue working offline, without creating another local copy for editing. I hope this information is useful, but let me know if there are other concerns it raises. Thanks, Scott ... View more

Hello Thomas, This is the same sync workflow that has been used with Collector for some time now. There is a bit of a footprint in the number of versions created, but these should be managed by ArcGIS Server as long as the offline map and its associated replica remain open. The way that ArcMap edits a feature service does not use sync, so it can't be used as a direct comparison for this workflow in Pro. When publishing versioned data as a feature service, a new version "child of the child" should be created for each downloaded map. This note describes how this child version is named. Since this is a versioned dataset, the need to reconcile and post will be maintained on all of these offline maps. If you have 100 people downloading an offline map, that's 100 child versions to maintain the version hierarchy down to the client. When you delete the offline map in Pro, its replica at REST should also be removed. In your versions at this time, "Esri_Anonymous_<feature service name>_<ID>" will remain. Since this is versioned data, your edits remain in this child version until you rec and post back to the first generation child (which the feature service is using). As long as the offline map was synced before it was removed, all edits should be in that "child of the child". As you noted, archiving is another option for managing edits for sync. If versioning is not required for your data model, or the rec and post process is too time consuming for the number of editors you'll have, then archiving may be the way to go. In the end, offline maps used by Collector and Pro are extending the versioning tree a step further via replication. Some of the links above can be used to build context around what all of the moving parts in Pro, ArcGIS Server, and the Enterprise Geodatabase are doing. Let me know if this raises any new questions! Thanks, Scott ... View more

Hello Inge, Thank you for submitting this idea! Please check out the Collector-Integration GitHub repository for what's currently possible with the custom URL scheme. It looks like there is already a similar issue, so it may be helpful for the Collector development team if you share your comments there as well. If your request differs enough (or you have other requests), feel free to create a new issue! Thanks, Scott ... View more

Hello Steve, Thank you for submitting this idea! I've gone ahead and removed the Collector category so this idea can remain focused on Web AppBuilder. If you would also like to see this functionality in Collector as well, I recommend submitting a new idea to allow us to track votes for each application. Thanks, Scott ... View more

Hello James, Thank you for submitting this idea! Aside from number of visitors for a given period of time, what would you say is a good measure of popularity? What kind of data points do you believe would show the importance of a given point of interest, with regards to your business an retail use cases? Any additional information or clarification you can provide will help us examine how this could potentially be addressed. Thanks, Scott ... View more

Hello Zach, Have you signed up for the https://community.esri.com/community/gis/applications/collector-for-arcgis/blog/2017/09/06/the-aurora-project?sr=search&searchId=c91c5850-fdf2-40a6-b56e-3fd2ccfc61e2&searchIndex=1 yet? I bring this up because some of your concerns about accidentally moving points due to that tiny sliver in Collector are addressed in the beta. It's still in the works, but there are many design changes going into it that may address some of your other concerns. Being in the Early Adopter's Community is also a great way to make sure your voice is heard, since the Collector development team is active in addressing feedback as beta testers put the app to the test. Thanks, Scott ... View more

Hello all, When voting for this idea, please consider leaving a comment to share your use case. How could geofencing be used in your current workflows to improve productivity? What other improvements do you envision it offering for your projects? Thanks, Scott ... View more

Hello Nick, Thank you for submitting this idea! It looks like there are two angles to your request: Option to capture a full resolution picture with the device's camera, but only upload a thumbnail to the service. Option to store a thumbnail and the full resolution picture on a hosted feature layer. Each of these requests sound like interesting improvements. Could you provide a current workflow or project where this would improve collection of data? How are you addressing this need currently in your workflows? Everyone else, When voting for this idea, please consider leaving a comment to share your use case. What types of projects are you accomplishing today with Survey123 or Collector where this functionality would be useful? Aside from smaller uploads/limited bandwidth, how do you envision this improving your workflows? Thanks, Scott ... View more

Hello Nick, Thank you for submitting this idea! It looks like there are two angles to your request: Option to capture a full resolution picture with the device's camera, but only upload a thumbnail to the service. Option to store a thumbnail and the full resolution picture on a hosted feature layer. Each of these requests sound like interesting improvements. Could you provide a current workflow or project where this would improve collection of data? How are you addressing this need currently in your workflows? Everyone else, When voting for this idea, please consider leaving a comment to share your use case. What types of projects are you accomplishing today with Survey123 or Collector where this functionality would be useful? Aside from smaller uploads/limited bandwidth, how do you envision this improving your workflows? Thanks, Scott ... View more

Hello James, Thank you for submitting this idea! Just to clarify, you would like the ability to configure this automatic submission of surveys at the survey level, rather than in the Survey123 app itself? Could you share any workflows or projects where the timeliness of survey submissions is required? This additional context can help us better understand your needs in this space. The "Push Only" option in Collector is a little different than the functionality you've described. This setting allows the user to only push their edits up to the service. When enabled, a sync in Collector will not request new/updated features to be downloaded from the service. In low bandwidth areas, this can be useful since you would only be uploading, and wouldn't have to worry about downloading a large file with every sync. Thanks, Scott ... View more

Hello Amanda, Thank you for submitting this idea! I've removed the Survey123 category, since this is requesting functionality within Web AppBuilder and its widgets. The cascading form functionality seen in Survey123 is primarily inherited from XLSForms, which define the data structure for services to be published from Survey123 Connect or the website. The service contains more complex configurations than most feature services and data models published for other uses, so I can see how the Smart Editor Widget may take a lot of effort to mimic some of these behaviors. When you say you want the cascading form functionality from Survey123 in Web AppBuilder, are you only interested in hiding/showing fields, disabling fields, and calculations? Or are you interested in more of the functionality that XLSForms have to offer? You had also mentioned a need for easier editing of related records in general. Is this something that you find difficult in all widget configurations that allow you to add or update related records, or is this idea primarily focused on the cascading form functionality? Would it be feasible to move the entire workflow into Survey123, either using an existing feature service, a new survey with the Inbox, or a combination of the two? Are there other tasks that these workers accomplish within your Web AppBuilder application that must remain as a separate app? Thanks, Scott ... View more

Hello Amanda, Thank you for submitting this idea! I've removed the Survey123 category, since this is requesting functionality within Web AppBuilder and its widgets. The cascading form functionality seen in Survey123 is primarily inherited from XLSForms, which define the data structure for services to be published from Survey123 Connect or the website. The service contains more complex configurations than most feature services and data models published for other uses, so I can see how the Smart Editor Widget may take a lot of effort to mimic some of these behaviors. When you say you want the cascading form functionality from Survey123 in Web AppBuilder, are you only interested in hiding/showing fields, disabling fields, and calculations? Or are you interested in more of the functionality that XLSForms have to offer? You had also mentioned a need for easier editing of related records in general. Is this something that you find difficult in all widget configurations that allow you to add or update related records, or is this idea primarily focused on the cascading form functionality? Would it be feasible to move the entire workflow into Survey123, either using an existing feature service, a new survey with the Inbox, or a combination of the two? Are there other tasks that these workers accomplish within your Web AppBuilder application that must remain as a separate app? Thanks, Scott ... View more

Thank you for submitting this idea Jeremy! I've gone ahead and removed Survey123 from the categories, since this idea appears to be specific to Workforce and assignment statuses. In your current workflows, how are you handling this need for approval/rejection of assignments by the dispatcher? Thanks, Scott ... View more

Thanks for the clarification Andrew! When examining the behavior for both the install process and the update notification, I was also drawing comparisons to Pro on my end. Others, When voting for this idea, please consider leaving a comment to share your perspective on the current update process for Survey123 Connect, and how it is impacting your organization. Thanks, Scott ... View more