Survey123 Tricks of the Trade: Repeats

[IsmaelChivite]

You can think of XLSForm repeats like sub-forms: A form within a form that can also be completed multiple times. Repeats are a very powerful feature in Survey123 because they can be configured in many different ways to support different business workflows. This article covers everything from the basics to the more advanced features of repeats. 

Some use cases

Let's first review some common scenarios that scream for a repeat:

• In a door-to-door population survey, you will want to capture the location of the household and address, but also information about every member of the family. A repeat will help you model the form to be completed for each of the members of the household, including information about their name, age, gender, etc. The household survey will have a household member repeat in it, which will be completed for each person in the household.
• In an asset inspection form you may want to capture information about each defect found. The defects repeat (or sub-form) will include questions to let you document each defect with its own photo, a description of what needs to be repaired and estimated cost of repair.
• Repeats are also a great way to handle routine inspections. An asset form can include a repeat for the inspections: one form for the asset with its ID, location, etc and a sub-form (repeat) for every inspection ever made, with its date, issues found, etc. Since repeats can be nested, the inspection repeat form can also include its own repeat or sub-form for every defect found.

The basics

Repeats are supported through XLSForms via Survey123 Connect. If you are familiar with XLSForm groups, you have a lot of ground covered, because a repeat is really a type of group that lets you cycle through the questions in the group again and again.

To add a repeat to an XLSForm you need to enclose a set of questions within a begin repeat and end repeat set, as shown in this example:

type	name	label
text	hh_id	Household ID
text	hh_address	Address
begin repeat	hh_members	Household Members
text	mbr_name	Name and last name
integer	mbr_age	Age
select_one gender	mbr_gender	Gender
end repeat
select_one yes_no	all_members_present	All household members present?

In the survey above, the main body of the form is really about the household itself and is used to collect the household ID and address. The repeat block is all about household member information. We expect the enumerator to complete the Household Members repeat, or sub-form, once for each person in the household. The All household members present? question is outside the repeat, so it also belongs to the main form, but it will be presented right after the Household Members repeat.

Below is what the survey above would look like in the Connect preview. Note that the repeat appears as a common question group, except that at the bottom there are multiple options to navigate records within the repeat: a plus button to add a new record as well as next and back buttons (once you have more than one household member).

The user experience for repeats within the Survey123 web app is slightly different, presenting all the repeat records at once. You can navigate through them by scrolling up and down, as shown in the next animation.

You can add one or more repeats to your survey. For example, in a school survey, you could include a repeat to document all classes in the school, and a separate repeat to gather information about teachers, etc. 

Understanding repeat data in your feature layer

Survey123 repeats are modeled in ArcGIS as related tables (or related layers if your repeat includes a geopoint, geoshape or geotrace question). In the example household survey above, the information about the household (id, address...) is kept in the main layer of a feature service, and the data from the household member repeat (name, age, gender) is modeled as a separate, but related table. The relationship between the tables/layers is kept through internally created global IDs.

If you would like to preview what your geodatabase schema looks like you can use the Schema Preview option in Connect, as shown in the animation below. Note that the name of the repeat in XLSForm becomes the name of the related table.

Using the Survey123 website, you can quickly explore data from repeats using the Data tab. The table will show records from the main layer of your survey as usual, and also extra tabs for every repeat in your form. You can propagate selections across the tabs for easier exploration of your data.

Repeat appearances (minimal and compact)

Through the appearance column in the XLSForm you can control how the repeat initially loads and appears in your form. By default, a repeat with no appearance value set is shown expanded, with one initial record showing. This can be good or bad. The good is that all questions within the repeat are ready for end-users to enter data right away. The bad is that if no data is entered, a new empty record will be added to your related table. I generally avoid using repeats with no appearance unless questions within the repeat are flagged as required.

If you want to avoid the repeat from having an initial record preloaded, use the minimal appearance. This will show your repeat group expanded, but with no records. To initialize data entry in the repeat, the end user will need to explicitly add a new record to the repeat by clicking the plus button.

The compact appearance simply collapses your repeat when the form initially loads. Of course, you can combine the minimal and compact appearances.

XLSForm expressions and repeats

XLSForm expressions allow you to bring sophisticated logic into your forms. Generally, XLSForm expressions are used to auto-calculate values (Calculations), define skip logic (Relevant), and to build data validation rules (Constraints). The XLSForm expression syntax for calculations in repeats is basically the same as with any other question in the form (more details at Formulas—Survey123 for ArcGIS | Documentation), but here are some important things to highlight.

