Working with existing Feature Services in ArcGIS Survey123

09-25-2017 12:03 PM
Esri Frequent Contributor
32 130 65.2K

[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.


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 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:

esriFieldTypeGeometry (point)geopoint
esriFieldTypeGeometry (polyline)geotrace
esriFieldTypeGeometry (polygon)geoshape


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)


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.


Occasional Contributor III

You'll want to create a field on the table with a GUID data type and relate that GUID field to the point / line / polygon FC Global ID and everything will work.

New Contributor II

Hey James Tedrick

I've configured a survey to work with an already existing hosted feature service that has since been integrated into a website using ClientID/Secret. I now need to add an additional field to the form/feature service and am unable to. When I try to add it in the form i get that error "the field doesn't exist in the feature service." However, through AGO I am not seeing the option to add a field. I'm logged in as the data owner, have tried adding the field after toggling editing privileges for the layer and the two view layers built off of it, and have tried adding the field through Pro where I'm hit with error 000852. Since I am the data owner and the data is not read only, the only thing I can think of is that there is somehow a lock created by the ClientID/Secret used to access the data through the website.

Your thoughts on how I could successfully add a field to this survey and feature service are very much appreciated!

Esri Esteemed Contributor

Hi Matthew,

If this is a hosted feature service, you should be able to add a field via the Item Details Page > Data tab, to via the table view in the Map Viewer. This is separate from editing privileges (which govern the ability to new features into the feature class).  

New Contributor II

Thanks for the quick reply James. I am familiar with this process for adding fields through the Details Page > Data Tab. Unfortunately, with this particular feature service there is not an option to add a field where it normally should be. There are only options to append data to layer, show/hide selection, and clear selection. All my other hosted feature services have the option to add fields. I can't think of anything other than a schema lock somewhere although i'm not sure how AGO handles those.

Esri Esteemed Contributor

A schema lock in the DBMS sense isn't something that should be encountered with a hosed feature service (i.e., one whose url begins with .  I would open a ticket with Esri Support to investigate what is occurring.

New Contributor

Hello James Tedrick‌,

I want to do the same walkthrough but on workforce for ArcGIS with ArcGIS enterprise , I want to create assignments on a feature service that is not hosted on ArcGIS datastore but on a feature service that uses enterprise geodatabase . I would be grateful if there are some steps that elaborates how to get this done

Esri Esteemed Contributor

Hi Islam,

This would be best addressed in Workforce for ArcGIS

by Anonymous User
Not applicable

Hi James Tedrick and Ismael Chivite,

We are trying to develop a Crash survey so that our staff could add the vehicle crash points using survey 123 with portal. So, I developed a survey from a scratch using survey 123 Connect with repeats/ related tables. The new feature services will be hosted on portal. The problem is we already have a crash feature class and related tables with more than 100000 crash points.  I was wondering if there is any way I could add/upload our existing 100000 records into the new feature class on portal and can see all these points on Survey123. The reason why I created the survey (XLS form) from scratch instead of just using the existing Feature Service is the Schema. Our new schema is bit different and have more fields than the older one. 

Any suggestions will be highly appreciated. 


Esri Esteemed Contributor

Hi Pnakaj,

Yes, you can append in the existing points into the near feature service.  Given your description, I would recommend using the Append Tool in ArcGIS Pro - Append—Data Management toolbox | ArcGIS Desktop ; alternatively, you can append data to a hosted layer using via the Item Details page for the service or using the ArcGIS API for Python.

by Anonymous User
Not applicable

Hi James Tedrick‌,

Thanks a lot for your reply. I was able to append the existing FC into the new Survey123 FC but related records are not showing up on the portal. So, in my existing GDB I have “Crash_test” FC and “Injury 2” table. I created a relationship class “Crash_test_Injury_Test_GUID” using “Crash_test” as an Origin Table and "Case_Number" field as PK. In my Survey123, I have “Crash Report” FS and “Trafiic_details” table created through relate. After creating relationship class, I appended the existing old data with the new one but the related records are missing. If I just append the “Injury2” related table with the “Trafiic_details” related table on ArcPro, the data is appending but relation is still missing on Portal. Am I missing something? Any help would be highly appreciated. I am using Federated server with portal.



Esri Esteemed Contributor


It looks like you are trying to append both datasets into one layer (/0) - you should be appending each dataset into the corresponding layer (You should see multiple layers in the feature service information).

by Anonymous User
Not applicable

Hi James,

Thanks for your help. I appended the FC with the FC and table with the table separately but the related records were not carried forward on Portal as well as in Survey123 Inbox. I have created a relationship class with crash FC and Injury Table.   

Alternatively, I created a new survey for the crashes with the same relationship using Existing Feature services, but the related records are not showing up in Survey 123 Inbox. I can see the related records on portal but not in Inbox.  

Thanks in advance


Esri Esteemed Contributor

It sounds like the GlobalID's may not have been transferred in the append- there's an environment setting to make sure they are preserved.

For the new survey's Inbox, you specified the query in the bind::esri:parameters column, correct?

