Working with existing Feature Services in ArcGIS Survey123

99330
137
09-25-2017 12:03 PM
IsmaelChivite
Esri Notable Contributor
36 137 99.3K

[Last updated October 11, 2019]

[Last updated March 15, 2021]

 

Typically, when you publish a new survey with Survey123 Connect or the web designer, a new feature service is created on your behalf. Data submitted with your survey will be stored into that new feature service. We built Survey123 this way because we wanted to simplify as much as possible the process of building new surveys. We did not want people having to worry about feature classes, domains and all of that. Instead, we took an approach where the focus is on adding questions and rules to a form, and leave the creation of the data model to the software.

There are some valid cases however, where you may want to publish a survey that works on top of an existing feature service; In this blog post I will describe how this can be done. 

 

Why would you publish a survey on top of an existing feature service?

There are multiple scenarios where building a survey on top of  an existing feature service  makes sense. I will describe in more detail some of them:

  • Databases: ArcGIS Enterprise allows you to create feature services on top of commercial databases like Microsoft SQL Server, Oracle, etc. There are good reasons why people want data in them although in most cases the key is interoperability. Data in databases can be handled via SQL queries which many software stacks, including ArcGIS, support. In order to have Survey123 add, update or read data from these databases you must first create a feature service on top of them and have your survey work with it.
  • Existing data: You may have feature services that were created way before Survey123 existed.  By building Survey123 smart forms on top of these feature services, you want to be able not only to add new features, but even update existing ones. A classic example is asset inspections: You may already have feature services with thousands of assets... what if you want to now have Survey123 work against these assets to enable inspections through smart forms?
  • One feature service, many surveys: In some scenarios, you may want to create multiple surveys on top of the same feature service.  For example, say you have 3 distinct geographic areas where different field crews operate.  While you want to consolidate all data in a single feature service, you also want to tailor the survey for each team.   Each field  crew will use its own flavor of the survey, including a distinct offline basemap, custom defaults and trimmed-down choice lists according to the area at hand. 
  • Another example is that where you want to use Survey123 to manage the complete life-cycle of an incident: one survey is used to report a case, a second survey is used to review the initial report and may be a third survey is used to close the case.  In this scenario, all three surveys work against the same feature service, but each presents or hides different questions according to the purpose of the survey at each step of the cycle.

Pre-requisites

Survey123 can only work against feature services where the supportsApplyEditsWithGlobalID property is set to true.  There is a detailed explanation of how to meet this requirement in the https://community.esri.com/groups/survey123/blog/2018/07/17/how-to-turn-supportsapplyeditswithgloabl... blog post, but in short here what you will need:

  • Your feature layer must be either hosted in ArcGIS Enterprise or ArcGIS Online.
  • If using a multiuser geodatabase, layers can use Branch versioning, but not Traditional versioning. To understand the difference betwen the two, check this help topic.
  • Your layer must have an indexed GlobalID field and all relationships, including attachment tables, must leverage GlobalID fields.

How to create a survey on top of an existing feature service?

You can build a survey on top of an existing feature service using Survey123 Connect.  First. you will need to be logged-in against ArcGIS Online or your own ArcGIS Enterprise instance.  Then simply click on New Survey and select the Feature Service option.

 

 

Once you select the Feature Service option, the gallery on the right will show you every feature service shared with your account.  For ArcGIS Online, this will include all hosted feature services and in ArcGIS Enterprise, all hosted feature services plus all federated feature services shared with you. 

If you want to use a service from an ArcGIS Server instance that is not federated with Portal for ArcGIS, then you will need to follow instructions in this KB article to register your service in your portal through a feature layer item.  Otherwise, your service will not be shown in the gallery.

Ok, so next you need to select the feature service of your interest and give your survey a name.  Once you click on Create Survey, Survey123 Connect will look into your feature service, checking all fields, related tables and geodatabase domains. A new XLSForm will be created for you as a starting point for your survey. I will call it the initial XLSForm design.

 

Understanding the initial XLSForm design

In the next few sections I will describe the rules followed by Survey123 Connect to generate the initial XLSForm design. Understanding these rules is important, because you will often want modify the initial XLSForm to tailor the user experience of field users using your survey.

One question per feature layer field:

Other than a few exotic exceptions, that I will describe later, Survey123 Connect will add a new question to your initial XLSForm design for every field in the first  layer of your feature service.  The questions will be added to the survey XLSForm worksheet in the same  order as fields appear in your feature layer.  You can reorder the questions in your survey and you can also remove any questions you may want to hide. 