When writing XLSForm expressions for a question within a repeat, you can reference other questions inside the repeat, but also questions outside! A common use is that where you want to bring data into your related table from the parent record. For example, in the example household survey you may want to store, along with every household member, their corresponding household ID. It would look something like this:

type	name	label	calculation
text	hh_id	Household ID
text	hh_address	Address
begin repeat	hh_members	Household Members
hidden	parent_hh_id	Parent Household ID	${hh_id}
text	mbr_name	Name and last name
integer	mbr_age	Age
select_one gender	mbr_gender	Gender
end repeat
select_one yes_no	all_members_present	All household members present?

Note how the parent_hh_id question within the repeat is calculated to automatically fetch the value of the Household ID for that person. The Household ID is outside the repeat, but the calculation brings that value into the repeat record. This is a common use of calculations within repeats because it helps bringing more information into the repeat table that would otherwise require a join.

Styling

There are a few techniques you can use to style your repeat with custom colors and labels. This can be help users navigate your form more efficiently.

One technique is to dynamically set the label of your repeat to provide some context as to what information should be entered into the repeat. For example, in our household survey, you can include the address of the household in the header of the repeat. Instead of just reading 'Household Members', you can make it read 'Household Members at: <Address of the household comes here>. This is what is known as a dynamic label and it is described in more detail in the https://community.esri.com/groups/survey123/blog/2018/11/01/understanding-dynamic-labels-in-survey12... blog post.  This is quite handy when working with long surveys, because it brings additional context for the person filling out the form. Here is what this would look like. Note how the label for the repeat is dynamically generated using a value from a question outside the repeat.

type	name	label
...
text	hh_address	Address
begin repeat	hh_members	Household Members at ${hh_address}
...

You can also use colors to make your repeats stand out better within the form, like in the following screenshot. The repeat block uses a darker background color than the rest of the form, clearly separating questions within the repeat, from those outside.

The background and border colors of your repeat can be controlled through the body::esri:style column. In the example above, the vale in this column for the begin_repeat question is: backgroundColor='#cbcddb' borderColor='#494a4f'.  The color is expressed in hexadecimal format or HTML color name.  You will generally not want to use bright colors for you repeat backgrounds. Try to be subtle using slight variations of the background color of your form.

The body::esri:style color parameters are only honored by the Survey field app.

Aggregation functions (max,min, count and sum)

XLSForms support a handful of functions specially built to work with repeats. Specifically: count, sum, min, and max. They are all pretty self-explanatory. The design below shows the max and count functions in action.

type name label calculation bind::esri:fieldType

type	name	label	calculation	bind::esri:fieldType
text	hh_id	Household ID
text	hh_address	Address
begin repeat	hh_members	Household Members
text	mbr_name	Name and last name
integer	mbr_age	Age
end repeat
hidden	max_age	Age of oldest person	max(${mbr_age})	esriFieldTypeInteger
hidden	total_count	Total persons in house	count(${mbr_name})	esriFieldTypeInteger

The count function can get a bit tricky as it will only consider in the count records with a value in the question it references. For this reason, it is best to use the count function against a question within the repeat that is flagged as required.

The sum question is also an interesting one in that it can sum not only numbers, but also text and even geopoint questions as well. If you sum text, it will concatenate all responses to your question within the repeat. If you sum on a geopoint question within the repeat, it will generate a geotrace object.

Check the Repeat Aggregation Survey123 Connect survey sample for an example using aggregation functions.

Note: When used in the Survey123 field app, count() and max() can be placed inside or outside of the repeat. If the function is to be used in the Survey123 web app it must be placed outside of the repeat. Optionally, its value can be referenced in a calculation inside the repeat.

Aggregation functions (join)

There is one more aggregate function that may be of interest: join. The join function is used to create a single list including all responses to a particular question within the repeat. Its syntax looks as follows:

join (",",${questioname})

The first parameter defines a separator. You can use a comma ",", a hyphen "-", or other character. The second parameter is the question within your repeat from which you want to create the list.

In our household survey example, we could use join to display a list of all people interviewed so far.

type	name	label	calculation
text	hh_id	Household ID
text	hh_address	Address
begin repeat	hh_members	Household Members: ${interviews}
text	mbr_name	Name and last name
integer	mbr_age	Age
end repeat
hidden	interviews	Every person interviewed	join(",",${mbr_name})

Note that the hidden question at the end uses the join function in the calculation column. Then the label in the begin repeat takes that value and displays it dynamically. You can see the effect in the next animation:

We can take join a bit further. Let's pretend we need to design a manhole inspection form. We want all six parts of the manhole to be inspected: the cover, chimney, cone, wall, bench and channel. We will use a repeat to document the inspection results of every component, and the join function to help us make sure all components have been inspected. Let's first have a look at what the form's behavior looks like:

Note that a checklist at the bottom of the form keeps track of the components inspected so far. When a new component is selected for inspection within the repeat, the value of the checklist is recalculated accordingly. This checklist at the bottom is set as read-only, so the user cannot manipulate it. A constraint in the checklist is also in place to avoid users from submitting the form unless all components are checked.

A simplified version of the XLSForm, highlighting the use of the join function is shown below:

type	name	label	calculation
text	manhole_id	Manhole ID
begin repeat	components_group	Components
select_one components	component	Component
select_one conditions	condition	Condition
end repeat
select_multiple components	comps_inspected	Components Inspected	join(",",${component})

To complete the XLSForm to mimic the behavior shown in the animation, you would also need to:

• Set the comps_inspected question as read-only, to avoid users from manipulating the checklist manually.
• Set the constraint of the comps_inspected question to count-selected(${components_tested})=6.

Repeat Count

If you want to control how many records must exist within a repeat, use the repeat_count XLSForm column. If you set the value to 2, then your repeat will be initialized with 2 empty records. If you set it to 5, it will contain 5, etc. You can also set the repeat_count dynamically as shown in the example below.

type	name	label	required	repeat_count
text	hh_id	Household ID
text	hh_address	Address
integer	hh_total	How many people live in this house?
begin repeat	hh_members	Household Members		${hh_total}
text	mbr_name	Name and last name	yes
integer	mbr_age	Age	yes
end repeat

The repeat_count column simply defines how many records are shown in the repeat. All records will be empty until the end user goes through every record to add data. Unless you have required questions within the repeat, Survey123 will allow you to submit records from the repeat with no data, and they will show as what they are: empty records. Generally speaking, you do not want to use repeat_count, unless you want to force people to submit a specific number of records in the repeat. If that is the case, you will want to add required fields within the repeat group. In the household example above, we first ask, "How many people live in this house?" We use that number to define the exact number of records in the household roster that must be completed. By making the questions within the repeat required, we guarantee that data is entered for every person in the house.

In cases where you want users to submit a number of records within a range, you will not want to use repeat_count. Instead, you will want to use constraints and the count function. For example, in an electric panel survey, you include a repeat to document all circuit breakers. Say that the number of circuit breakers is always between 5 and 20. This is what you would want to do:

type name label constraint calculation

type	name	label	constraint	calculation
text	cc_id	Circuit Panel ID
begin repeat	breakers	Circuit Breakers
select_one type	breaker_type	Type
select_one status	breaker_status	Status
end repeat
integer	total	Total Breakers	${total}> 4 and ${total}<21	count(${breaker_type})

As described above, for the count function to work effectively, you will want to make the breaker_type question required.

Nested repeats

A nested repeat is a repeat within a repeat. For example, say you are doing a survey of a campground in a National Park. You want a survey for the campground itself (the name, the location of the entrance, etc). Within each campground you have campsites, so that gives you one repeat (location of the campsite, photo, size, etc). Then for each campsite you have equipment, which gives the second repeat (equipment type, condition, etc).

You can nest as many repeats as you want. That is, you can nest 3, 4 even 5 repeats if you like. Technically you could nest even more but for the sanity of your users avoid it whenever possible. 

Note: Nested repeats are not supported in the Survey123 web app when you update a record. You can use nested repeats to collect new records, but not to update them. The Survey123 field app supports nested repeats for new and updating records.

Repeats in the Inbox

The Inbox is a powerful feature in the Survey123 field app, allowing you to edit existing GIS records in a feature layer. If you are not familiar with the Inbox, I strongly suggest you watch this short video tutorial.

By default, when GIS features are loaded into the Inbox, the repeat records will be empty. That is, the Survey123 field app does not fetch data from related records unless told otherwise. When updating an existing record from the Inbox in this way, you will be able to add new repeat records, but not view or update existing ones from the feature layer.

If you want to look at or update existing related records, you need to specify in your XLSForm what you want to download into the app, and for what purpose. This is all done through the bind::esri:parameters XLSForm column.

For example, let's pretend you are creating an asset inspection form and you want the complete history of inspections to be available in read-only mode. Then you would go with something like this:

