S123 Custom URL Scheme and Relevant Expressions

182
6
Jump to solution
05-16-2019 06:19 PM
Highlighted
New Contributor III

Hello...is passing field parameters from Collector to S123 no longer possible for fields with a relevant expression? This no longer works for me. I also checked previous surveys that worked but now do not (I haven't changed anything). I'm using S123 3.3.64 but also tested with 3.4.96 without any success.

Thanks.

Reply
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Esri Frequent Contributor

Hi Tony,

Yes that is correct, it is no longer possible to send values via custom url to questions that are not relevant when the form loads. We used to store values in fields that were not relevant, which was wrong and considered a bug as when sending the survey those values got stored in feature service. This was fixed in a recent release which means now the question must be relevant on load to store the value.

Phil.

View solution in original post

Reply
0 Kudos
6 Replies
Highlighted
Esri Frequent Contributor

Hi Tony,

Yes that is correct, it is no longer possible to send values via custom url to questions that are not relevant when the form loads. We used to store values in fields that were not relevant, which was wrong and considered a bug as when sending the survey those values got stored in feature service. This was fixed in a recent release which means now the question must be relevant on load to store the value.

Phil.

View solution in original post

Reply
0 Kudos
Highlighted
New Contributor III

Hello Philip,

I don't quite understand why this functionality was considered a bug. I've written the url scheme to pass the parameters from collector to s123 because I wanted those values to get stored in the feature service. My survey is a lot more cluttered now because this ability was removed.  For example, we have a check s123 workflow that is used to audit forest renewal assessments. With a previous release of s123, the auditor would identify the trees on the site being assessed and compare those against what was originally assessed. Doing so only brought up the original surveyed tree numbers (passed via url) and a question for the auditor to record their tree numbers for the species selected.  Now I have to show all originally assessed tree number values up front as partially illustrated below. This complicates the survey as most of the time only a few species exist at the site yet all these 0 values now get displayed on the survey for trees not present. This workflow is further described in the following ArcNorth News story

Any suggestions on how I could simplify my survey to the way it was previously when this 'bug' existed? 

Thanks.

Tony Viveiros

Impact of no longer storing values via custom url to questions with a relevant expression...a cluttered survey.

Reply
0 Kudos
Highlighted
Frequent Contributor II

Create a set of hidden fields - then pass the values to them (or use Notes if you want the user to see the values).  Then base the relevants off these hidden fields.  You can then even default the hidden in case values are not passed in.

Highlighted
New Contributor III

Thanks for the tip Doug.  That worked.

Tony

Reply
0 Kudos
Highlighted
Esri Frequent Contributor

Hi Tony,

Great to hear the solution Doug provided worked for you, he beat me to it, I was also going to suggest using hidden fields to load the values into, so that they are always available and stored, and then if you need to access them in other questions you can use calculations to grab those values, and they will still update whether the question is relevant or not.

As for why storing and sending values to the feature service in not relevant questions was considered a bug (by other users and customers, not just us) is related to the definition of a not relevant question. If a question is deemed not relevant, it means the user completing the survey should not see that question and not be able to answer that question, as it is not relevant to them. Therefore when they submit the survey, they should not submit answers for that question either. In your case the way you designed the survey to pass values from url scheme, it may have made sense and been a good workflow, but technically it was incorrect, you were sending answers to questions and storing them with valid answers in the feature service even though they were not relevant to the survey.

The problem is that once the data is sent and viewed in the feature service, it is not possible to tell if those questions came from relevant or not relevant questions at the time of sending the survey. For example, if you can imagine that there was a select one question, and based on the answer to it, there were several following questions, but different answers to the select one had different following questions. If the user picked one answer, completed all the following questions, but then changed their mind or realised they made a mistake, went back up the survey and changed the select one answer to a new choice, then completed the newly displayed following questions, if we were continuing to store not relevant answers, when they sent the survey the answers will be sent for the questions that were not relevant from the first set they answered by mistake. In the feature service they will have now answered both set of questions related to the different answers in the select one. This will be an issue when summarising and analysing the data, performing statistical analysis or printing reports.

Hope this helps clear it up and glad that you now have a workflow that is working for you.

Phil.

Reply
0 Kudos
Highlighted
New Contributor III

Hi Philip,

Thanks for the explanation.  I can understand how storing data in not relevant questions would be be a problem and considered a bug.

Tony 

Reply
0 Kudos