Reordering questions can be very handy, because the order of fields in a table may not respond to the logical order in which you want people to enter data in your form.  Removing questions in the XLSForm can also be useful, because you may have fields in your feature layer that you do not want to expose to users. Think of internal fields that people in the back-office will use but that are not meant to be visible to field users for example.

XLSForm Question types:

The initial XLSForm design assigns XLSForm question types based on the corresponding feature layer field type, according to the following table:

esriFieldTypeIntegerinteger
esriFieldTypeDoubledecimal
esriFieldTypeStringtext
esriFieldTypeDatedatetime
esriFieldTypeGeometry (point)geopoint
esriFieldTypeGeometry (polyline)geotrace
esriFieldTypeGeometry (polygon)geoshape
esriFieldTypeGUIDtext

 

There are some notable exceptions to the rule above.

  • First, reserved fields in your feature layer will not be added to your XLSForm: ObjectID, GlobalID and Editor Tracking Fields will be ignored.
  • If your layer includes attachments, you will need to add image questions manually.
  • Fields in your feature layer that have a coded value domain will be modeled as select_one questions and the corresponding coded values will be automatically added as a list in the choices worksheet.

The correspondence of Esri field types to question types in XLSForm, as described above, is a best guess to ensure data consistency. That is, if you were to publish the survey, you are guaranteed to be able to submit data to all fields in the feature service.  However, you may want to adjust the XLSForm types depending on your needs. For example:

  • Esri date fields are modeled in XLSForms as datetime, but you can choose to change the XLSForm to just time (if you want to capture time) or date (if you do not care about the time).  You should avoid changing the XLSForm question type to decimal or text for example, because the types would not be compatible.
  • Esri string fields will be translated by Survey123 Connect as text questions, but you could switch the XLSForm type to integer or decimal for example if you wanted to provide a numeric user input.  You could also use question types such as barcode against text fields.
  • If attachments are enabled in your feature layer, you can add one or more image or audio type of questions in your XLSForm.

One key concept to remember is that the XLSForm question type fundamentally defines the type of user input that will be presented in the form. As long as the input captures a data type that is compatible with the corresponding target feature layer field, you are fine.  For example: Do not expect the calendar control exposed by a date XLSForm question to generate data that is compatible with a field of type decimal.  Now, if you feel like you can accelerate data capture using a barcode question against a string field, you can replace the initial text type of question with a barcode question because barcode question types will always return an output that can be stored as a string. You can also use the appearance XLSForm column to refine the user input experience.

XLSForm bind::esri:fieldType and fieldLength:

If you look carefully at your XLSForm, you will also note that Survey123 Connect added in the bind::esri:fieldType column the exact Esri data type found for fields in your feature layer.  The bind::esri:fieldLength column will also contain the length originally set to your feature layer fields.

You should never change the esri:fieldType, because they are defined by the feature layer and Connect will not be able to change your layer. 

You could change the length, as long you make it shorter. Making the length shorter in XLSForm allows you to limit the user input. For example, if your field has a length in the feature layer of 200 characters but you want to limit the user input from your survey to 5, simply change the bind:esri:fieldLength value to 5.  You are not allowed to specify a fieldLength in your XLSForm that exceeds the actual length of the field in your feature layer.

You will rarely have to change the bind::esri:fieldLength and bind::esri:fieldType columns. If you do, you may trigger an error when attempting to publish the survey.  The reason is that Survey123 Connect has a built-in check to ensure that a published survey is compatible with the underlying schema of your feature service. If the schema are not compatible, then you will not be allowed to publish the survey.  Tinkering with the bind::esri:fieldLength and in particular with bind::esri:fieldType can easily result on schema inconsistencies.

Question Names and Labels:

The XLSForm name column reflects the exact field names found in your feature layer. You cannot change the values in this column.  The label column is populated using the field name alias from your feature layer. You can do whatever you want with the label column (except leaving it empty).  You may want to rephrase questions, embed  html formatting etc, etc   

Repeats (related tables):

In the event that the first layer in your feature service is related to other layers or standalone tables, you will see the presence of repeats in the XLSForm.  In Survey123 we model related geodatabase tables/layers as repeats.  The name of the repeat will be defined by the table name of the related table or layer and cannot be changed. The label of the repeat can contain any text you like.