type	name	label	bind::esri:parameters	calculation
text	panel_id	Electric Panel ID
geopoint	location	Location
begin repeat	circuits	Circuit Breakers	query
datetime	insp_date	Inspection date
select_one status	status	Status
end repeat
integer	total	Total Breakers		count(${breaker_type}

The query value in bind::esri:parameters will force the Survey123 app to download every related record, so all your inspections will show in the repeat of the asset form. The values supported in this column include:

• query: Used to fetch related records and populate repeats. If query is not used, surveys from the Inbox will not display any repeat information from the existing feature. You can also control which records should be fetched, by defining a where statement for your query. For example: query="status='needs_repair'" will populate the repeat with all related records where the status is set to needs_repair. If no where statement is passed, the query parameter will fetch all related records.
• allowUpdates: This parameter controls if the existing data in the repeat can be updated by the end user of the Survey123 field app or not. This is extremely useful because often you want end users to have read-only access to historical data (for example previous inspections of an asset) in the repeat, while allowing entering a new inspection to the repeat. allowUpdates by default is always false, but you can turn it on: allowUpdates=true.
• allowAdds: By default this parameter is always true, allowing the end user to enter new records in the repeat. You can turn it off by passing allowAdds=false.

In the example below, our electric panel survey will display all existing circuit breakers ever recorded for that asset. It will also allow the end user to modify information from those previously recorded breakers because allowUpdates is set to true. The only exception will be the installation_date, which will be shown in the repeat as read-only.

type name label bind::esri:parameters calculation readonly

type	name	label	bind::esri:parameters		readonly
text	panel_id	Electric Panel ID
geopoint	location	Location
begin repeat	breakers	Breakers	query allowUpdates=true
datetime	ins_date	Installation date			yes
datetime	insp_date	Inspection date
select_one status	status	Status
end repeat

[David0044]

Great article, but it doesn't quite address my use case.  I have a Survey for fire hydrant inspections.  It utilizes Inbox for crews to choose the hydrant (outside the repeat) they're evaluating. 

The Survey has a repeat for the actual inspection data.  Occasionally, inspecting requires a second hydrant to be opened and flowed.  Is there any way of utilizing Inbox for the crews to choose the second hydrant (inside the repeat), similar to the original hydrant?  They won't change any hydrant info, I just want it to validate that they've chosen a real, legit hydrant from the feature service.

[DeonLengton]

Does Survey123 still honor the "minimal compact" appearance to stop it from creating a blank record?

I have a survey with that exact setup but Survey123 still creates a blank record:

The Progress for Week repeat is inside the Financial Year repeat. But its appearance is minimal compact.

Even without clicking on the + for Progress for Week a record still gets created in the database:

[DougBrowning]

@DeonLengton 

This has been an issue for awhile now.

https://community.esri.com/t5/arcgis-survey123-questions/related-table-creating-blank-rows-despite-m...

https://community.esri.com/t5/arcgis-survey123-questions/repeat-always-creating-record/m-p/774312

https://community.esri.com/t5/arcgis-survey123-questions/repeat-count-is-overruling-relevant/m-p/100... 

This may help

https://community.esri.com/t5/arcgis-survey123-questions/groups-in-a-repeat-stay-expanded-if-last-re...

I also had logged a bug that when inside a nested repeat minimal does not work but I cannot find the post.

I am getting lots of blank records in my current project.

[erica_poisson]

@DeonLengton  

I have a few surveys where this is also an issue. I use a scheduled Python script to handle deleting these empty records each night, and that works well enough. It would be nice if a Minimal Compact appearance did work as you've described though. 

[Czapiga_Jason]

I have a problem where when a user wants to edit an existing record from their inbox, the repeat displays as if they did not enter anything.  I understand why it is doing that and it's a result of some calculations I have set up, but I don't know how to make it work properly.

The user has the choice of entering a individual report or quarterly report.  If the user chooses individual, a select multiple is displayed with a hidden field for each value in the list.  If the user chooses quarterly, an integer field is displayed for each value in the select multiple list.  The integer field is what is stored in the feature service.  If the user chose individual report, for each check box they select in the select multiple, it calculates a 1 in the integer field.  If the user chose quarterly, the integer they submit for each choice gets stored. I based this method on this post:  https://community.esri.com/t5/arcgis-survey123-blog/understanding-multiple-choice-questions-in-surve...

Back to my problem.  If I enter:  query allowUpdates=true in the bind::esri:parameters of the begin repeat row.  When a user opens an existing record from their inbox to edit, it loads the repeat records, but the select multiple shows blank because when they originally entered it, those checks were recorded as 1 in the integer field and it doesn't know that the select multiple was checked when the feature service is queried for the repeats.

When loading a record with repeats from the inbox for editing, how can I tell the repeat query to check those boxes in the select multiple if it was an "individual" report and the integer field >0?

[Marianadc]

Thank you for the post!

Is it possible to limit the records that will appear using a join function? The repeat I'm building is going to get to many records so I was trying to find a way not to show all the records from a specific question. It would be great just to show the latest five records or so.

Alternatively, is there any way to show the latest record from a question (string) as a note on the repeat? This would be a way for the user to have a quick knowledge of the last record he/she made when filling out the next record.

Thank you in advanced,

Mariana

[LinzMess]

I have a question similar to the issue @MelanieWilliams1 posted last year which may have been resolved  offline. I have a survey embedded in a dashboard (so a web form). All the questions in this survey are wrapped in a repeat and write to the same feature layer as another survey that users interact with via the FieldApp. The idea is that users submit an observation via the field app, then other users can view and comment on observations via a dashboard. My question is, how can I restrict users of the web form to only submit new records? Currently in my dashboard, all records in the repeat are displayed and editable. To add a new record, users must scroll to the bottom of the survey to fill out a new repeat. I do not want users to be able to edit or delete comments from others, only add new comments. Due to the nature of the survey and dashboard, everything is public, so I cannot restrict users to editing only their own records.

How survey appears when no comment records are associated with an observation and how I would like it to appear for all observations (even when existing repeats exist for a record):

How the survey appears when a record contains a repeat:

I can provide the dashboard link via e-mail if it would help to explore what I am working on.

Thanks!

Lindsey

[MichaelBruening]

Do you have the "repeats" query parameter set to query records back? Maybe you can set that to not query records back, but still allowAdds?

Just a quick thought.

[LinzMess]

Michael-

I did consider some of the query logic when researching my issue, but my understanding of that (admittedly limited) is that it is more intended to work with the field app inbox and works on filtering the feature layer. Since I have 2 survey forms writing to the same feature layer, one recording observations via the field app and a secondary survey allowing users to comment on already submitted observations via a web form, I would think by using the query function you would disable users from commenting on previously submitted features? I am not sure how you would use the query function to disable editing previously submitted repeats in the secondary survey without completely disabling the commenting all together.

Thanks for the idea and I might continue to experiment with how this might work.

Lindsey

[MichaelBruening]

I was thinking about when you create a form within Survey123 Connect that would be used to edit existing data, there is a way to "query" back records. I have not used the webform as much as I should, so I was unsure if you could set the "query" parameter within connect and have it honored within the web version of the form that is embedded?

I have a few that are setup within an Operations Dashboard, but the records are filtered based on a "list" that allows the viewer to choose a particular record and then the form will query back that record for editing.

I also wonder if you could have the embedded form that you are using have the questions/comments that you do want to be edited just set to "read-only"?

I am thinking off the top of my head about this. If I have a chance, then I will attempt to see if any of these will work. 

[DougBrowning]

What about making the comments a separate form that is related vs being a repeat?  The data will actually look the same but would be easier to manage.  Then set the setting to allow only adds.  Opening an existing record all the time gets dangerous.

Just an idea.  

[MichaelBruening]

After re-reading your post a few times. If I understand your situation correctly, then I might try this approach.

I would have two fields for comments.

I would have one field for field worker comments then

I would have one field for reviewer comments.

Within the field app I would make the reviewer comments fields hidden.

Within the dashboard with the embedded form I would make the "field worker" comments read only.

Then have directions for the reviewers to use the reviewer comment fields.

I just tested this out within the dashboard that I have set up in a similar manner and it works just the way it should. Field comments are frozen as read-only and the reviewer comments can be added at will.

Sometimes the K.I.S.S. (keep it stupid simple) approach works the best, as I think we're overthinking things with this.

[LinzMess]

@DougBrowning The comments is a separate form that is a related table. To be able to add multiple comments to a single observation record, I wrapped the comment survey into a repeat but it is its own form. Both the comments and observations forms write to the same feature layer. By only allowing adds via the survey123 online settings, users will not be able to use the commenting form (I did try that and had issue with my feature layer displaying geometry which ESRI staff helped me troubleshoot). And yes, my goal is to not expose the previous comments or observations to editing since both forms and my dashboard are public to allow users to interact without having an AGOL account through our organization.

[LinzMess]

@MichaelBruening I see the logic with your approach, however, I need users to be able to add more than one comment to an observation and often these users will not be the same person(s). Thus the need for wrapping the comment (secondary) survey into a repeat. I am currently using much of the workflow you have what you have described. I have a comment field for the observer to describe their observation. This field is hidden/not available in the commenting survey, so that is not my issue. My issue is how to make previous comments (maybe this term is a bit mis-leading, it is actually a comment survey with several fields) unavailable for editing. If it would be helpful, I can e-mail a link to my dashboard and my .xls survey forms for you to take a look, I would just need your contact information.

[MichaelBruening]

@LinzMess my email is mjbruening@edge-es.com if you want to email the link to the dashboard. I think if I can see the dashboard, then it might help me understand this a little bit more. 

One thing that comes to mind is something that I had figured out where you can create a note question that will hold and concatenate multiple answers and display them in a unique individual display.

I think it had to do with a geologist wanting to give his workers that were filling out the sheet the ability to see each of the sample intervals from a repeat on one page. So, I had figured out a means of using the concatenate function with some HTML coding to display each of the repeat answers within the note question. So the Note question would show the first interval with the values and then a hard return and then the next interval with some values. In your case we could just use it to show each individual response from previous submittals with a hard return or two in between each one. I am not sure if it would work, but it would be worth a shot, because you might be able to change the repeat to only allow adds and use the note question to display the previous answers?

I am unsure if this will work outside of the field app and within the web browser, but it might be worth the shot.

This might be a way to represent the previous answers without exposing them to the public for editing. If I can dig up the old coding for the note question, then I can send that to you via email or on this thread.

[DougBrowning]

"To be able to add multiple comments to a single observation record." 

If you have a repeat or just multiple forms the data would look the same.  I would have one comment = one form.  Then the security side is easy.  It seems like you have a main point, then a comment header record, then repeat records under this.  Just relate the comment forms directly to the point.

Hope that makes more sense.

[LinzMess]

@DougBrowning 

Thanks. I was thinking removing the repeat from the secondary form. As long as I can link back/record the parent record in a field, I should be able to accomplish what I need in my sahboard. I just did some preliminary testing and if I take the repeat out of the commenting survey form, I have issues publishing the form when writing it back to the original feature layer. I need a related table to contain all of the comment records (this is a one to many relationship with a single observation having potentially many comments which is why I have the repeat in the first place). To resolve this, I tried leaving the repeat in the primary survey and publishing. This does create the related table I need. Then in the secondary survey, I removed the repeat and on the settings tab of the survey form, I used the related table name as the form_id. I of course used the submission url for my original feature layer so the comment record is connected to the observation record. When publishing I get the following error message: "Fields not found in the feature service: 1" 

It appears all the fields are present in the related table when I look at the overview->data on AGOL, so I am not sure which field it is not finding in the feature service when attempting to publish. I did have to manually enable attachments on the feature layer since one of the fields in my commenting survey is a "file" question type with a multiline appearance (so more than one file can be attached).

[DougBrowning]

Are you using a repeat_count at all?  That my be it.  

When removing a repeat it does get cranky so I would publish it to a new service if you can. 

If not then make a copy of the form, publish that and see what fields are missing.

[LinzMess]

@DougBrowning @MichaelBruening 

Just an update on how I solved my issue just in case others come across a similar problem. I ended up taking the repeat out of my secondary commenting survey and making the commenting survey standalone (so it no longer writes to the same feature layer as my primary observation survey). I then embedded the standalone survey into my dashboard with the layer containing the observation data as the layer in the configurations. I then used URL parameters in the survey link to fill in information I was pulling/needed to pull from the selected observation survey record, including the global ID of the observation record. This allowed me to connect the appropriate records across feature layers. I think in the long run, this was the cleanest solution and will allow more flexibility moving forward with potential future updates to either survey.

[DustyJordan]

This is an extremely helpful article for getting more out of the repeats feature. I have a question for a potential workflow that I'm not sure this addresses however. 

I have an inspection workflow that involves entering inspection event data (date, inspector, location, etc.), then a repeat for each asset inspected that day. Within the asset repeat there is another repeat that tracks all the things discovered during the inspection of that asset. 

From what I'm understanding from this article I could use the inbox to pull the base record (inspection event data), and potentially any repeats associated with it. However, what I would actually need is to pull the asset repeat, and then allow additions of new things found during the inspection of that asset. Can this be achieved with the inbox feature? 

In other words, I need to pull the existing repeat highlighted in bold below, while allowing new data to be entered in both the base record and nested repeat. Is this possible?

Inspection Event Data (date, location, inspector, etc.)

Asset Data

Issues Detected Data

[Anonymous User]

Hi @DustyJordan,

Yes the workflow you outlined is possible with nested repeats and the Inbox. You can query and return all existing data to the Inbox, including the related repeat and nested repeat data, and then you can use parameters on each repeat to decide if you want to allow users to add new records, update existing records or do both.

Regards,

Phil.

[IanGallo]

@AllenDailey1 Did you ever find a way to do this. 

In a repeat I have question 1. Later in the survey I would like the choices of a select_one question to be the list of responses to question 1. Are we talking about the same thing?

[AllenDailey1]

@IanGallo  No, unfortunately I didn't pursue it a lot farther and didn't find a way to do it.  Yes, I think we are talking about the same thing.  If you find a way to do it, let me know!  🙂

[IanGallo]

@AllenDailey1, unfortunately it looks like it is not currently possible according to our Esri rep.

[DougBrowning]

Is question 1 a list?  If so I did have someone find a way.  It is clunky and slow on long lists but short lists it may work.  Also assumes both have the same lists.

Have a field that does a join of values from question 1

joinField with a calc of

join(",",${question1})

Then for question 2 use regex in the choice filter field

regex(${joinField}, name)

Not even positive how it works but it did work.  Hope it helps

[IanGallo]

@DougBrowning Question one is a text field, not a select_one or select_multiple, if that is what you are referring to. I'll give it a try though. 

[IanGallo]

Bit of confusion here. I want a choicelist to be created in real time as the user is entering new data into a field in a repeat. The choicelist will never be populated before the survey begins. I don't believe this is possible and if I'm reading it correctly the regex solution is only applicable to an existing choice list. A helpful tip to know though!

[SébastienLétourneau]

Hi,

I’m trying to pass a value in a repeat that comes from a previous repeat.

Ex: Previous repeat: last position calculated.

The problem is that value is the result of a calculation and I’d like to update the result in the “new” repeat with a calculation.

Ex: “New” repeat: new position calculated from the last position.

I obtain a dependency cycle error.

Is there any workaround that could break this cycle?

Thank you.

[Anonymous User]

Hi @SébastienLétourneau,

This issue and several improvements with the calculation expression engine and calculationModes have been resolved and enhancements added to the upcoming 3.14 release. This includes fixes for repeats, nested repeats, indexed-repeats etc. Also the dependency cycle error has also been improved.

You can check out the latest 3.14 beta builds on the Early Adopter Community, and test it out and provide feedback before it is released:

Expression engine improvements and calculation modes - ArcGIS Survey123 (esri.com)

Regards,

Phil.

[SébastienLétourneau]

Hi @Anonymous User,

I tried the 3.14RC2 update. Unfortunately, it doesn’t fix de dependency cycle error I have.

Here is a simplified example of what I'm trying to achieve.

As soon as I want to refer directly to a value in a previous repeat, it gives me this error.

Is there a workaround?

Thanks in advance.

[Anonymous User]

Hi @SébastienLétourneau,

What you are seeing is expected and is an error returned by pyxform, the API that converts the Excel sheet to XML. 

This error is due to referencing a question/field in the calculation of another question/field that relies on the value from itself to calculate correctly. This is now allowed. This is similar to what happens in Excel with standard calculations/formulas supported by Excel. If you point a calculation to calculate a value based on its own value.

You will need to reconfigure your calculations and form design to remove this dependency cycle.

Regards,

Phil.

[SébastienLétourneau]

Hi @Anonymous User,

I understand the problem you describe, but in my example the calculation is not referencing to itself but to a value calculated in a previous repeat.

In other words, I would like to know if there is a way to transfer a calculated value from a repeat to the next repeat, on which I could perform a calculation… and so on.

Can you help me with that?

Regards.

[DougBrowning]

Yes but the name of the field is still the same so 123 treats it the same.  The only way to bring the last repeat value over is into a different field or use JavaScript.  Search on here for the code.

[Anonymous User]

Hi @SébastienLétourneau,

As @DougBrowning points out, the field name is the same across repeats, that is how it works in XLSForm. So it looks like a circular reference as you are referencing the same field name.

Many other users have solved this issue by using position() and indexed-repeats, and updating a field outside of the repeat, and then pulling that value into the next repeat. Also with 3.14 release we have made improvements to expressions and repeats, including indexed-repeats, as well as new calculationModes that can be useful in this scenario.

Regards,

Phil.

[SébastienLétourneau]

Hi @DougBrowning,

Tanks for the info.

Since I’m not a super familiar with JS, could you refer me to some documentation that would help me get started?

[DougBrowning]

Code is here   https://community.esri.com/t5/arcgis-survey123-questions/have-a-repeat-in-survey123-default-to-last-...

[CarlosSousaFerreira]

Great article! So helpful! Thanks!

Is there a way to hide the repeat count and navigation buttons on the form?

I'm working on a form that populates different related tables, according to the event type being reported. For this I have different repeat groups that only appear when the correspondent event type is selected. I only need the repeat group questions to be answered once (I've set the repeat_count to 1), but in the form stills appears the "1 of 1" repeat count. Is there a way to hide this?

