Custom urls that should open in Collector (arcgis-collector://?itemID=xyz) do not open

Question

I'm having a similar issue to this post, except in my attribute template popup, I'm configuring links to open other maps in Collector itself (i.e. arcgis-collector://?itemID=xyz) and the map with this attribute template popup is opened in Collector.  In other words, I want to open a map in Collector that has layers with attribute templates that open other maps in Collector.

If I long press on one of these links and choose the copy option then paste the link into Safari it successfully opens the new map in collector.  I have seen in other posts that Collector now opens all urls in an external browser (Safari) but this does not seem to be true - 10.4.2 still opens them in a Collector browser window.  I suspect if it opened them in an external browser, the custom url scheme would work.

Also, if I open the same map in Explorer for ArcGIS and click one of these links, Collector opens the requested web map.

Jade_Freeman · Answer

Hi Doug,

Thanks for the response.  I understand iOS apps have to register custom url schemes but the arcgis-collector:// scheme is already handled by Collector correct?  This is the url scheme we are trying to open which you indicated is not currently handled when invoked from within Collector itself.

We are using Collector to allow building maintenance staff to collect the location of various building equipment within the buildings on our campus.  Within our equipment management system, every piece of equipment is uniquely identified by an equipment number.  We have our backend RDMS containing the geodatabase setup to synchronize attributes from that system to feature classes within the geodatabase so that when a new location is mapped and the equipment number added as one of the attributes, a trigger on the feature class table will pull in all of the equipment attributes from the equipment management system.  These are also synchronized back to the geodatabase when updated within the equipment management system.  Additionally, mechanics can update attributes from within Collector while they are standing in front of the equipment rather than writing information down and taking it back to the office.  This allows maintenance mechanics to document the exact location of equipment (we might have 5 fire extinguishers within a hallway that is 600 ft. long - how do you know which is which if all you know is the room number) using a georeferenced floorplan for context.  Additionally, we can use spatial relationships between the equipment and room polygons to push updates back to the equipment management system when the floorplan changes.

The main difficulty is that with over 600 buildings on our main campus we have over 30 possible floors (Sub-Basement, Basement, Ground, Terrace, First, Second, Penthouse, Mechanical Deck 1/2/3, Mezzanine etc.) and every building has a unique combination of floors.  In other words, some buildings may have a ground floor and first floor while others may have just a first floor - there has been little standardization as these buildings were designed and built over the last 100 years.

This can be difficult for maintenance mechanics who may be responsible for 30 different buildings each.  Our first attempt was to create a map that had a floorplan layer for every possible floor, and as you cannot group a feature editable service layer within a dynamic map service layer (and within the feature service itself you cannot group layers nor include non-editable layers), we also included an equipment layer for every possible floor.  The underlying service for these layers had a unique feature template setup for each floor level layer that defaulted the floor attribute to the appropriate value for that floor.  So, if a mechanic wants to map a location on the first-floor, they turn on the first-floor floorplan layer and the corresponding first-floor equipment layer.  Initially we only had a single equipment layer and the mechanics were supposed to set the floor attribute manually however, this lead to problems such as turning on say the ground-floor floorplan but setting the floor value on equipment to first-floor.  It also lead to an enormous number of layers for the mechanic to manage.

Our current approach, which is aimed at really simplifying things for the mechanic is to create separate maps for every building and floor.  This quite a large number of maps and so we use the REST API (ArcGIS Portal) and FME to do this automatically.  We also record in the geodatabase the item ID for each map and the building and floor it is associated with.  The equipment layer within each map is set to the appropriate feature service that has the feature template set to autopopulate the correct floor value for that floor level.  We then create a single index map that pulls in a list of hyperlinks using the arcgis-collector://itemId=xyz url scheme in the popup for each building:

Notice in this next one the url for the hyperlink:

We are currently having the mechanic install both Explorer and Collector and sign into our portal in both.  They then open the index map in Explorer and can open the floor-level map from the popup for any building.  They can then collect features on that floor and when they are ready to move to the next floor they can switch back to explorer and just click the next hyperlink.  This works pretty well however, we would like to include the building index layer in the each floor-level map so the mechanic would never have to leave collector.  They would open the building popup and move to the next floor all within Collector.

We also have built a WAB application that we've used to map over 17,000 equipment locations.  However, this is being used mainly in the office and as such is not being used to verify/update equipment attributes nor attach photos.  On the other hand, the initial approach I described above using a single web map has been piloted by a single mechanic who has not only collected over 600 locations but has also been able to use collector to collect vital attributes like make, model, serial number and add photos of the equipment which aides in equipment identification later on.  While this is fairly impressive, it has taken a lot of training and support as well as verification, QA/QC etc.  We would like to roll this out to more of our field staff but feel we need to simplify the process for the mechanic as much as possible which has lead to the second approach.  All the mechanic should have to do is click on a building, pick the floor they want to work on, wait for the map to load in Collector and start collecting features.

Hope this clarifies the workflow we are trying to achieve!

DougMorgenthaler · Answer

Hi Jade-

Two things to note here.

First, iOS is pretty stringent about requiring each app to declare exactly which URL schemes that are recognized.  If a scheme is present that isn't explicitly declared, it's deemed untrusted and will not launch.  We currently support a limited set of schemes for our apps.  As an aside, Android and Windows do not have this restriction.

On he second point, Collector isn't designed to launch from itself.  I'd appreciate if you could share some additional information about the workflow you're trying to accomplish.  If you prefer you can send an email to collector4arcgis@esri.com.

Jade_Freeman · Answer

Thinking about this some more, eventually we want to include custom url scheme links to apps other than Collector or Explorer and I'm wondering if these will not work for the same reason?

Does Collector, Explorer, Survery123 only support custom url schemes to other Esri apps?  If so, why?