Form with Multiple, Duplicate Entries: Best Practices

[ericonline]

Hello, 

I'm coming across a common (and complex) pattern within Forms and could use the community's help: 

Pattern: 

• User completes multiple, duplicate entries of some Form fields. 
  • Example: Form for a single Event
    • Task 1 Description
    • Task 1 Start Time
    • Task 1 End Time
    • User clicks "+" button and enters similar info but for Task 2
    • User completes remainder of Form (non-Task fields)
    • What is the best practice for capturing these items? Collection specifically for Tasks? Other method?
• These Task items should be displayed to the user so they can edit/delete. 
  • What is the best practice for displaying these items? Gallery specific for Tasks? Other method?
    • The Gallery really disrupts the rest of the Form. Hence the ask here. 
• These items should be written to Data Source using SubmitForm. 
  • What is the best practice for writing these items to their respective tables? 

Example UI: Here is what I end up with, but again, a separate "input bar with "+" for each item" mixed with a Form, mixed with a Gallery (not shown below) makes for a complex UI: 

I know this exercise starts with a logical table design (a good reference for this is the "Data Management Best Practices" forum post). Lets assume I we have that in place for this particular topic. I'm really interested in the UI and App elements here. 

Please post your ideas, I'm certain we can all benefit from a standard approach. 

[v-xida-msft]

Hi @ericonline,

Could you please share a bit more about your scenario?

Could you please share a bit more about the formula within the OnSelect property of the "+" button?

For your first question, do you want to type multiple and duplicate entries within the Edit form for different tasks?

If you want to type multiple and duplicate entries within the Edit form for different tasks, I think the Collection could achieve your needs. You could consider take a try to store the form data as a Collection (TempCollection) using ClearCollect function, then if you want to reference the same value within the form for Task2, you could pull data from the TempCollection.

I have made a test on my side, please take a try with the following workaround:

Set the OnSelect property of the "+" icon button to following formula:

ClearCollect(TempCollection,Form1.Updates);ResetForm(Form1)

Note: The Form1 represents the Edit form control within my screen.

Set the Default property of the Data card (which you want to remain same value as previous form) to following formula:

If(Form1.Mode=FormMode.New,First(TempCollection).Title,ThisItem.Title)

For your second question, if you want to display all task items within your app, I think the Gallery control could achieve your needs. You could consider take a try to create a sparated screen within your app, then within this screen, add a Gallery control to displays these task items.

For your third question, do you want to write these items back to one data source or each item to a separated data source? 

If you want to write data back to your data source, please check if the Patch function and SubmitForm function could help in your scenario.

Patch function, SubmitForm function

Best regards,

Kris

[ericonline]

Hi @v-xida-msft (Kris), 

Thank you for putting some thought and energy into this. Its a tough problem to explain and I'm afraid I wasn't clear enough. Let me clarify a bit more: 

RE: The "+" Button OnSelect property: 

• I do indeed ClearCollect the results and display them in a gallery below the Form fields. 
• Unfortunately, this results in what I would call, a complicated User Experience where 3 elements coexist in the same area (Repeating Field-input area, Gallery displaying Repeating Field inputs, and the remaining Form fields). 
• This complicated UX is what I'm trying to solve for in the post

Here is what I'm going to try (no visuals at this time to share): 

• Make the Repeating Field-input area and Gallery look like they are part of the Form
• Goal will be to make all Controls look like a single Form to ease UX. 

Will report back soon!

Thanks again.

[JonathanWest]

@ericonline

This is what I have come up with some of my apps.

We have a lot of InfoPath documents we are migrating to PowerApps

One document, in particular, has about 150 Questions. So having multiple screens is really not an option. (Unless the user wants to click the next button all day). 

I created a data form with dynamic positioning based on the previous control but we also had other tables with foreign keys in this document. So we had to add galleries into the PowerApp (Which is technically not a feature). The only problem is that when you get too far down the document with the galleries in the app and try and add an entry it causes the scrollbar position to go all the way to the middle of the DataCard.

This issue is described here but I found if you turn the "New Improved App Rendering" off then it works, but then you have other errors because you are using the old rendering engine.

If anyone has any other suggestions on how to make a scrollable screen with a one to many relationship I am all ears.  

[wyotim]

Great topic @ericonline! And I completely agree with your opening statement that this is a common issue. 

I worked out a bit of a solution for a one-to-many problem (as @JonathanWest so eloquently described it) that I will try to describe in the hopes that it can add something to this discussion and we can all work out a good best practice. Wall of text inbound!

*edit* Out of respect for everyone and the massive scrolling they might endure, I put my wall of text in a spoiler tag.

Spoiler

We have a wire rope inspection section in our maintenance app in which our supervisors input the results of inspections of a number of wire ropes on a rig. There are about 13-18 individual wire ropes with between 1 and 5 user inputs for each one, the number varying by whether the rig has one or two winch lines and what guy-securement systems they use. Essentially, the wire ropes would parallel the tasks in your scenario. There are also related items in our inspection (drum inspections, notes, etc.) that parallel the non-task fields in your scenario. In total, there are three different data tables storing inspection data: one which has entries for all maintenance tasks, one for the wire rope inspections, and one for related aspects of the inspection as mention before. This is also a phone app, so much of the design is a result of that choice.