New Contributor II

Hi, James Tedrick

I am working with a survey published from an existing feature service and trying to collect information from the public while simultaneously not showing that same information to the public. Using the feature service settings identical to this post and views I have been successful on AGOL and within the Survey123 website, except that if I, or other users within my organization, bring the feature service into ArcPro the data is no longer hidden from the service that the survey form relies on. This seems like a big security problem but I am wondering if I am doing something incorrectly. 



by Anonymous User
Not applicable

Thanks a lot James, It worked, I forgot to add he query in the bind::esri:parameters column. 

But now I have another issue. I am getting this error "unable to perform" when I am trying to submit surveys. I am using existing services with ArcGIS enterprise on Portal. I have enabled my attachments, editor tracking, archiving but couldn't enable sync as data is not versioned.  My "supportsApplyEditsWithGlobalIds" is true. Any idea what could be the problem.

Thanks in advance

Esri Esteemed Contributor

Hi Sky,

Thanks for reaching out.  I am not seeing the behavior that you describe in Pro with a test survey that I set up (that was published in Survey123).  We may need to dive a bit deeper on the exact configuration of the feature service and members in your survey.

If you are using an existing feature service, Survey123 does not create views to help manage access (this is because in many cases it cannot create views with existing feature services).  That means that the main feature service will need to  have the settings applied, which it sounds like you have done.

If this is a hosted service, as the owner, you would be able to see the data, regardless of the settings.  This would also be true of anyone whose roles included the 'View all' and 'Edit with full control' privileges - they are essentially administrators for data.

Esri Esteemed Contributor

Hi Pankaj,

To diagnose the applyEdits error, I would need to see a log of the submission attempt.  This might be better suited to address via Esri Support.

Occasional Contributor

Everything starts from feature services and what you should have. But no one has commented or at least I have not found it as it should be the process of creating a feature class (with everything it should have) in my GDB so that it can then create a feature service. Anyone have an official document? for Arcmap or AGpro?
According to my experience I have some steps, but it is pure pragmatism (long time)
Generate a feature class with its corresponding fields
Add Global ID
Register as Versioned
Feature template
Unregister as versioned
Enable archiving
Create attachments
Finally generate the service in a federated AGServer.
To that knowledge we must add how to do if you want to have related tables or image in the survey ... bla

New Contributor III

James Tedrick wrote:

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.

In my Organisation we do a survey of farmers, where we use collector app to trace the farm boundaries, and survey123 to fill complex attributes. The scenario of creating the survey form a polygon feature class and then edit the survey using inbox option works well. I can create new surveys from new created polygon by collector app too. However the problem comes in when a user by mistake, create   a duplicate of the survey from one polygon feature, the I end up having more than one record for one single polygon feature. The result is what i show with the screenshot below, I end up with just one geometry with multiple records.  What am I missing  ? 

Occasional Contributor II

Hi There

I have an existing hosted feature service in our enterprise portal with a related table.  The related records ("attached" using a GUID field from both the feature layer and the table) are showing up fine when you look at the feature in  a popup for example, so I know that that bit is working.  However when I create a new survey in Connect using this service the repeat questions from the attached table aren't coming across.

 Am I missing something here?



New Contributor

Hello everyone, 

I am trying to use Survey123 for asset inspection.I have a feature service that I want to use for creating my inspection survey. Trying to use a feature service in Survey123 Connect I get the following error. 

Any idea?


Esri Contributor

Hi Matt, just came across your post while researching a similar issue.

A schema lock like this might occur if we have hosted feature layer views configured that are also participating in joins. This will end up locking the schema of your original hosted feature layer.

New Contributor

I have a Survey123 form built on an existing feature service of parcel data polygons.  It works great for showing me the existing data and then allowing me to add some questions for my users to fill out.  However, one of the things we need to do is set up a nested repeat for a few questions.  I know how to write the repeat and the questions in it and I can get them to show up in my form. When I hit publish I get an error message saying table not found.  Publishing works just fine if I delete the repeat section.  Should I be building a related table and sharing it to my AGOL account in the same location as the feature service to capture the responses to the repeat?  Is there something else I should be doing?

New Contributor III

Every repeat is a related table in your feature service. You need first to create the all required related table before you publish your feature service.

New Contributor


James Tedrick‌; Ismael Chivite

Thanks for this blog.

We followed this workflow exactly for one of our requirement as briefed below.

1. We have set of Parcels in our project area to do some assessment at each parcel. For this, we have an existing Point feature class (Parcel Centroid as Point) with standalone table and then created a feature service. Based on Feature Service, created a XLS Form and published with Inbox enabled to update existing parcels data based on Field Survey Assessment.

2. We have realized at some point of time that existing Points are not showing in Survey123 App through INBOX mode and even the points are not visible in feature class. But, it is fully qualified Point feature class-> connected with Feature Service -> Connected to XLS form. Not sure, which process/configuration has influenced to hide existing point. In order to collect the point, enabled required option (Required=Yes) to get the current location mandatorily. 