Within the XLSForm repeat block, you will find questions corresponding to the fields found in the related child table. The rules for how questions are added within a repeat are exactly the same as for questions in the main feature layer. The rules for changing question types, labels etc as well as for removing or reordering them are the same too.  Just be aware you cannot take questions outside of the repeat (removing them is fair game, but not to take them out of the repeat block and into the main block of the form)

Select_ones:

I want to add a few notes on how select_one questions behave.  In short, every time a field in your feature service uses a coded value domain, a new select_one type of question is created.  The coded value domains are matched by a corresponding XLSForm list in the choices worksheet.  You are free to reduce the number of choices in the list if that makes sense for you. You can also change the labels in the list as you see fit. 

The values in the name column of the choices worksheet need to remain unchanged because otherwise, you will be adding data into your feature service outside the valid values set by your geodatabase domain.

Range domains are modeled as range questions in XLSForms.

Geodatabase subtypes and contingent values are ignored by Survey123, although you can use cascading selects to model them.

Other XLSForm columns and question types: 

As far as the survey worksheet in your XLSForm, columns and question types other than the ones described above will not be used. That is, the default, calculation, constraint, relevant columns etc will be empty.  Question types such as groups, notes or calculates will also never be present in the initial XLSForm design.  Now: you can, and should, use those extra columns and question types as appropriate to build a great data capture experience. For example:

  • You can use XLSForm groups and pages to break down questions in your survey into logical sections. This simplifies and accelerates data capture without altering the original geodatabase schema in your feature layer.
  • You can leverage XLSForm notes and hints to provide field users with critical information to capture data more  efficiently. Similarly, notes and hints have no effect on the geodatabase schema.
  • You can use constraints, relevant statements as well as input masks, calculations and defaults to better control user input.
  • Appearances are also a great way to optimize the field data capture experience.

The initial XLSForm design is just that: a starting point. Take pride of your surveys and transform flat GIS data models into beautiful smart forms.

Once you are happy with your design, you will proceed to publish your survey. When publishing, no new feature service will be created for your form. Instead, the feature service you selected will be referenced by your survey.

Settings worksheet:

The settings worksheet of the initial XLSForm contains two key pieces of information:

  • submission_url: This column defines the url of the feature layer item in your ArcGIS Organization on which responses to your survey will be stored. This is the exact url of the feature layer you chose in the Create New Survey dialog as the seed of your survey.  Note that this is the url to the feature layer item, rather than the url of the feature service itself. 
  • form_id: This column defines the name of the layer in your feature service that your survey will hit.  If empty, your initial  XLSForm design will always point to the first layer found in your feature service.

While you often may not want to change the submission_url, there is one use case where  changing the form_id is very handy.  Think for example, that you want to create a survey on top of a related standalone table.  For clarity, lets think of a feature service with parcels (polygons) and their related assessments.  You may not want to build a survey to edit the parcels, but you may want to create one to create the assessments. Typically, when you get the initial XLSForm design, you will have questions in your survey for all the fields in the parcels layer and then a repeat group, with all questions in the related assessment table. This is only because in a feature service, typically the layer with geometries (parcels in our case) goes first, and then the related tables.  To create your parcel assessment survey you will delete all questions  corresponding to the parcels layer from your survey and then take the name of your assessments repeat and put it into the form_id setting.  Finally you will delete the begin_repeat and end_repeat rows in your survey. 

To ensure that assessment data is properly attached to the corresponding parcel, it is important that in your survey you preserve a question to enter the unique identifier of the parcel. You will need to know what field in the child assessment table is used for the geodatabase relationship.

Limitations when working with Repeats in your XLSForm:

Mapping the ArcGIS geodatabase model into an XLSForm is possible to some extent, but there are some limitations to bear in mind.  In the case that you are working with existing feature services published from ArcGIS Desktop, there are chances that you could run into some situations where you simply cannot build a survey on top of a feature service, or at least not the exact survey that you had in mind.   The truth is that you can actually build surveys pretty much on top of any feature service, except when working with related tables.  Lets get into the details:

  • The XLSForm specification does not accept two questions in a single survey with the same name. This makes sense because otherwise you could not uniquely reference the question in your XLSForm expression.   When working with existing feature services this will be a problem when you have related tables AND fields in both tables with the same name.  In some cases this is not a real problem because you may not want to include the repeat on the survey. You may also be able to delete one of the questions referencing the duplicated field name (from either the main body of the survey, or from within the repeat). But this is not always the case...
  • The XLSForm specification does not accept spaces in the name of a repeat.  This is a problem when you have a related table in your feature layer that includes spaces in the name. If you encounter this you can do two things: One is obviously to delete the repeat group from your survey all together. If you cannot delete the repeat then you can ask the owner of the feature service to publish the feature service again, eliminating the space in the name of the related table. Of course this may not be possible in many cases, but I bring this up because changing the name of a layer in the feature layer does not imply changing the name of the table in the database.  All you need to do is to change the name of the layer in the table of contents in ArcGIS Desktop and publish again.
  • The XLSForm specification does not like spaces in the name column of the choices worksheet: This will be a problem when you have coded values in a domain that include spaces in them. Fortunately, you will only get a warning when validating your XLSForm in Connect. You will actually be able to publish your survey with no problem, but it is not good practice to use spaces.  It is also technically possible to encounter coded values in domains that exceed the maximum length of 32 characters allowed by choice names.

