Working with existing Feature Services in Survey123 for ArcGIS

49844
126
09-25-2017 12:03 PM
Esri Frequent Contributor
31 126 49.8K

[Last updated October 11, 2019]

Typically, when you publish a new survey with Survey123 Connect or 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 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 ever 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 fundamental 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 even 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?
  • 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 people are  capturing data and you have assigned one team to each area.  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 classic example is where you want to use Survey123 to manage the complete life-cycle of an incident, where 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 Online, and if not, it must be registered in a multiuser geodatabase.
  • Multiuser geodatabase layers cannot be versioned.
  • Your layer must have an indexed GlobalID field and all relationships must leverage the GlobalID fields.

If using Portal for ArcGIS, only version 10.4 and newer are supported.

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 for ArcGIS.  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 the case of 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.

                    

Starting with version 3.0 of Survey123, you can only work against Feature Services where the supportsApplyEditsWithGlobalIDs property is set to true. See https://community.esri.com/groups/survey123/blog/2018/07/17/how-to-turn-supportsapplyeditswithgloabl... for more details.

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.

XLSForm Question types:

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

Feature layer field typeQuestion type in initial XLSForm design
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 (kind of difficult to reliably store a user entered string into a date type of field).
  • 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.

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 truly 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 relationships 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.

Survey123 only supports one level of repeat. That is, if you have two nested related tables, Survey123 will not be able to model that. Nested repeats are planned to be supported in version 3.0 (July 2018)

Nested repeats are supported starting with version 3.0              

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)

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.

Two One more note on geodabase domains: At the moment Survey123 Connect will ignore range value domains, although if you like you can model them as constraints in the XLSForm survey worksheet relatively easy.  Also, if your feature layer has subtypes and each subtype has been assigned a coded value domain, Connect will ignore the domains as well. If you really wanted to model that, you could setup cascading selects manually.

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 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  o effect on the geodatabase schema.
  • You can also 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 itslef.  In old versions of Survey123 we actually supported working directly with feature service urls, but when you let Survey123 Connect create your initial XLSForm design, the feature layer item url will always be used.  Right now, Survey123 supports feature service urls only for backwards compatibility. you should always use a url to the item!
  • form_id: This column defines the name of the layer in your feature service that your survey will hit.  By default, 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.
  • The dialog in Survey123 Connect listing all available feature services to be used as a seed for your survey will include line and polygon feature layers. Keep in mind that at the moment you cannot work against a layer with polygons and polylines, but you can work against any tables related to them.  Use the form_id setting to redirect your survey against the related table and eliminate questions outside the repeat.
  • 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 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.

[Updated on July 22, 2018]

[Updated on October 11, 2019]

126 Comments
Regular Contributor

the table describing fieldtypes do not match....typerInteger = text?

typeString = integer? 

Esri Frequent Contributor

Oh My! Totally unexpected that some would read the entire thing! Thanks so much, nice  catch.  Fixed!

Regular Contributor

By the way, any update on #BUG-000107912?

Esri Esteemed Contributor

Hi Joe,

I just looked into the status of BUG-000107912 - it is currently still going through processing.

New Contributor III

This is really cool! Just want to make sure I understand how this works though...the feature class has ALL of the fields you need in the various surveys in it already, you are just publishing various surveys that will port info in to specific parts of that existing feature class?

What we are trying to do (and I'm not sure if this is possible??) is keep several surveys separate, meaning they have separate feature services, but have them related so they know they belong to each other. In our case, we want our biologists to go out in the field and collect their rare species data using the Rare Species Obs form we already have. Then they need to come back in the office and go through the rest of their processing steps, which involves filling out a Data Acceptance form as well as a Data Processing form (these could possibly be together on one survey...not sure yet if we need/want to keep them separate). We need these two forms to know that they belong to a given rare species obs feature but we want them as completely separate surveys (NOT just pointing to fields on the rare species obs feature class) because we don't want updates/modifications to the Acceptance and Processing forms to mess with the Rare Species data collection. If we had to work on those forms, we don't want to have to keep republishing up the same feature service the bios are collecting their field data in and holding them up on their work. If all of these were somehow related to each other it would be really convenient.

Any thoughts or tips on this would be so helpful. We have a complex data processing system here (field data needs to come in and move through processing and qc steps, then parts of it need to go into Biotics, the rare species oracle spatial database that Heritage programs all use, and other parts of it need to go into biologists individual databases that they use for doing their research/analysis) and we are trying to see how much of our workflow can be helped using these tools.

New Contributor III

Unfortunately I was hoping to use Survey123 alongside Collector on my services that are;

- Versioned to support a replicated workflow.

- Using web-tier authentication...

... which of course means I can't according to this article; How To: Create Survey123 for ArcGIS surveys that connect to non-federated ArcGIS Server services  

Any chance Survey123 might be updated to support these two things? 

Esri Esteemed Contributor

Hi Cameron,

Survey123 does not support versioned feature services; we make use of the "Apply Edits with GlobalIDs" capability of Feature Services, which does not allow for data to be versioned; see ArcGIS REST API for information, search for supportsApplyEditsWithGlobalIds to get to the relevant information)

The document you cite above is for working with standalone ArcGIS Server services and is a workaround in the case you do not have a Portal; a federated service with web tier authentication (meaning that the Portal would also have web tier authentication) is supported.

Esri Esteemed Contributor

Hi Tara,

I believe that Survey123 can support the workflow you are describing.  The key part in linking the surveys together would occur in the table authoring stage - as part of the design, you would need to have a key field that uniquely identifies the observation in each table and then relationship classes using that key field would need to be created.  The value would be created by the observation form, and then it would need to be also entered in the follow up forms.  Benefits of relationship classes—Help | ArcGIS Desktop is a good place to start with relationship classes if you're not familiar with them.

New Contributor III

Hi James,

Thanks for the response.

We're still stuck working with standalone ArcGIS Server services for much of our work due to the named user restrictions with Portal and federated services (not practical to have hundreds or thousands of internal users under the current licensing options). This works fine with Collector, but not with Survey123, as identified.


Hopefully I can figure out a work-around once we can get Portal up and running... unfortunately our update/install/upgrade process is painfully slow at this point...

New Contributor III

I'm in the same boat - our organisation is very slow to get portal up and running, so have to use secure services. alas thanks to security restrictions I can't store credentials with a service, which means I cant use survey123

New Contributor III

Is it possible yet to use a pull data function from an existing feature service? We have thousands of accounts in our CRM that we would like to use in Survey123, and we use a static .csv pull data function to bring in account information. Would like to be able to sync with a feature service so that new accounts and account changes would pull into the survey automatically like they do with our maps

New Contributor II

Is is possible to pull in images that are attached to the feature service so they can be annotated in Survey123? We use Collector to launch Survey123 from a custom attribute popup. Ideally, we would like to select a parcel in Collector, which opens Survey123 from the popup, then within Survey123 the user would be able to markup the unique parcel record card that is attached to that selected feature.

Esri Frequent Contributor

Hi. The Survey123 Inbox does not support images at this point so it is not possible to annotate photos that already exist in your feature service.

Esri Frequent Contributor

Pulldata at the moment only works against local CSV files although we would like to extend it to work with feature services too. Still in the backlog.

New Contributor III

I got this working! Thanks you very much!!

I would now like to make some changes to the survey. This process works with a feature layer in AGOL using a submission URL, but I cant get it to work on my feature services:

- followed the steps above to connect feature service in AGOL

- connected to the service and published a survey

- added some fields in the survey to do calculations that I do not want in my feature service schema

- republished the survey

with a feature layer this works: the extra fields aren't added, but can still do calculations and feed other fields

When I do this with my feature service I get this error:

any ideas?

Esri Esteemed Contributor

James,

You will need to set the 'bind::Esri:esriFieldType' column of your added questions to the value of 'null' - this was introduced with version 2.4

New Contributor

Hi

Thanks for this great blog, it's very helpful!

I'm trying to create new survey from existing (hosted) feature service that has attachments, but the translated excel file missing the attachment (image) question.