3. Now, the Parcel Assessment is currently in progress and Points are visible for those parcel's assessment is completed.  While doing QA/QC process,  there are rejection of parcels  because of incorrect locations. Hence, we are trying to reinject those parcels alone in separate form based on the QC Status - "Rejected" through INBOX mode.

In this step, the wrong points collected through Parcel Assessment is visible and unable to make this Geo Point question as mandatory to Re-Survey once again in place of Wrong point even if we make "Required=Yes"

Q1. Need to understand, why/how those parcels centroid points are not visible at the initial stage while accessing existing data in Survey123 through INBOX mode.

Q2. How to make this Geo Point question as mandatory to Re-Survey once again for the rejected parcels

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

Thanks for your support.



by Anonymous User
Not applicable

Hi all,

I need to publish a very complex survey form and then it will be probably necessary to update it in the future without loosing collected data.

I am aware that adding a question or updating some choices it is not an issue, and also changing question type can be accomplished with some workarounds, but adding a repeat means that feature service and all collected data will be delected if I simply update the form using Survey Connect.

Reading this post, I'm wondering if a good solution could be:

- I publish the Survey form using a managed geodatabase as data source

- When I need to add a repeat, I add a related table to the feature class and feature service

- I  publish a new Survey form using the existing feature service (that contains the already collected data and the new empty related table) 

Should it works ?




New Contributor III

This is going to be a long post, and I apologize but I want to paint the full picture of my issue.

I'm having an issue with a survey I built from a feature service that has a related table. It's a FC of all of our vehicles and equipment, for inventory and maintenance purposes. There's a related table that would store all the maintenance done on that vehicle/equipment, for easy reference to those using the equipment.  It's a two part survey where half of it would add a completed maintenance record to the related table, and the other half would show that maintenance is needed on something. It uses pulldata and cascading selects to autopopulate the location of the vehicle/equipment on a map to fulfill the 2nd half of the surveys functionality. Ideally, I want to maintain both functionalities so that I don't have to update the csv of 2 different surveys every time we get a new vehicle/get rid of a vehicle/move a vehicle to a new department (which happens easily once a month). Also along with this, I want it to be available through web format, NOT using the Survey123 app, because with many users who I don't regularly see, I don't want the users to have to update the survey every time a vehicle change occurs.

However. I'm concerned that I'm trying to do too many things in one survey, or have some things in there that are unnecessary to accomplish my goals, and that's the cause of my error message. I have no issues publishing, but I cannot submit a survey. Everything appears to function as it should, but just does not work. There is no error code, it just says "Survey contains errors", and highlights the map question. 



















I tried to take the mapping part away, thinking maybe that was the issue, but still, no luck.






Not quite sure what's going on. Any ideas? 

New Contributor III

Sorry in advance for the long post, but I want to explain the whole situation so my issues are clear.

I've created a survey using a FS that has a related table. The dataset is a point FC of all of our vehicles and some of our equipment (such as trailers, backhoes, lawn mowers, etc). The related table is to capture all of the maintenance done to each item, and make it easily accessible to the people using the equipment. Because of so many different users, I need the survey to be a web form, so that every time a vehicle moves departments, or we get a new vehicle, or get rid of an old one, all of the users won't have to go in and update the survey. History has shown that they're not good at that, so I'd really like to avoid using the app to access the survey.

This is how the survey is currently set up: The survey is set up with cascading selects to select the equipment you want to submit the survey for, and then pulldata to populate a point on the map based on the equipment selected. The survey is essentially two different surveys smashed into one. One part is "maintenance is needed", where once the equipment is selected, the user fills in information about what is wrong with the vehicle for our office manager to schedule it for maintenance. The second half of the survey is to be filled out when maintenance is already completed, and is set to populate the maintenance related table. I'd like to keep this two-in-one setup in place if possible, so that I don't have to update multiple locations every time there's a change to the inventory.

I had no issues publishing, no errors returned or anything, and when filling out the survey, everything functions as it's meant to. But when I submit it, I receive a general error.




I thought the issue might be with the map question, or the pulldata function, or the two-in-one functionality, so I pulled everything out of the survey except the questions where an item is selected, and the questions the maintenance table needs. But then I receive a different, even more general error message.



So I'm not sure what's going wrong. Any suggestions?


New Contributor II

If I change the name of the feature services and break my connection to Survey 123 (and can't change it back), how can I re-establish the connection to my survey?

Occasional Contributor

UPDATE Jul-30: I didn't have editing enabled on the feature service in AGOL (settings tab).

Hi all,

I followed the steps to create a survey from an existing feature service in S123 Connect and published the survey.

Unfortunately, the new survey will not send responses. I get an error that says "survey could not be sent due to the following error: (then it just shows the instance name) Do you want to edit this survey?"

It appears that the submission url and form ID are correct. I did add a few fields in AGOL and then in S123 Connect and republished with success.

Interestingly, when you try and edit and look at the geopoint question, the survey does not populate any of the maps that have been linked in S123 Connect.

Responses are currently backing up in the Outbox.

Any help is appreciated!