Latest Contributions by BillSimper

‎02-15-2023

Thank you so much for posting this kind sir-- you saved my project!

‎11-17-2022

It looks like it is possible to open a specific existing record into a Survey123 form in the field app. There's hardly any ESRI documentation for this feature (it'd be nice to see some and for this to be fully explained in a blog post). Here is what worked for me: arcgis-survey123://?itemID=itemIDofyourSurvey123FormHere&action=edit&q:globalid=globalidofyourSurvey123recordhere&update=true The globalid of your record should be the 32 character alphanumeric with dashes. Here are some caveats: 1) spell globalid as 'globalid', not GlobalID or globalId (unlike the ESRI example linked to below) 2) this feature uses the Inbox, so that has to be turned on in your S123 form 3) it's a good idea to turn off the Sent box in your form as this will interact with the Inbox and probably result in problems when trying to get this feature to work 4) I think you need that last part &update=true in order to refresh the Inbox. I'm not sure if you need &action=edit for this to work but you probably want this for your purpose I got this to work through lots of trial and error and by referring to this web page: https://doc.arcgis.com/en/survey123/reference/integratewithotherapps.htm There are other permutations that work, like: arcgis-survey123://?itemID=itemIDofyourSurvey123FormHere&action=edit&q:where=globalid='globalidofyourSurvey123recordhere'&update=true The form above (using single quotes) works for text fields generally (just avoid space characters or maybe URL encode the spaces). You can also query integer fields, including objectid, for example: arcgis-survey123://?itemID=itemIDofyourSurvey123FormHere&action=edit&q:where=objectid=integerObjectIDofyourrecordhere&update=true or arcgis-survey123://?itemID=itemIDofyourSurvey123FormHere&action=edit&q:objectid=integerObjectIDofyourrecordhere&update=true For objectid, be sure to spell it 'objectid' and not objectId or objectIds (as in the ESRI example). Apparently this field can be named differently from feature layer to feature layer so you may want to check to see how your field is spelled. This blog post outlines how to do the same thing using the web browser version of Survey123 (instead of the Field App): https://community.esri.com/t5/arcgis-survey123-blog/survey123-tricks-of-the-trade-editing-records-in-a/ba-p/895827

‎10-06-2022

I'm having this problem too. The only survey that is causing it makes extensive use of 'linked content' specifically CSV files uploaded to ArcGIS Online and used for choice lists using the select_one_from_file field type.

‎01-28-2022

Did some more trial and error this morning on different devices and figured it out. Long story short, it doesn’t just depend on what org the *signed in* user is… it also (now at least) depends on the org of the user *that downloads or updates the form*. In this case I’d downloaded the form to Survey123 with a corporate org account, then signed out of that account and signed back in with my HUB org account and tried to use the form. This has worked for me in the past. Anyhow, after either delete and reinstall, or just ‘update’ the form when the Hub account is signed in to S123 it will now work with the Hub account as expected. Did the same from the corporate account and now Hub account doesn’t work again. Also confirmed that it’s not the same form republished (i.e. two forms that look the same and named the same)—it’s the singular form that lives on Hub. This is an issue that most users will probably never encounter (because why share to someone in an org that wont work anyhow?), but just adding it to the record.

‎01-27-2022

Hi Phillip, I'm having this problem ('Javascript functions are disabled'). My form is published in our Hub org and I'm signed into Survey123 with a Hub account (actually tried with several Hub accounts). This had been working previously, it's been a few months since I've looked at this form.

‎10-21-2021

