You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firstly, I love the work you're doing and how adaptable this product is!
I acknowledge this is quite a broad ask and probably has many features that can be delivered to better handle this request, but thought we could start with a single issue. As some context, I initially wrote this request as a direct request for a polymorphic reference type but thought i'd step back and describe the problem i'm trying to solve. I did look for related requests but couldn't find an actual feature request put in.
Describe the problem to be solved
I have a few tables that are somewhat polymorphic, and depending on the type of record / row, different columns / scenarios are relevant. Here are some examples to show you what I mean:
Example 1:
A CRM style document that has tables such as:
customers
orders
support requests
notes
The notes table can be related to a customer, order, or a support request, but a single row will only ever be related to one. At the moment, if we wanted to create a new note from a list of notes, we'd have to show every reference column.
Example 2:
A inventory / ERP style document that has tables such as:
inventory (think an asset but with a quantity e.g. 5x potatoes)
assets (a concrete, single item)
schedules (e.g. maintenance, end of life)
In this example, inventory and assets could probably be represented by a single polymorphic table, as the only difference between them is quantity, however, there is no way for us to not show this column when inventory is the asset type.
Alternatively, and as shown, we can have separate tables but this means we have the same problem as example 1, where a schedule can relate to either inventory or an asset but we lack a good way of showing this in the UI.
Example 3:
Not a direct use case I have, but have seen in the wild on other platforms.
A Sales focused CRM document that has tables such as:
leads
opportunitys
orders
As a lead / opportunity progresses through it's lifecycle, different columns may be relevant.
Describe the solution you would like
I can think of two features that could help all of my examples:
Dynamic pages via conditional widgets
Ideally, we could set widgets to appear / disappear conditionally, however, I can imagine this would make editing the layout challenging unless there was some way to manage page variants and switch between the different variants / conditional outcomes. I think a more realistic option would be to change the visibility of specific columns of a widget based on some criteria.
I think each widget type would be able to be more or less dynamic based on it's own constraints, for example a related table widget would be able to change the columns based only the selected row as it has to be consistent across every item. On the card list widget you could change the columns based on the selected row or the (related) row itself as the columns do not have to remain constant against each item.
Polymorphic references
If we could create a reference column that could reference more than one table, for example, a single column on notes could reference all things it can be related to.
This has some implications for formulas trying to use the reference I imagine and I can think of some possible solutions:
only allow formulas to reference columns that are common across all of the tables (not ideal)
provide a function to select a particular column depending on the table is referenced e.g. select_poly_column($related_to, "customers", "name", "orders", "number", "support_requests", "case_id)" would return namefor a customer,numberfor a order andcase_id` for a support request
I am sure there are solutions available today that involve multiple pages with single type tables, formulas and action buttons and such but I don't think they are fit for every use case and certainly they lead to harder DX and / or UX. Although, i'd still like to hear how people handle these type of scenarios today! But I do believe these features, if implemented, could open up a lot of possibilities for users without having to reach for custom widgets / code / workarounds.
The text was updated successfully, but these errors were encountered:
bowdi
changed the title
Support for dynamic pages
Feature request: Support for dynamic pages
Feb 5, 2025
bowdi
changed the title
Feature request: Support for dynamic pages
Feature request: Support for dynamic elements
Feb 5, 2025
Context
Firstly, I love the work you're doing and how adaptable this product is!
I acknowledge this is quite a broad ask and probably has many features that can be delivered to better handle this request, but thought we could start with a single issue. As some context, I initially wrote this request as a direct request for a polymorphic reference type but thought i'd step back and describe the problem i'm trying to solve. I did look for related requests but couldn't find an actual feature request put in.
Describe the problem to be solved
I have a few tables that are somewhat polymorphic, and depending on the type of record / row, different columns / scenarios are relevant. Here are some examples to show you what I mean:
Example 1:
A CRM style document that has tables such as:
The notes table can be related to a customer, order, or a support request, but a single row will only ever be related to one. At the moment, if we wanted to create a new note from a list of notes, we'd have to show every reference column.
Example 2:
A inventory / ERP style document that has tables such as:
In this example, inventory and assets could probably be represented by a single polymorphic table, as the only difference between them is quantity, however, there is no way for us to not show this column when inventory is the
asset
type.Alternatively, and as shown, we can have separate tables but this means we have the same problem as example 1, where a schedule can relate to either inventory or an asset but we lack a good way of showing this in the UI.
Example 3:
Not a direct use case I have, but have seen in the wild on other platforms.
A Sales focused CRM document that has tables such as:
As a lead / opportunity progresses through it's lifecycle, different columns may be relevant.
Describe the solution you would like
I can think of two features that could help all of my examples:
Dynamic pages via conditional widgets
Ideally, we could set widgets to appear / disappear conditionally, however, I can imagine this would make editing the layout challenging unless there was some way to manage page variants and switch between the different variants / conditional outcomes. I think a more realistic option would be to change the visibility of specific columns of a widget based on some criteria.
I think each widget type would be able to be more or less dynamic based on it's own constraints, for example a related table widget would be able to change the columns based only the selected row as it has to be consistent across every item. On the card list widget you could change the columns based on the selected row or the (related) row itself as the columns do not have to remain constant against each item.
Polymorphic references
If we could create a reference column that could reference more than one table, for example, a single column on notes could reference all things it can be related to.
This has some implications for formulas trying to use the reference I imagine and I can think of some possible solutions:
select_poly_column($related_to, "customers", "name", "orders", "number", "support_requests", "case_id)" would return
namefor a customer,
numberfor a order and
case_id` for a support requestI am sure there are solutions available today that involve multiple pages with single type tables, formulas and action buttons and such but I don't think they are fit for every use case and certainly they lead to harder DX and / or UX. Although, i'd still like to hear how people handle these type of scenarios today! But I do believe these features, if implemented, could open up a lot of possibilities for users without having to reach for custom widgets / code / workarounds.
The text was updated successfully, but these errors were encountered: