Survey123 Tricks of the Trade: Repeats

21411
71
04-09-2020 04:42 PM
IsmaelChivite
Esri Frequent Contributor
9 71 21.4K

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:

typenamelabel
texthh_idHousehold ID
texthh_addressAddress
begin repeathh_membersHousehold Members
textmbr_nameName and last name
integermbr_ageAge
select_one gendermbr_genderGender
end repeat
select_one yes_noall_members_presentAll 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.

Repeat records in the Survey123 web app are shown all at once

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.

Survey123 Connect lets you preview the geodatabase schema of your survey

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.

Use the Survey123 website to explore related records (repeats)

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:

typenamelabelcalculation
texthh_idHousehold ID
texthh_addressAddress
begin repeathh_membersHousehold Members
hiddenparent_hh_idParent Household ID${hh_id}
textmbr_nameName and last name
integermbr_ageAge
select_one gendermbr_genderGender
end repeat
select_one yes_noall_members_presentAll 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.

typenamelabel
...
texthh_addressAddress
begin repeathh_membersHousehold 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.

typenamelabelcalculationbind::esri:fieldType
texthh_idHousehold ID
texthh_addressAddress
begin repeathh_membersHousehold Members
textmbr_nameName and last name
integermbr_ageAge
end repeat
hiddenmax_ageAge of oldest personmax(${mbr_age})esriFieldTypeInteger
hiddentotal_countTotal persons in housecount(${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.

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.

typenamelabelcalculation
texthh_idHousehold ID
texthh_addressAddress
begin repeathh_membersHousehold Members: ${interviews}
textmbr_nameName and last name
integermbr_ageAge
end repeat
hiddeninterviewsEvery person interviewedjoin(",",${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:

typenamelabelcalculation
textmanhole_idManhole ID
begin repeatcomponents_groupComponents
select_one componentscomponentComponent
select_one conditionsconditionCondition
end repeat
select_multiple components
comps_inspectedComponents 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.

typenamelabelrequiredrepeat_count
texthh_idHousehold ID
texthh_addressAddress
integerhh_totalHow many people live in this house?
begin repeathh_membersHousehold Members${hh_total}
textmbr_nameName and last nameyes
integermbr_ageAgeyes
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:

typenamelabelconstraintcalculation
textcc_idCircuit Panel ID
begin repeatbreakersCircuit Breakers
select_one typebreaker_typeType
select_one statusbreaker_statusStatus
end repeat
integertotalTotal Breakers${total}> 4 and ${total}<21count(${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. 

Nested repeats are only supported in the Survey123 field app.

The Survey123 web app does not support nested repeats.

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:

typenamelabelbind::esri:parameterscalculation
textpanel_idElectric Panel ID
geopointlocationLocation
begin repeatcircuitsCircuit Breakersquery
datetimeinsp_dateInspection date
select_one statusstatusStatus
end repeat
integertotalTotal Breakers${total}> 4 and ${total}<21count(${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.

typenamelabelbind::esri:parameterscalculationreadonly
textpanel_idElectric Panel ID
geopointlocationLocation
begin repeatbreakers Breakersquery allowUpdates=true
datetimeins_dateInstallation dateyes
datetimeinsp_dateInspection date
select_one statusstatusStatus
end repeat
71 Comments
David0044
New Contributor II

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
Esri Contributor

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:

DeonLengton_0-1616576781150.png

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

DeonLengton_1-1616576795487.png

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

DeonLengton_2-1616576864588.png

 

 

 

DougBrowning
MVP Frequent Contributor
erica_tefft
Occasional Contributor III

@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
New Contributor

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
New Contributor

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
New Contributor II

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

LinzMess_0-1624053490267.png

How the survey appears when a record contains a repeat:

LinzMess_1-1624053570521.png

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

Thanks!

Lindsey

 

 

MichaelBruening
New Contributor III

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
New Contributor II
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
New Contributor III

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
MVP Frequent Contributor

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
New Contributor III

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
New Contributor II

@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
New Contributor II

@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
New Contributor III

@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
MVP Frequent Contributor

"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
New Contributor II

@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
MVP Frequent Contributor

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
New Contributor II

@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
New Contributor III

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

Philip-Wilson
Esri Frequent Contributor

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.

About the Author
Currently in Denver