Some tips and other things to be aware of:

  • In the old days of Survey123, people used to create the initial XLSForm designs by hand and from scratch. If you really understand the meaning of the submission_url and form_id XLSFom settings and you understand how to map fields in your feature service to XLSForm question types, you can do it.  Typically using the Create Survey from Feature service option as described above is the best way to go, but forcing yourself to build a survey from scratch on top of an existing feature service will be a good learning experience.
  • Sharing can be problematic! Keep in mind that while you will always be the owner of the survey you are publishing, you may not be the owner of the underlying feature service.  Unless you are the owner, you can't really control the sharing, so you will want to make sure that your feature service is made available to users that will access your survey.
  • Capabilities: Similarly, unless you are the owner of the feature service, you will have no control over the update, query, delete and add capabilities of the feature service. It is your responsibility to make sure your survey is consistent with the capabilities enabled in the service. For example, if the feature service does not support updates, then you should not enable the Inbox.
  • Hosted Feature Layer Views: You can create surveys on top of hosted feature layer views.  Views are a clever way to securely limit access to features and or columns in an existing feature service. Views also allow you to better control sharing of your feature service.  There are some scenarios where you may want to create surveys on top of views, rather than directly on top of the feature service.

 

137 Comments
JamesTedrick
Esri Esteemed Contributor

Hi Andrew,

Unfortunately, Survey123 doesn't support calculating photo names or duplication of images.  

TimothyKing3
Occasional Contributor

Hi all,

I have a survey that was created by another individual in our company, and I need to update it.  So far I have moved the feature service and form to My Content, but now I want to make changes to the survey that are primarily cosmetic by hiding some fields and changing some choices.  Since this is a live survey I am a little nervous as I do not want to do anything that will impact the survey in a negative way.  Any help would be appreciated!


Thanks,

LTK

JamesTedrick
Esri Esteemed Contributor

Hi Timothy,

Did you place the form & feature service in a folder, or is it in the root of My Content?  We would encourage it to be in a folder; after that, you will need to discover the folder's ID and copy that into the survey to ensure publishing occurs successfully.  The easiest way to discover the folder's ID is to right-click on the title of the folder in the left sidebar and select "Inspect Element" - this will open up a view of the code of the web page.  The folder will appear with an <a> link, with a data-id property that specifies the ID:

Download the Survey into Survey123 Connect and open up the survey's folder (the folder button).  Then, either close Survey123 Connect or move it back to the gallery of surveys (so the form is no longer being previewed).  Open up the <form name>.itemInfo file in a text editor (Notepad++ or another more complex editor would be best) and look for the ownerFolder property.  Replace that value with the id of the new folder and save.  After that, you can reopen the form in Survey123 Connect, edit and republish.

TimothyKing3
Occasional Contributor

Thanks for the quick response James!  I did copy the survey into an identical folder in My Content. I then realized that the original survey was created with an earlier template so I downloaded the advanced template, copied the old data into the advanced template and added the submission_URL.  I then attempted to Publish the survey and had to do some tweaking but was able to get it to work adding data to the originally created feature service. This will mean that the crews will have to redownload a new form but it will have the benefit of having the advanced functionality.  Do you see any issues with the way that I accomplished this?

Thanks,


LTK 

JamesTedrick
Esri Esteemed Contributor

No, there shouldn't be any issues if you created a new survey from the template - that would take care of the folder management issue.

RamiAlyGad
New Contributor II

I have a situation that I believe most closely relates to Ashlie Hildebrand‌ 's question above.

Ismael explained that, with using an existing feature service(fs), you can use the same or less fields that already exist in the fs for questions in your survey. However, I am left wondering, what about adding fields to the survey that aren't and shouldn't be fields in the fs.

My company has a project to create a Transmission Line Inspection workflow using Collector and Survey123. The idea is to view transmission lines and transmission structures(poles/towers) on the map in Collector. Then, be able to click on a structure to view the pop-up with the existing attributes so they can be updated if incorrect. In addition to existing attributes, we would look to embed a survey123 url into the popup to open a Survey123 form with completely different questions/fields in regards to conditions of different elements at the structure.

Once a record is sent using that form, we would like to retrieve past inspection records, also by clicking on the structure in collector. 

After reading this whole Post w/comments, my viewpoint has changed to involve the following assumptions:

1. A new feature table would need to be created in the enterprise geodatabase for "TransmissionInspections"

2. The new table would need to have a relationship to the Transmission Structures(poles/towers)

3. The map read by Collector would have to include the new feature table that is related to the structures (in addition to the structure fs) so it can be opened from the structures popup (to view past/existing records).

4. There would be no need a have a geopoint field in the survey because the records would all be related to a structure location.

Do my assumptions capture the best and most logical practice? I envision a circular flow of the data. 

PaulCone2
Occasional Contributor III

I've finally a got a survey working -- for ATC-20 post-earthquake building inspections -- that uses an existing feature service.  Building footprints are polygons, and then there is a related table with inspections, as well as a table for one or more photos per inspection.  Thank you to everyone who helped with that.  However, now when I look at the survey at survey123.arcgis.com, rather than seeing the inspections in the related table, I see ALL the building footprints as records (e.g. 200,000+ survey records).

How can point survey123.arcgis.com to the related table so I can see just the inspections?

LynnBerni
Occasional Contributor II

Can I publish a survey based on related nonspatial tables in an existing feature service? I need to create a survey to populate the BacteriaBatch/BacteriaSamples tables:

SampleSites (points) === 1:M ===> BacteriaSamples (table)

BacteriaBatch (table) === 1:M ===> BacteriaSamples (table)

Here's more detail, if needed:

Currently we collect field data on paper forms, and then manually update an Access database. We're working to streamline this process, but we want survey data to populate SDE (not my AGOL).  I've built the survey to collect our Bacteria data in Connect, and its working great in my AGOL...but creating everything "from scratch" in SDE is a little more complex. Relationships are so confusing!!  I'm attempting to model things so we can use Survey123.

Bacteria Survey

We test for bacteria (ecoli, etc.) each month and it is a 2-day process. Day1:  Samples are collected at multiple sites (one sample per site) and then processed as a batch in the lab. Day 2, the samples are taken out of the incubator to see what grew.  Based on this workflow, I created a survey with batch level questions and samples in a repeat. It works like a charm and will really simplify our data collection process. But, in my AGOL the batch level data is saved as point data (feature layer), and samples are in a related table. What we need is both as nonspatial tables in SDE.


From the original blog post, the example of collecting parcel assessment data that would populate the related table only---by changing the form_id in a survey created from an existing feature service (which has spatial data with a related table) and deleting all questions that point to the spatial data---makes perfect sense. This is exactly what we need! But will it work if both are nonspatial?  I haven't tried yet, thought would I would ask first.

Hope this makes sense.

Please advise, thanks!

JamesTedrick
Esri Esteemed Contributor

Hi Lynn,

Are SampleSites and BacteriaBatch independent of each other?  You describe the collection of batches at SampleSites.  It also sounds like you have different fields in BaccteriaSample to store the relationship between SampleSites and BacteriaSample and between BacteriaBatch and BacteriaSample? 

From you description it sounds like this could be modeled through 2 forms, one to record each day's progress.  You would use the Inbox functionality to load data collected on Day1 in Day2's form

LynnBerni
Occasional Contributor II

Yes, our SampleSites points are independent of BacteriaBatch. And yes, we have fields to store the relationships.  For each batch, we collect multiple samples (one sample per site). The BacteriaBatch ("batch-level") data pertain to all samples in the batch (e.g. date/time/incubator temp when all samples go into the incubator, date/time/temp when they come out, expiration dates for the bottles used to collect the samples, staff that collect & process the samples, etc.).  Data recorded for each sample (in the repeat) includes things like date/time collected, weather, results after incubation, etc.  One batch, many samples.

I haven't yet explored the Inbox functionality, but we do record batch level data and individual sample data on both days.  We've been saving the survey as a draft on Day1.  I'm not sure how to get away from the repeat, and thus the need for a related table....if that's what you meant by two forms.

LynnBerni
Occasional Contributor II

Hi James,