Thanks

[DougBrowning]

You can put a relevant on the begin repeat line to hide it.

[CarlosSousaFerreira]

Hello, @DougBrowning !

I'm not looking for hiding the whole repeat group, but just the repeat records count that appears at the end of the repeat group:

[DougBrowning]

Nope you cannot change the UI for repeats in 123 at all.  You can set border and background colors but that is pretty much it.

[FrederikPicavet]

Hi,

I have made a repeat question, for a picture (so making pic1, pic2, ...)

Now I want to configure a popup, but the list of attachments is empty:

The expression {photo} is not in any list .... 

What am I missing ? 

[MariaC]

Silly question, is it possible to create repeats while using the web browser version to create a survey?

[CarlosSousaFerreira]

@FrederikPicavet: I'm probably late for commenting on your question, but, when you create a repeat question, a related table is created in the data model and is that related table that will have the photos attached.

I faced the same issue and managed to show the first attached image is this manner:

1. Created an expression to get the url for the attached image with a code similar to:

var url = 'https://services.arcgis.com/<whatever>/ArcGIS/rest/services/<service_id>/FeatureServer/<photos_table_id>'
var photoid = ''
var photo_rec = First(FeatureSetByRelationshipName($feature,"<name of the relationship for the photo label>"))
if (photo_rec != Null) {
    photoid = photo_rec["objectid"]
    }
