# Required fields not working correctly in fori loops

**URL:** <https://community.silverfin.com/t/required-fields-not-working-correctly-in-fori-loops/2149>\
**Category:** Templates\
**Created:** [September 16, 2021, 9:01am UTC](https://community.silverfin.com/t/required-fields-not-working-correctly-in-fori-loops/2149 "2021-09-16T09:01:42Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![robindeclercq](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.silverfin.com/robindeclercq/32/472_2.png) [@robindeclercq](https://community.silverfin.com/u/robindeclercq)\
**Post date:** [September 16, 2021, 12:15pm UTC](https://community.silverfin.com/t/required-fields-not-working-correctly-in-fori-loops/2149/2 "2021-09-16T12:15:02Z")

</div>

Hi @ronald_groot_RSF ,

Whenever you use this `required` attribute in inputs related to the `fori`, it will only work correctly for the `fori` itself. In your example the input is not related to the `fori` (because of the use of the custom drop `custom.[RGS_code].risk_remark`). This doesn’t seem to work as it tricks the code to think we’re in the last iteration of the loop (which in case of fori-structure is always empty.

Can we ask why did you choose to include a custom drop in the `fori` structure? Alternatives like `input item.[RGS_code]` might give the exact same output and required would work fine in that case.

Furthermore, you could combine this with the use of the persisted method to make it more clear for users from a functional perspective ([CASE: use persisted to hide parts of a loop](https://community.silverfin.com/t/case-use-persisted-to-hide-parts-of-a-loop/1413)).

Let me know if this is clear!

Kind regards,  
Robin

---

_[View the full topic](https://community.silverfin.com/t/required-fields-not-working-correctly-in-fori-loops/2149)._