am I missing something?

Esri Esteemed Contributor

Hi,

Our apologies, the documentation misstates what occurs.  You will need to manually add the image question(s).  The blog post has been revised to reflect this.

New Contributor III

My organization requires a configuration where we're able to change the 'status' attribute of a feature via survey but also record the remaining survey answers in a separate table for historic archiving. We're currently doing both tasks separately, one through a webapp and the other through survey123. 

Is there a way to update a field within a feature service but also record a submitted form in a related table? 

Esri Esteemed Contributor

Hi Mario,

Yes, this can be done by creating a survey based on a feature service with both the feature and related table in it and then enabling the Inbox to enable data revision capabilities.  Please refer to Use Survey123 with existing feature services—Survey123 for ArcGIS | ArcGIS  and Prepare for editing existing survey data—Survey123 for ArcGIS | ArcGIS 

Regular Contributor

Is it possible to make the form run calculations when the form opens rather than requiring manual interaction? I want to prepopulate new fields based on field values I'm pulling down from an existing survey.

I'm following the pattern described in the post of one feature service and many surveys. The first survey populates up to 10 questions. The second survey includes some fields from the first survey for context and then about 10 new questions. 

In the second survey I'm pulling down an integer value into a note field. In a new note field I want to calculate a new value automatically based on that value as soon as the form opens. It doesn't work. However, if I turn that note field into a text field and press enter then the new field will populate.

A side effect of this is that the original value can be changed once it is submitted via the second survey. As a work around I created a hidden field in the first survey that stores the original value.

Esri Contributor

Hi Ismael,

Thanks for a very informative article.

I have a question about the attachment relationships. I have existing feature service in AGOL with attachment enabled for some layers. I started a new survey using Survey123 Connect and point to existing feature service in AGOL and the form is created using layer 0 fields which is fine. This layer does have attachments enabled. But I cannot see any image type added to the form. So I tried to add them manually by adding "begin repeat", "image" and "end repeat" rows. However, I cannot publish this survey, it keeps complaining that "attachments" table not found. "attachments" is what I used for the "name" of the "begin repeat" type. It seems that at publish time, Survey123 Connect looks for a table called "attachments". However, from AGOL, it is not possible to know the name of the table used for attachments. How do I go about creating attachments in repeat?

Thanks,

Vish

Esri Frequent Contributor

Hi Vish, I responded to your email, and just for completeness here is the same reply:

It appears you are trying to add the image question in a repeat (related table) that does not exist. If Layer 0 is the layer/table you want the survey built from and has attachments enabled, and it is the table you want the attachments added to (ie not another related table), then all you need to do is add in an image question to the main part of the survey. You do not need to add a begin repeat and end repeat section, as that would imply there is a related table to Layer 0 that you are trying to attach the images to.

Regards,

Phil.

New Contributor III

Is it possible to not necessarily build a survey on top of a feature service but to change a value of a feature service. For survey tracking purpose we'd like to be able to change a field called "surveyed? (y/n)" so we can visually track progress on a map?

Thanks,

Kevin

Esri Regular Contributor

Hi Kevin,

If you are looking to change the (y/n) value of an existing feature service record using the Survey123 field app, it will require that you create the survey from the service and enable the 'Inbox'.  Is the idea that the value would be changed by the field collector on location?  

Brandon

New Contributor III

That's correct Brandon. It wil be done by the collector on the field. So if I understand it correctly I can create a survey from a service, just leave the "status" question to be able to change my y/n status and then add other question not related to my feature service?

Esri Esteemed Contributor

Hi Mike,

The calculation not occurring in a note question is a known issue.  This is specific to questions with null field types, which notes have by default.  In 2.5, you will be able to use a read-only field for the same effect.

New Contributor III

Hi,

Following Phil's suggestion to Vish's re the repeats on images.

If I understand this correctly, that is by simply adding type question image will allow for capturing image(s) on Layer 0 (which has attachment enabled). My question is, will this allow for capturing multiple images/photos per feature on Layer 0?