return url + '/' + photoid + '/attachments/' + photoid"

2. Then I inserted a image in the popup using the previously calculated url

[LiamHarrington-Missin]

When editing, can you have a repeat start on the latest entry rather than the first? 

Hi all,

When you are editing a survey which includes repeats and reload it from your inbox, overview or sent items, the repeat question starts at 1.  For my use case, that's inconvienient, I'd rather it load in and start on the most recent edition.  

The work around is to press the plus button, which creates the next entry and then use the delete button to get back to the latest record.  That's all well and good when you know the trick, but not ideal.

[DougBrowning]

If you long press on the arrow it will go right to the end for you.  Same with the other arrow, long press and it jumps to the beginning.  

For pages tap the Page 2 of X part and it will give you a list of pages to jump to.

Hope that helps

[DataOfficer]

Is there any change to the Nested Repeats statement below?

The Survey123 web app does not support nested repeats.

Being able to use nested repeats in the webform would be very useful.

[jzibbell_boise]

Any suggestion for how to prevent people from accidentally saving a blank repeat? I have tried the constraint string-length(.)>0 but that does nothing. I have tried to put in a relevant question that would show up if the string-length = 0 but it shows up as soon as a new repeat is added so it is sort of confusing and in the way. I am using the repeats for users to add notes to each section of the form. I'm using repeats so their notes won't be a giant block of text on the report template and can be organized with bullets. It's also a problem not to catch the blank notes in real time since deleting notes after a survey is submitted isn't possible through the app. 

[DougBrowning]

What I do is outside the repeat have a field with a calculation of count(${somefieldintherepeat})  Then set a constraint on that field.  

Hope that helps

[JoséLuisGonzálezB]

Hello everyone.

After many failed attempts: in order to edit the questions within the repetition, it worked for me to place what was suggested as follows:

allowUpdates=true query

Greetings

[RachelHackett]

I'm attempting to apply the "required components" of repeat as described in the heading "Aggregation function (join).

Here's what I got:

type	name	label	calculation	constraint	constraint_mesage
begin repeat	Plant_Group	Plant Group Species Richness
select_one plant_group or_other	m_plantGroup	Plant Group
...
end repeat
select_multiple plant_group	m_plantGroupAll	Plant Groups estimated	join(",",${m_plantGroup})	count-selected(${m_plantGroupAll})=6	All six plant groups must have species richness and percent cover values.

The thing is, each of the plant_group options don't have to be selected. I could select 6 vine groups and it is passing the form validation. Or in the case below, I made 2 vine groups and 1 of each of the other checked.

Can I somehow get it so the data is not validated unless each of the six groups are chosen?