Here's a sketch of the data relationships in our database, which you might find helpful.  As mentioned, I want to build a survey to populate the Bacteria Batch TO Bacteria Samples tables.  One batch, multiple samples processed per batch. 

Mossor_Colleen
New Contributor II

I created a survey based on a building feature service, which has about 10 fields in it. I also added about 20 new questions that I need in the survey, but they don't need to be fields in the feature service. Where are the answers for these non-feature service questions stored? I can't seem to find them in either the feature layer data view or through the data view in Survey123. 

WilliamParco_GISP
New Contributor II

Thanks for this detailed write up. Survey123 has been a boon for my field workers and when we started out making surveys against our own services there was a lot of trial and error. This gives a lot of great information on what to expect and some tips we definitely didn't know.

PaulCone2
Occasional Contributor III

It appears something changed recently -- now I am only seeing the related records, which is what I want.  ???

WillPlatt
New Contributor III

I am also trying to use Survey123 to do pole inspections.  Have you figured out how to get this to work?

Thanks

DavidBuehler
Occasional Contributor III

Hi James,

I am referencing your comment a few above.

"You can create a survey against a feature service built for other applications.  The main limitation is that Survey123 does not automatically add image questions when reading the feature service, you would need to do add them manually; additionally, you will only be able to add one image per question (you can have multiple image questions to capture multiple images)."

I think this response is along the same vain as the conundrum I am trying to solve with Workforce and Survey123 integration.  Is it possible to push multiple photos  to the attachments of a Workforce feature service from Survey123?  I ask because the field names need to be different in Survey123 unless you are using a Repeat which pushes the photos to a related record table, not attachments table.  I am looking at workflow that doesn't require jumping between "apps" to take pictures.

JamesTedrick
Esri Esteemed Contributor

Hi David,

I'm not sure I understand the workflow you are asking about.  Workforce itself has the ability to attach photos to a task; you wouldn't need Survey123 for that.  You could create a survey that works with the Workforce task, but that would only add photos to a new task, as Survey123 does not support adding attachment during the editing process.

DavidBuehler
Occasional Contributor III

James,

I think I figured out what I wanted to do.  I am trying to bludgeon a combination of Workforce and Survey123 to get the best of both worlds because my users want one environment/ one app to work in.  I want the photos based on a survey123 form prompting them to take them at the time of the inspection form being filed out (survey123), while leveraging the useful parts of workforce (i.e. easy to use dispatching and work notifications).  So in short I am trying to push notifications to Workforce via Survey123 and push from Workforce to a specific Survey123 form, and if there is already a specific Survey123 form for an open event use that survey.  Let's just say the two are not as integrated as they should/could be.

DavidBuehler
Occasional Contributor III

Hi James,

Correction to my last post.  Things did not work as anticipated.  It is possible to push multiple photos from a survey123 survey to a Workforce feature service in AGO?

JamesTedrick
Esri Esteemed Contributor

Hi David,