In the normal way of creating forms using Advanced XLS, I would use the begin repeats/end repeats to allow for capturing multiple photos. But you are saying that using "begin/end repeats" on existing feature services points to related table.

On another issue, I need to add more questions that does not yet have existing fields in the feature layer to the form. I do not have problem adding to the form on Connect, however, I am unable to republish the modified form as it gave me error:

"The custom feature service submission url is not compatible with this survey (Field AAA not found in HostedFeatureLayer)"

When creating the form from scratch, I have no problem republishing the survey as I add more new fields to the form. Is this a limitation when creating survey from feature service? How can I easily add more new fields to the form?

Thank you

SW

New Contributor III

Hi Mike and all,

Just to clarify, did you prepopulate the answers to some of your questions on a form created from feature services?

I am trying to work out how to prepopulate the fields to some of the questions. I would normally use the Pulldata functions, however somewhere earlier in this blog says that pulldata function cannot be used on feature layer (?).

If that is the case, is there any other way to prepopulate my questions other than having a duplicate data in a local CSV with pulldata function?

Thank you

SW

New Contributor II

Great article!

I was wondering though, how would you open up an existing feature in your survey?

For instance, we're wanting to have two forms linked to the same database where first a field worker goes out and collects some information and then later their supervisor (on a different device) goes out and signs off on it.

So far, we've only been able to set it up so that the field worker can edit their outbox, but we're creating an entirely new feature that is just being fed the values that the field worker collected.

New Contributor III

Hi Saven,

I've recently asked similar question. Have a look at the response in the blog

Cheers

SW

New Contributor II

Thank you, this is exactly what I was looking for!

Esri Frequent Contributor

Hi Siew,

Not sure if anyone answered this yet or if you have worked it out, if you want to add fields to an existing feature service you should add them to the feature service first (via AGOL or Portal or use Pro) and then update the same field names into your xls form in Connect.

In the latest release 2.5 we now allow adding fields to feature services published by Connect, some add actions are not supported which you can find in documentation.

Phil.

Regular Contributor

"...did you prepopulate the answers to some of your questions on a form created from feature services?" - yes.

I was playing around with a Workforce project. I added additional fields to the assignments feature service. I used one survey123 form to populate and create an assignment in WF and then a different survey123 form would pull that record down to complete the assignment.

The issue I'm having is that the assignment type is an integer tied to a domain. In Survey123 when I pull that record into the form that integer has no meaning for users. I wanted the form to automatically calculate the actual value in a separate field based on a IIF statement (e.g. if field=1, use description 1, if field=2, use description 2, etc). However, it doesn't matter if the field with the calculate is a note or a read only text field. It still won't calculate automatically. It requires the user to click in a text field to run the calculation.

New Contributor II

Hello All

I'm hoping someone can help clear up a few questions for me.  I have a feature service with attachments and related tables published through desktop to ArcServer, and registered with Portal.  The related table questions are shown as a repeat in my survey.  I have the form_id and submission URL matching, but when I attempt to publish, I receive an error that fields from the related table are not found in the form_id, therefore the URL is incompatible.  My question is, is this part of a limitation of having repeats in an existing service?  Can you not have 2 "sources" of questions?

I have archiving turned on, and using global ID and GUID properly.  If I create the exact same survey and use Survey Connect to create the hosted service, I have no issues. 

Thanks for your help!

Occasional Contributor

Hello,

I am struggling with understanding how repeats work that use Global IDs and GUIDs. As mentioned above, "reserved fields in your feature layer will not be added to your XLSForm: ObjectID, GlobalID and Editor Tracking Fields will be ignored." Also, you mention that Survey123 only lets you work with repeats when the underlying feature service has relationships that comply with the following:

  • Both the parent and child tables must have an indexed esriFieldTypeGlobalID field
  • The child table must use an indexed foreign key of type esriFieldTypeGUID against the GlobalID or GUID field in the parent table

So if Global IDs are reserved fields and are not added to the XLSForm, but also needed for repeats, how does the related data work and look in the XLSForm?