The way I sorted it out for us was to not use forms or galleries. Instead, I built a form-like structure that shows/hides and formats input areas based on a page-like navigation system. This also allowed the freedom to group input items that are related but not in the same data tables (i.e. no restrictions from galleries or forms). It was a bit of work but, in the end, I think it was worth it. Plus, I couldn't find another way to do it.  In the case of having 150 different questions, this would be a tough build but depending on the questions, I would think there could be some way to do it where input areas could be reused and the layout was such that there could be a tenable pagination structure.

The navigation is controlled by a collection that acts like an index and is generated by the app for the specific inspection based on what rig is selected. Basically, there are buttons that change dynamically based on what the previous and next items in the index are, and these allow the user to go back and forth between items to enter data. I could see dynamically adding and removing items to this index, such as with your "+" button to add tasks. Also, the index has a key built in to tie it to the type of wire rope being inspected. 

Inputs for the inspection are stored first in temporary tables, allowing the user to enter/edit inputs before submission. This actually came as a result of the app requiring offline functionality but it turned out to be a really great way to handle the one-to-many aspects. This makes it pretty easy to enter and check the data without constant writing to the source as well. When the user has completed putting in the required items, they can then submit the data. This is done through a Collect in our case as the data is a one-time submission (it wouldn't be prudent if they could edit inspections after the fact). In the case where users need to go back and edit data, it would be possible to pull data into the temporary tables and use Patch instead of Collect.

One note on this: the offline functionality/temporary table structure necessitated de-normalizing the data a bit so that there was some sort of key to tie the items together in lieu of a SQL generated ID. I ended up using a composite of the user ID, inspection date, and equipment ID in each table, which has worked well. 

On the display/review side, this is where my approach differs quite a bit. Instead of a data review or anything like that, I created a graphic of a top-down view of a rig with the wire rope locations color-coded based on the completeness and quality assessment. I would assume having a summary shown from what is stored in the temporary tables would work, perhaps using a gallery based on the index and custom fields to display relevant information.

So, those are the high-level aspects of what I came up with. My solution is a bit complex but I didn't see any other way at the time given the needs associated with the scenario. Feel free to critique it or ask for more detail if you like. This was actually the first PowerApp I ever built, so I am sure there is plenty of room for improvement.

As stated before, this seems a common scenario and if we can work out some best practices I suspect it would be very helpful to a number of people.

[ericonline]

Awesome write up @wyotim! 

I have a couple questions for you: 

• When you say "I built a form-like structure that shows/hides and formats input areas based on a page-like navigation system."
  • Does this mean you created your own "form fields" with labels, asterisks, error messages, error handling, ect.?
  • If so, what are some best practices for this? I got stuck here a while back where I had to manually write all the error handling. Was quite a challenge.
• Wow! "...a collection that acts like an index and is generated by the app for the specific inspection based on what rig is selected"
  • This I'd like to know more about! 
  • How is the collection initialized?
    • If user selects Inspection A, Collection A is initialized, If Inspection B, Collection B is initialized?
  • How does the app "traverse" the "index"?
    • When user clicks "Next" button, Lookup(indexCol, some=condition, result) ? 

Dude! Neat stuff. Are you ever in Seattle? We should hang out!

[wyotim]

@ericonlineFor the first question, essentially yes, with some caveats.

The labels and inputs are dynamic in some cases so they change as the user selects different items.

In my case, all the items are required except for the notes area, so my primary validation method is making sure there are inputs for every item. Some of the items are radio controls but the majority of them are numerical, so the text boxes are set to numerical inputs which solve the majority of issues with the data entry. The user's inputs are assessed right away as the app compares the input to a specified boundary based on the wire rope type so they get instant feedback on what they entered, making it easy to see errors before submission. In that regard, the error handling is pretty light and handled in the input field before submission.

This does put a lot on the user but hopefully is enough to guide them and let them know if data was mis-entered. A complication with this is that an entry outside the normal bounds could be a legitimate entry, which is another reason for the light approach. Another aspect is that every completed inspection triggers an email with an out-of-bounds items noted so that our operations managers can review the data, so while not technically part of the error handling in-app, it is part of the process.

I am not sure if there are too many best practices to glean from my approach and I am definitely open to input as I want/need to grow in this area!

On the second question, the collection is initialized in the OnVisible section of the inspection screen, based on the selection from a gallery. There are two key items for our situation that decide which of the two versions to use, so a simple If statement is all that is needed. 

As far as traversing the index, I use a UpdateContext on an arrow button to track a number. The number relates to the position in the index and is used for the text labels. I'll include my code so you can see it:

/* Button code for the next item */
If(
    CurrentInspectionItem.Text = "Winch Line 1" ,
    If(
        LookUp(RigCollection, EquipmentID = EquipmentListBrowseGallery.Selected.ID).WinchLineCount = 1,
        UpdateContext({LocationVariable: LocationVariable + 2}),
        UpdateContext({LocationVariable: LocationVariable + 1})
    ),
    If(LocationVariable < 19, 
        UpdateContext({LocationVariable: LocationVariable + 1}), 
        ""
    )
)

/* Text code for the next item */
Substitute(
    If(
        CurrentInspectionItem.Text = "Winch Line 1",
        If(
            LookUp(RigCollection, EquipmentID = EquipmentListBrowseGallery.Selected.ID).WinchLineCount = 1,
            LookUp(RigWireRopeLocationCollection, 
                ID = LocationVariable + 2, 
                RigLocationName
            ),
            LookUp(RigWireRopeLocationCollection, 
                ID = LocationVariable + 1, 
                RigLocationName
            )
        ),
        If(
            LocationVariable = 19,
            "",
            If(
                LocationVariable = 18, 
                "Notes", 
                If(LocationVariable = 17, 
                    "Clamps",
                    LookUp(RigWireRopeLocationCollection, 
                        ID = LocationVariable + 1, 
                        RigLocationName
                    )
                )
            )
        )
    ),
    If(
        LookUp(
            RigCollection, 
            EquipmentID = EquipmentListBrowseGallery_1.Selected.ID, 
            Sheaves
        ) = true, 
        "/Boomer", 
        "Sheave/"
    ),
    ""
)

For updating the number, the main complexity for my scenario is knowing if the rig has one or two winches and if the list is at the beginning or end of the list. The previous item button code is much the same just checking if the number is less than one to show that the selected item is the first one. 

For the text, the complexity is a bit greater in that some items are altered (the Sheave/Boomer is truncated based on what the rig actually uses) and some items have to be made because they aren't wire rope items (Clamps and Notes). Obviously, this is before I learned to use the If statement in a non-nested way. I need to update the code a bit!

The number is the PK for the wire rope type, so I can reuse it to help in the quality assessment as well as setting up what should be shown/hidden and how it is formatted. That is essentially what everything is based on. The temp tables are also pre-made and ready for input. There is an Update function in the OnChange area of each input field so that it goes to the right place.

Unfortunately, I don't get to Seattle that often but maybe that needs to change. The last time I was in town was for the Microsoft Data Insights Summit last year, which was the old name for the Business Applications Summit. I didn't make it to the Summit this year sadly. If I head up to your area, I will shoot you a message for sure!

Let me know if I can clear anything else up. It's a bit difficult to describe but hopefully what I wrote is decently understandable. Again, feel free to offer any suggestions or critiques. There is plenty of room for improvement on my side and it would be great to get to a best practice of some kind for these scenarios.

*edit* Screenshot for reference. Again, this is the first app I ever made so any chuckling at the design is warranted. The color scheme is an attempt to use brand colors and results in a pretty bold scheme. I am in the process of revamping this app now, so it won't actually look like this by the end of the week.

[JonathanWest]

@wyotim

So let me ask you this.

I may not be understanding your app very well but why didn't you just use different screens and navigate to them instead of hiding controls and what not. You still would have to build a Navigation Model for it depending on the entity and what questions needing to be asked.

[wyotim]

That is a great question. I guess for two reasons: first, because the idea never occurred to me. 

Second, because this app was already pretty screen heavy (it was at like 19 or so at that point), I was just trying to not have to build more onto it by that point. It was the first PowerApp I had made and I started on it basically when PowerApps went GA and released the first version in about 6 weeks. Truth be told, it was the first app I had ever made, not just my first PowerApp. My main experience is in Excel/VBA, which is a bit of a far cry from PowerApps, so I had/still have a lot to learn.

And really, once I got to the temporary table aspect along with the index, it was pretty easy to map the data to and from the input areas so it seemed a good approach at the time. And it has held up pretty well too. While I am currently redesigning the app, that approach is staying. (I am cleaning up the code a bit though. Those unnecessary nested Ifs...)

Mainly because the idea never occurred to me though. That does seem like it would be a cleaner approach (and the more obvious one in hindsight). Again, great question!

[wyotim]

So in thinking a bit more about this, I realized there are some other areas that have a similar one-to-many structure which I approach in a much simpler manner. We have an area in an app to track and enter employee information such as training records. There are a number of these trainings that must be renewed, be it annually or some other multi-year scale. The way that I display these is in a nested gallery. I then have a pop-out form to add/edit/delete entries.

In keeping with the use of forms and the SubmitForm function, what about having a form for tasks and a form for the rest of the items? (Assuming this is a two-table design that is; you would need a form for each table basically.) On the tasks form, it could have a button to add another task (which would submit the current form and refresh it for another entry), and a button that went to the form to add the rest of the data (which would also submit the task form). 

The information could then be shown in a nested gallery (a gallery of galleries?) next to the form area which would add the information as it is submitted, giving the user a view of their submissions. There could be buttons to allow the user to add/edit/delete from the gallery as well, which would bring up the applicable form.

This is certainly simpler in design than my previous offering. The main downside I see is how slow it would be to enter data. One monolithic form would be much faster for sure.