The easiest method to accomplish this is to have a Survey123 form created to work with the task layer of the Workforce project and include multiple image questions.  An alternative can be done using webhooks (Webhooks—Survey123 for ArcGIS | ArcGIS ), though webhooks that utilize attachments are more complex (see Automatically extract attachments from Survey123 using webhooks as an example).  Finally, this might be doable via a python script once the data is posted (it would be a modification of https://community.esri.com/groups/survey123/blog/2017/03/22/working-with-your-survey123-photos ).

NusratFatema1
New Contributor III

Hi ,

 I am trying to use an image type of question to capture a picture when I do a survey. I have an existing feature service with a survey  feature layer in it. When I try to  publish the survey, it give me the following error

Please help.

 Thank You

Nusrat

IsmaelChivite
Esri Notable Contributor

Hi Nusrat Fatema‌. It looks like your feature layer does not have Feature Attachments enabled.

NusratFatema1
New Contributor III

Hi Ismael,

 Thank You  so much. Currently I am using a hosted service .But I my ultimate goal is to use a non hosted feature service. Thanks again

Nusrat

Ramakrishnankamal_raj
New Contributor

Hi,

As per the instruction I was able to create and publish Survey123 form using existing ArcGIS Server feature service.  Also I could submit data from Survey123 mobile application.  But when I access the Web app of the same form and submit, it throws an error 'Failed to Submit - Cannot find matched feature service json'.  I was not able to proceed further.

Please advice.

Thanks,

Kamal 

JamesTedrick
Esri Esteemed Contributor

Hi Kamal,

The error appears to be an issue with the web app accessing the feature service.  This might best be debugged via a technical support case - could you file one and work with Esri Support?

PhilipMcCarthy
New Contributor II

Hi ismael chivite and james tedrick

This is a great article - thanks.

Following the steps contained in it I was able to create a feature service from a feature class I created and which sits in an ArcSDE database sitting behind my department's firewall. I was then able to publish that feature service to my ArcGIS online account.

I then used the 'Survey 123 Connect for ArcGIS' desktop application on Windows to create a basic survey form using the feature service that I found in the list of those available.

This created the survey form based on the definition of the feature class which make sense to me.

I was then able to submit a record using the form and this turned up ok in the data for the form in https://survey123.arcgis.com/ 

The record however did not turn up in my database behind my department's firewall. This is what I really want to happen.

Your article seems to suggest this is possible, but I'm not 100% sure?

Obviously the 'Survey 123 Connect for ArcGIS' desktop application' was able to build the form from the information in the feature service, but can the form send data through to the actual feature class in the database through the firewall. Its this bit I don't understand.

I'd be very appreciate of any insights you have.

Thanks, Phil.

ParasAcharya1
New Contributor

Hi James Tedrick

Is it possible to integrate the collector and survey 123 so that I can create new features (points,lines and polygons) in the field using collector app and record the attributes for those newly created features using survey 123 form published using same feature service. I was hoping this will help me to customize the attribute information collection as survey 123 allows relevant functionalities and I can set it up to show only fields that are required to collect based on the feature type field within the features.

If it is possible can you provide some insight on how do I go about it?

Thanks for your time.


Regards

Paras

JamesTedrick
Esri Esteemed Contributor

Hi Phil,

Given what you describe, if the data is visible in the Survey123 website, it should be in your enterprise geodatabase.  I would check the item details page for the form, and go to the linked feature layer to confirm that it is the feature service corresponding to your enterprise geodatabase (which you had to register to your AGOL account).

JamesTedrick
Esri Esteemed Contributor

Hi Paras,

It is possible to configure this, though it would require the use of the Inbox to load the feature into Survey123 after creation in Collector.  It is more common to use an application link to pass information from Collector to create a new entry in Survey123.

PhilipMcCarthy
New Contributor II

Thanks James. I had to give up on it, the data would always turn up in the Survey123 website, but no matter what I tried it would not go into our database behind the firewall. I could never setup the feature service with anything other than query access.

ElizabethGoetz
New Contributor II

Hi James Tedrick

Thanks for all of your responses - this string has been really helpful. I have a related problem - I have a set of hardscape polygons that we need to do condition assessments on. I have them set up in Collector but the interface doesn't support the "spinner" function, which is hugely helpful in the field. 

I managed to create a S123 (table and repeat) for the polygons, then appended the existing polygons into the table. Using the Inbox function, I can get a list of the polygons and then use the repeat to do the condition assessment, but the polygons don't draw on the map. I have to assume that this is because polygons aren't supported in Survey123. Is it possible to get the polygon centroids to draw on the Inbox map instead of the polygons? 

JamesTedrick
Esri Esteemed Contributor

Hi Elizabeth,

Polygon and Line support is in progress - you may want to check out the Early Adopter Community.

ElizabethGoetz
New Contributor II

Thanks James, will do!

ParksCamp
New Contributor III

I have a question about attachments and repeats the was mentioned in an early comment, but never fully answered.

 

I am building a form against an existing feature class with attachments enabled (and "supportsApplyEditsWithGlobalIds": true). If I build the form with a single 'image' type, I can publish and the survey allows the user to attach a single photograph. However, if I try to add a repeat around the 'image' type (to allow for multiple photographs), the survey will not publish, with the error "Table XXX not found" (where XXX is whatever I name the repeat).

 

So, how do I configure the form to allow for multiple photographs?

 

Thanks,

Parks

BrettStokes
Esri Contributor

Hello Parks,

You can simply continue to add image questions to your XLSForm in Connect and re-publish. Since you have attachments enabled in your feature layer, this can include multiple attachments.

Adding a repeat around a single image question is actually trying to add a related feature (with the name corresponding to your repeat) to your existing feature layer. Since your existing feature layer does not contain any related features you are presented with the error message. You will need to set up this relationship in order to get this working. This is most easily achieved in desktop by adding the relationship class and re-publishing your feature layer. Re-creating the survey based on your updated feature layer in Connect will read this related feature as a repeat and add this to your survey form accordingly. Just make sure that attachments are also enabled on the related feature layer.

 

Hope this helps,

Brett

PamelaLandy
Occasional Contributor

I generated a survey from a feature service (FClass), after publishing it and capture data, I wanted to add photos but I did not have the attachment enabled. Then  enable attacchment  and re-publish the service ( arcmap), Now when  I want  to add the field image  in the form I can´t go back to pick up the initial survey, mentions that you can not find the table  :

The custom entities service  url is not compatible with the survey (Not found  fcdemsurvey table)

(FClass).  I have reviewed and the item is the same.

JoeBryant1
Occasional Contributor III

Any update on this?

JoeBryant1
Occasional Contributor III

I also have this question.

Did you find out any more information, Kevin?

VickyS
by
Occasional Contributor

Hi James

As Survey123 does not support versioned data how do esri recommend administrators manage conflicts?  Will the JS API be update in future to support versioned data or is client generated GlobalID's the way esri is moving? 

Thank you

Vicky

JamesTedrick
Esri Esteemed Contributor

Hi Pamela,

Can you provide a screenshot of the feature service URL listing the layers/tables in it?

JamesTedrick
Esri Esteemed Contributor

Hi Kevin,

If the form has a repeat section, you can omit the foreign key field from the form - that will be handled automatically by Survey123.  If you are creating a form that contains just the related table, you should include the key field (for example, parentglobalid is the default field for feature classes created by Survey123 Connect) in the form.  One way to do this is to have it as a hidden field in the form that receives a value via a URL that opens the form from a pop-up; another way would be to have a single choice questions whose name values (what gets stored in the database) match the values of objects in the parent feature class.

JamesTedrick
Esri Esteemed Contributor

Hi Joe,

Out of the box support for feature services is not present, though it can be done with the in-beta custom JS functions.  Please visit the Survey123 Early Adopter Community for more information.

JamesTedrick
Esri Esteemed Contributor

Hi Vicky,

In terms of where Esri is going to support versioning in a services context, take a look at - An Introduction to Branch Versioning 

KevinKozak
Occasional Contributor

Hello Joe,

Sorry I did not get back with you sooner. I was out on a wildfire dispatch.

I reviewed my question and think I remember the answer. My data has a bridge point feature service that relates to a bridge inspection. And the bridge inspection relates to elements. These are two different services. The bridges are in collector and the inspection and elements are in survey123. At that time, to relate the bridges to the inspections I had to create a text question in survey123 that had guid as it name. I would pass the bridge GlobalID to this text field through a URL link from the bridge popup window. Then I would calculate the inspection guid from the text field. It was very confusing and Ismael helped me set it up. The Inspection to elements worked just fine from the relationship class that I used in ArcMap because they are in the same service.

However, I think the relationship problem has been corrected in a later version of survey123 so you might want to ask I Ismael it that is true.

Kevin

DSIProvince_Nord
New Contributor III

Hi,

I have the same issue, it has been reported here also : https://community.esri.com/thread/226606-cannot-find-matched-feature-service-json-error-survey123 

Do you have any idea regarding a potential workaround ? I tried to recreate my feature service with preauthentification but didn't work.

Thanks

DSIProvince_Nord
New Contributor III

Hi,

I found a workaround by turning the related table into a feature class (in this case I have now a polygon FC related to a point FC). Even with no polygon geometry written by Survey123, it works fine. I think that the bug only appears with related tables without geometry.

JohnWatson_EBA
Occasional Contributor

Hey James Tedrick‌ ~ switched jobs recently but still working with surveys....this one is new, however. Pulled a feature service from Portal down into Connect and created/tweaked survey from that, then tried to publish. It has a related table with repeat count set to 1. The custom feature service submission url is not compatible with this survey (Unsupported relationship type esriFieldTypeString in key field ASSET_ID for table ASSET_ID). The related table is called FlushingValves. There is a field called ASSET_ID in the table. It is not a required field. I haven't seen anything online about this so I figured I'd ping you...

JamesTedrick
Esri Esteemed Contributor

Hi John,

This indicates that there is a non-GUID-based relationship present, which Survey123 does not support.

JohnWatson_EBA
Occasional Contributor

That would be it, my relationship is based on that Asset ID field. I’ll have to change that. Thank you, sir!

JohnWatson_EBA
Occasional Contributor

James, I have the same message, this time on the GlobalID field:

Unsupported relationship type esriFieldTypeGlobalID in key field GlobalID for table GlobalID.

My relationship class is built off the GlobalID field in both the table and feature class.