I am creating a Bridge Inspection application that will use both Collector and Survey123. I am generating the survey123 form from a feature service that I created from my ArcGIS database design. The service has Inspections with related Bridge Elements. In my database I built in ArcGIS, I added Global IDs to my Bridge Inspection feature class and Element table. I also added a GUID to the Element table. The relationship class between Inspections and Elements is built upon the Inspection Global ID and the Element GUID. How does the repeat work if the Global ID and GUID are not stored in the XLSForm?

As part of my application I also want to pass the Global ID from my Bridge layer to the Bridge GUID in the Inspection data within the Survey123 form. I was hoping to do this from Collector. But there is no Inspection GUID question in the XLSForm since it is not imported.

Any clarification will help.

Thank you,

Kevin

Occasional Contributor

I have the same issue with a feature service that i was adding some related tables to.  I added in the nulls to the 'bind::Esri:esriFieldType' but it still says The custom feature service submission url is not compatible with this survey (Request error).

Any help would be aprreciated!

Thanks,

Occasional Contributor

I actually had the wrong submission url but when I fixed that i got this message even though I used null for the additional fields.  Maybe it was because it was a repeat?

Esri Frequent Contributor

Hi Tim,

Can you please attach a copy of your survey xlsx form so I can take a look at parameters used.

Regards,

Phil.

Occasional Contributor

?Hi Phil,

Thanks for getting back to me. As I was searching I finally found what I needed. All I had to do was configure the attributes in the Pop-up to 8 decimals and it worked! I will have to update my post.

Thanks,

LTK

Esri Frequent Contributor

The blog post has just been updated with more information in the red note around the decimal formatting of pop-ups.

Phil.

Occasional Contributor II

Thanks for posting this, it has been of enormous help and a great resource!

I have a question regarding promoting through Dev to Production.  I have built the form by consuming the Dev Feature Service, and just wondering what it the best process to repoint/swap it over to the Production Service?

Cheers

New Contributor

KB link is broken

https://community.esri.com/external-link.jspa?url=http%3A%2F%2Fsupport.esri.com%2Fen%2Ftechnical-art... 

how to to use a service from an ArcGIS Server instance that is not federated with Portal for ArcGIS?

Esri Esteemed Contributor
by
New Contributor II

Thank you Mike,

I am also having the same issue with the domain. Maybe the domain values will be carry across to Survey123 sometime soon.

SW

Occasional Contributor II

Hi There,

ichivite-esristaff‌ and JTedrick-esristaff‌ I was wondering, If I were to Add an Image (capture Photo) using S123 based on Crowdsourced StoryMap Feature Service, would this save the image to the same location as in the StoryMap?

Also If i were to add additional fields and formatting would this cause the StoryMap to stop functioning correctly?

Cheers

Andrew

Esri Esteemed Contributor

Hi Andrew,

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

New Contributor

Is it possible to start in Collector with a map of a hosted feature layer click on a particular asset (ie storm inlet) have it pull up Survey 123 app and be able to show and edit fields of that particular inlet that you selected. And also create a Inspection of that particular inlet that is a related table to the hosted feature layer.

I have successfully done part 2, where I can select an inlet in Collector and be able to complete an inspection in Survey123 and the record shows up in the related table. I would like to be able to change one field in the parent layer (Inlet) to show it's status to say that the inspection has been completed. And I would like to be able to do it in the same survey form. Is that possible??

Occasional Contributor II

Hi James Tedrick

Thanks for this, so i have figured out that in the Editor View of the StoryMap it will display the points but the thumbnails does not come through as Survey123 doesnt create a thumbnail. So my next question would be is it possible to replicate the photo in to another photo field and call it PrimaryThumbnail.jpg just like StoryMap. This would allow me to then at least display the information in the Editor View of the StoryMap

Cheers

New Contributor II

From How To: Create Survey123 for ArcGIS surveys that connect to non-federated ArcGIS Server services , what is the purpose of this restriction: 

  • The server must not use web-tier authentication (for example, it cannot use IWA or PKI authentication).

Since we're unable to federate our existing servers with PTL, and we're required to use WEB TIER authentication, this essentially prohibits us from use 123.