⚡️ Ideas
Adam J. Richman Adam J. Richman Jun 21, 2025

Contextual FIELDS

Explain the problem as you see it

We currently have: "regular" fields, "optional" fields, but we don't yet have "contextual" fields with defaults that can be overridden locally, able to be made from the supertag config (despite them able to be made elsewhere, via table view). Having this would unlock at least one great workflow, and likely many more.

Why is this a problem for you?

Specifically for this example, but surely in other scenarios...

I want to list and re-use a list of #[[invoice line item]] nodes, each with pre-filled fields like:

Rate:: $100
Unit:: per Day
Quantity:: 6 hours

Logo Design #[[invoice line item]]

Rate:: $100
Unit:: per Day
Quantity:: 6 hours

I then want to reference this node (and a few others from my "library" of invoice line items) on a new #invoice so I can keep track of things like, "how many times I billed this particular thing," and totals per this category at EOY.

The problem is that when I reference this node and I want to adjust the rate for say, a corporate client versus a non-profit, when I change those rates, they obviously change across all of these references.

The only current solution is to simply duplicate this node and then change the rates.

Suggest a solution

What would be more ideal and interesting is if we could have a NEW FIELD TYPE called a CONTEXTUAL FIELD, matching existing nomenclature. This new field type would be able to be overridden at a local level, each time the node is referenced. So it would come along with my defaults, but it could then be changed on a per-invoice basis.

We already have the ability to create contextual fields at the TABLE level (and they even track into list view), we just don't have a way to create them at the CONTENT TEMPLATE level.

2025-06-20 at 10.36.13 - Tana - Tana [Curïo]@2x.png