Hi @ZacharySutherby, Thank you for the constraint tip- that'll go some distance to mitigating our problem. I'm still kind of confused about this phenomenon though. For example, the Time Control works fine when used in the form when the record is first submitted-- as expected a 5 character string is created and stored in the hosted feature layer (until it's submitted it looks like the form is treating it as an integer, i.e. Unix Time). So that string exists in the feature layer data, and is being successfully downloaded to the form via the Inbox-- we know this because the value shows up when we navigate the repeat, and even if we dont navigate the repeat, Survey123 knows that there is a value present because it doesn't complain that a required field is lacking a value when re-submitting. Furthermore, if I change the question type from Time Control to just a Text field (in a separate, cloned version of the original form specially made to retrieve, view and edit these records) and refresh the Inbox, then the Summary comes out wrong (which I understand and expect based on your response) *but* re-submitting the form will not overwrite the existing values with blanks. So the question is why is the Time Control acting this way when a simple Text field does not? And can this control be fixed (in the Survey123) so that it doesn't do this? This is the first I've heard that this is expected behavior (I'm not following your comment about validation)-- is there someplace I can read up on this mechanism? I'm also baffled by some differences between how a form behaves in Survey123 Connect versus the Survey123 field app. One way I tried to work around this issue was simply to make the problematic time field a text field (with or without an input mask) so that users could simply type in the appropriate value. When I do this and adjust form's javascript code to simply append these text values together (in a calculated field outside the repeat) it works as expected in Connect (you can see that code commented out in the script). However this breaks in the Survey123 field app for some reason-- the summary won't work. Because our users insist that these summaries are absolutely necessary when filling out and submitting a survey, I'm then forced to keep the time control and parse out the hours and minutes from the Unix time value.... but this leads to the data deletion problem if that record is ever accessed through the Inbox. So any ideas why something would work as expected in Connect (correct concatenation of string fields in the repeat) but not in the Field App? Thanks for your help with this!

‎10-20-2021

Haven't submitted a bug. The survey was published using Connect (using v 3.13 but also earlier versions) and was not version locked. Null fields and repeat_count don't seem to apply.

‎10-20-2021

Hi Phillip, here's an XLS form (and associated javascript code in the txt file) that illustrates both problems. To see the problem populate several Visit repeat records with time values, submit the record and then open it from the Inbox. The values in the summary fields, except for the first, will show as NaN:Nan (until all values are scrolled through), which isn't great, but the real problem is that if the record is submitted without scrolling through all repeat records, then blank values will be written back to the HFL, overwriting the existing data. However the form will not complain that the required fields are blank, leading me to believe that the data has been downloaded but is somehow not being 'loaded' from the form's perspective. To see the problem with input mask, you have to submit a record, then open that record in the WEB form (from a Dashboard). Then it will be blank and that blank value will overwrite the existing value if the record is submitted.

‎09-17-2021

Hi, writing in to report a pernicious problem that is cropping up in certain situations. The general pattern is that an existing record in a Hosted Feature Layer with properly populated fields is being retrieved somehow into S123 (via Inbox or via URL scheme in a Dashboard) and, under certain ideosyncratic conditions, some populated values show up in the retrieved record as blank. If the record is re-submitted, these blank values will overwrite the existing correct values in the data layer. One example are text fields with input masks retrieved in the web browser version of S123. They are being linked to from a Dashboard. The input masked fields come in blank, but when the mask is removed they come in properly (this is the workaround in our case). Another example is 'time' control fields in a repeat (retrieved into the field app via Inbox). In this case the values on all sub-records (except the very first, which does show up) are treated as blank until the reviewer manually scrolls through all repeat records. If the reviewer does not do that and resubmits the survey, then blank values will be written to the source data. As you know these 'time' values are stored as text, so changing the field type to 'text' solves this problem; however in our case this breaks some other necessary functionality (for an unknown reason-- embedded javascript is involved). Both of these examples occur in QA/QC workflows where reviewers are retrieving records submitted by other users on other devices. So we just want to bring it to your attention, since the end result if unaddressed is that a normal review will actually corrupt existing data. Thanks!

‎06-18-2020

In my field (conservation biology), there will always be a need for users to have access to offline basemaps. This is an area which is often fraught with problems for lots of users for various reasons. On Collector/Explorer-- the mechanism is pretty good. There's room for improvement but generally a persistent user can get what they need and if a download fails at least you know it failed (though these error messages could be much more informative!). There's even a mechanism for sharing basemaps across different maps/projects for a given user. However, they cannot be shared with other apps (as far as I know). On Survey123-- offline basemaps are a pain for form developers to create and the download process for users isn't great. Often, with large basemaps they will partially download and quit, but not show an error message-- instead they just won't work and the user won't know why (without checking the file size on device vs ArcGIS Online). Also, the user must manually go in and specify which basemap they want showing with EVERY individual survey-form-record-- it doesn't persist (unless it's specified by the form designer, which has other problematic effects if the specified basemap wasn't downloaded). On QuickCapture-- ability to use web maps and standard basemaps is awesome. However MUST be used in Online mode. Kudos for keeping it simple (in the spirit of QuickCapture) but not great for obligatory offline-mode users. So my proposal is to create a mechanism by which offline basemaps that are downloaded to device are available to ALL ArcGIS mobile apps (above) on that device. Ideally the user would be able to specify which basemap (or series of basemaps in order of user-specified priority or spatial extent / zoom level in relation to current location) they want to use in the Settings for a given app (and this would persist across surveys/projects/records until changed in App Settings by user). Additionally, I'd suggest creating a dedicated stand-alone mobile app for downloading these shared-offline basemaps. This would standardize the process across all apps, while also saving your app-development teams from having to re-invent the download interface for each particular app. If there was a dedicated development team for this downloader app, then the focus could be making it both flexible and bullet-proof functionally as well as easy and intuitive to use (and fully documented) and the other mobile apps would benefit from this. It also means that I, the form designer and technical intermediary in our organization, only have to teach one methodology for obtaining these necessary basemaps instead of keeping track of different capabilities across each app (which I can do with effort, but can be very confusing at the end user level). Thanks for listening!

‎06-18-2020

In my field (conservation biology), there will always be a need for users to have access to offline basemaps. This is an area which is often fraught with problems for lots of users for various reasons. On Collector/Explorer-- the mechanism is pretty good. There's room for improvement but generally a persistent user can get what they need and if a download fails at least you know it failed (though these error messages could be much more informative!). There's even a mechanism for sharing basemaps across different maps/projects for a given user. However, they cannot be shared with other apps (as far as I know). On Survey123-- offline basemaps are a pain for form developers to create and the download process for users isn't great. Often, with large basemaps they will partially download and quit, but not show an error message-- instead they just won't work and the user won't know why (without checking the file size on device vs ArcGIS Online). Also, the user must manually go in and specify which basemap they want showing with EVERY individual survey-form-record-- it doesn't persist (unless it's specified by the form designer, which has other problematic effects if the specified basemap wasn't downloaded). On QuickCapture-- ability to use web maps and standard basemaps is awesome. However MUST be used in Online mode. Kudos for keeping it simple (in the spirit of QuickCapture) but not great for obligatory offline-mode users. So my proposal is to create a mechanism by which offline basemaps that are downloaded to device are available to ALL ArcGIS mobile apps (above) on that device. Ideally the user would be able to specify which basemap (or series of basemaps in order of user-specified priority or spatial extent / zoom level in relation to current location) they want to use in the Settings for a given app (and this would persist across surveys/projects/records until changed in App Settings by user). Additionally, I'd suggest creating a dedicated stand-alone mobile app for downloading these shared-offline basemaps. This would standardize the process across all apps, while also saving your app-development teams from having to re-invent the download interface for each particular app. If there was a dedicated development team for this downloader app, then the focus could be making it both flexible and bullet-proof functionally as well as easy and intuitive to use (and fully documented) and the other mobile apps would benefit from this. It also means that I, the form designer and technical intermediary in our organization, only have to teach one methodology for obtaining these necessary basemaps instead of keeping track of different capabilities across each app (which I can do with effort, but can be very confusing at the end user level). Thanks for listening!

‎06-18-2020

In my field (conservation biology), there will always be a need for users to have access to offline basemaps. This is an area which is often fraught with problems for lots of users for various reasons. On Collector/Explorer-- the mechanism is pretty good. There's room for improvement but generally a persistent user can get what they need and if a download fails at least you know it failed (though these error messages could be much more informative!). There's even a mechanism for sharing basemaps across different maps/projects for a given user. However, they cannot be shared with other apps (as far as I know). On Survey123-- offline basemaps are a pain for form developers to create and the download process for users isn't great. Often, with large basemaps they will partially download and quit, but not show an error message-- instead they just won't work and the user won't know why (without checking the file size on device vs ArcGIS Online). Also, the user must manually go in and specify which basemap they want showing with EVERY individual survey-form-record-- it doesn't persist (unless it's specified by the form designer, which has other problematic effects if the specified basemap wasn't downloaded). On QuickCapture-- ability to use web maps and standard basemaps is awesome. However MUST be used in Online mode. Kudos for keeping it simple (in the spirit of QuickCapture) but not great for obligatory offline-mode users. So my proposal is to create a mechanism by which offline basemaps that are downloaded to device are available to ALL ArcGIS mobile apps (above) on that device. Ideally the user would be able to specify which basemap (or series of basemaps in order of user-specified priority or spatial extent / zoom level in relation to current location) they want to use in the Settings for a given app (and this would persist across surveys/projects/records until changed in App Settings by user). Additionally, I'd suggest creating a dedicated stand-alone mobile app for downloading these shared-offline basemaps. This would standardize the process across all apps, while also saving your app-development teams from having to re-invent the download interface for each particular app. If there was a dedicated development team for this downloader app, then the focus could be making it both flexible and bullet-proof functionally as well as easy and intuitive to use (and fully documented) and the other mobile apps would benefit from this. It also means that I, the form designer and technical intermediary in our organization, only have to teach one methodology for obtaining these necessary basemaps instead of keeping track of different capabilities across each app (which I can do with effort, but can be very confusing at the end user level). Thanks for listening!

‎06-18-2020

In my field (conservation biology), there will always be a need for users to have access to offline basemaps. This is an area which is often fraught with problems for lots of users for various reasons. On Collector/Explorer-- the mechanism is pretty good. There's room for improvement but generally a persistent user can get what they need and if a download fails at least you know it failed (though these error messages could be much more informative!). There's even a mechanism for sharing basemaps across different maps/projects for a given user. However, they cannot be shared with other apps (as far as I know). On Survey123-- offline basemaps are a pain for form developers to create and the download process for users isn't great. Often, with large basemaps they will partially download and quit, but not show an error message-- instead they just won't work and the user won't know why (without checking the file size on device vs ArcGIS Online). Also, the user must manually go in and specify which basemap they want showing with EVERY individual survey-form-record-- it doesn't persist (unless it's specified by the form designer, which has other problematic effects if the specified basemap wasn't downloaded). On QuickCapture-- ability to use web maps and standard basemaps is awesome. However MUST be used in Online mode. Kudos for keeping it simple (in the spirit of QuickCapture) but not great for obligatory offline-mode users. So my proposal is to create a mechanism by which offline basemaps that are downloaded to device are available to ALL ArcGIS mobile apps (above) on that device. Ideally the user would be able to specify which basemap (or series of basemaps in order of user-specified priority or spatial extent / zoom level in relation to current location) they want to use in the Settings for a given app (and this would persist across surveys/projects/records until changed in App Settings by user). Additionally, I'd suggest creating a dedicated stand-alone mobile app for downloading these shared-offline basemaps. This would standardize the process across all apps, while also saving your app-development teams from having to re-invent the download interface for each particular app. If there was a dedicated development team for this downloader app, then the focus could be making it both flexible and bullet-proof functionally as well as easy and intuitive to use (and fully documented) and the other mobile apps would benefit from this. It also means that I, the form designer and technical intermediary in our organization, only have to teach one methodology for obtaining these necessary basemaps instead of keeping track of different capabilities across each app (which I can do with effort, but can be very confusing at the end user level). Thanks for listening!

‎02-11-2020

Hi James, Yes, specifically I've been using the calculation parameter of XLSFORM to assemble the URL and create the link as a text question type to dynamically pass field values (text and numeric data types) as above. Here's a typical example using the concat function: concat('<a href="arcgis-survey123://?itemID=XXXXXXXXXXXXXXXXXXXXXXXXX&field:parent_uuid=',${survey_uuid}, '&field:individual_id=', ${individual_id}, '&field:alive_dead=', ${alive_dead}, '&field:sex=',${sex}, '">Click here to open a CHILD form.</a>') The correct form is opening up when the link is clicked, but no data being passed in. This is on forms where this was working previously, so had been tested and was working-- and continues to work when run using version 3.2.

‎02-11-2020

It looks like this field value passing via Survey123 URL scheme is broken in recent versions of Survey123 field app. Forms that utilized this feature are failing with version 3.5 and 3.7, but still work using version 3.2 (posted here). Anyone else noticing this? Did something change with URL scheme (or the concat function)?

Online Status	Offline
Date Last Visited	‎03-11-2023 01:31 AM

My Ideas

Latest Contributions by BillSimper

Re: Offline Map - SQLite Error

Re: Passing Workforce Assignment GlobalID from Collector to Survey123

Re: Error converting XLSForm [Errno 2]

Re: Survey123 form now shows "Scripts disabled" for value calculated using Javascript function

Re: Survey123 form now shows "Scripts disabled" for value calculated using Javascript function

Re: field value retrieval problem with certain field types/parameters cause blank values then written to source data

Re: field value retrieval problem with certain field types/parameters cause blank values then written to source data

Re: field value retrieval problem with certain field types/parameters cause blank values then written to source data

field value retrieval problem with certain field types/parameters cause blank values then written to source data

Share Offline Basemaps across all Mobile Apps (and dedicated downloader app)

Share Offline Basemaps across all Mobile Apps (and dedicated downloader app)

Share Offline Basemaps across all Mobile Apps (and dedicated downloader app)

Share Offline Basemaps across all Mobile Apps (and dedicated downloader app)

Re: Understanding Survey123's custom URL Scheme

Re: Understanding Survey123's custom URL Scheme

Re: Passing Workforce Assignment GlobalID from Col...

field value retrieval problem with certain field t...

Re: Survey123 Hangs When Publishing

Share Offline Basemaps across all Mobile Apps (and...

Share Offline Basemaps across all Mobile Apps (and...