---
title: "OFA: implementing 2 \"disconnected\" forms on the same entity - is it possible?"
url: "https://openforis.support/questions/4520/ofa-implementing-2-disconnected-forms-on-the-same-entity-is-it-possible"
tags: ["openforis"]
status: "answered"
score: 0
answer_count: 3
asked: "2026-07-08T23:18:46"
last_activity: "2026-09-22T14:16:18"
source: "Open Foris Support - Q&A Forum"
license: "Copyright Open Foris, 2026. Some rights reserved under creative commons license."
---

# OFA: implementing 2 "disconnected" forms on the same entity - is it possible?

Asked by acer on 2026-07-08

Dear OFA team,
I am trying to implement a specific workflow in OFA and would like to know if it's possible.
Here is the scenario:

 1. First Form: The user enters a list of trees with attributes: *treeID, species, dbh, and azimuth.*
 2. Second Form: The user navigates to a new form that displays a filtered subset of those trees (e.g., dbh > 10 and conifers only). From this list, the user selects a tree to enter an additional attribute (e.g., *height*).

I know this could technically be achieved within a single form by dynamically changing the visibility of the height attribute. However, due to our workflow requirements, we specifically need a two-form setup where the second form only shows the filtered trees.

Is there a feature or option in OFA that supports this kind of multi-form scenario?


## Answer (score 0, by Stefano (OF) on 2026-07-10)

Link: https://openforis.support/questions/4520/ofa-implementing-2-disconnected-forms-on-the-same-entity-is-it-possible/4522

Dear User,  
Thank you for reaching out. Currently, we do not have a feature that supports this specific scenario. However, we are already working on a solution that we believe will fit your needs, which is expected to be available by the end of August.  
How it will work:  

 - the filtered entity table will have to include a "minimum count" expression (to determine the number of filtered items) and a "relevancy"
   expression.  
 - when the table becomes relevant, the specified number of entities will be automatically generated.  
 - you will then need to set certain attributes as read-only (fetching values directly from the "source" table) while keeping other attributes editable.

Could a feature like this work for your use case? We would love to hear your thoughts.  
Best regards,  
The Open Foris Arena Team


## Answer (score 0, by acer on 2026-09-22)

Link: https://openforis.support/questions/4520/ofa-implementing-2-disconnected-forms-on-the-same-entity-is-it-possible/4550

Dear Stefano,
has this solution already been implemented?
I tried the steps below, but the automatic creation of records for adding height to filtered trees didn't work. Note that the first and second entities/form are on the same level, and both are child entities of the parent entity "Plot".

**First form (display trees):** 

multiple enabled

attributes: *treeID* as key, *species*, *dbh* and *azimuth*

**Second form (display filtered trees only):** 

multiple & auto-create minimum items enabled. 

Validations->Min count expression =   count(trees[azimuth>100])

attributes: 

*ID* as readonly with default value expression: index($context) + 1

*treeID_reference* as readonly with default value expression: trees[azimuth>100][index()-1].treeID

*height* as editable number.


## Answer (score 0, by Stefano (OF) on 2026-09-22)

Link: https://openforis.support/questions/4520/ofa-implementing-2-disconnected-forms-on-the-same-entity-is-it-possible/4551

Dear user,  
We have a solution that should work for your use case, though it requires using a category and a code attribute for both the tree ID and the filtered tree ID.  
![alt text][1]

If you want the ID to be auto-incremental, you will need to define a custom default value expression:  
![alt text][2]  

Next, the filtered tree entity must be marked as **Enumerate**, and you should define an **Enumerating items expression** to supply the category items used to generate the rows for the filtered tree entities.  
![alt text][3]  

The ID attribute in the filtered entity should be a code attribute marked as a key. It will act as the **enumerator** and function automatically as read-only (no need to manually mark it as read-only).  
  
If you need to extract specific values from the source table, use an expression like this:  
![alt text][4]  

This will produce the following final result:  
![alt text][5]  
Please be careful when you modify the "source" tree table attribute values (e.g. the azimuth); rows of the filtered table could be deleted or new ones could be added dynamically. Please consider adding some condition to make the entire source table editable or not, preventing accidental editing of it.  

Hopefully this can fit your needs.  
Many thanks,  
The Open Foris Arena Team


  [1]: https://openforis.support/upfiles/Screenshot_From_2026-09-22_14-12-00.png
  [2]: https://openforis.support/upfiles/Screenshot_From_2026-09-22_13-10-35.png
  [3]: https://openforis.support/upfiles/Screenshot_From_2026-09-22_13-08-27.png
  [4]: https://openforis.support/upfiles/Screenshot_From_2026-09-22_13-14-42.png
  [5]: https://openforis.support/upfiles/Screenshot_From_2026-09-22_13-05-26.png