Access properties from object type

I currently have 2 object types and they are linked.
Currently, when used in a ObjectTable - I can directly access the proeprties of the of the main table in the column configuration. But the other objectType’s properties can only be accessed as a linked objects properties(the showAPI names in object table widget in workshop are named as link_column , link_column1…). This limits the export capabilities, as I have no access over how I can directly choose the properties dynamically and then exporting.
Is there already a solution for these problems already?

Function-backed columns let you pull linked object properties into named, fully-exportable columns you control rather than auto-generated link_column naming.

The problem:

Adding linked object properties directly in Object Table creates auto-generated columns (link_column, link_column1, etc.) that you can’t really rename or export reliably.

Proposed solution here is function-backed columns:

Write a TypeScript Function that traverses the link and returns the properties you want as named outputs, then wire it as a column.

Example — Order linked to Customer, showing name and email:

typescript

import { Function } from "@foundry/functions-api";
import { Order } from "@foundry/ontology-api";

export class LinkedPropertyFunctions {
    @Function()
    public async getCustomerName(order: Order): Promise<string | undefined> {
        const customer = await order.customer.getAsync();
        return customer?.customerName;
    }

    @Function()
    public async getCustomerEmail(order: Order): Promise<string | undefined> {
        const customer = await order.customer.getAsync();
        return customer?.email;
    }
}

Then configure in Object Table:

  1. Add a function-backed column

  2. Select the function (e.g., getCustomerName)

  3. Set display name (“Customer Name”, “Customer Email”)

Why this is better:

  • You control column names with no auto-naming collisions.

  • Fully exportable Object Table CSV/Excel export supports function-backed columns up to 10,000 rows.

  • You choose exactly which linked properties to surface.

Important clarification:

Function-backed columns are configured at build time by the module builder. End users can’t dynamically choose which linked properties appear at runtime. But as the builder, you have full control over what to pull through and how to name it.

Alternative here is to denormalize:

If you’re pulling the same linked properties across many modules, denormalize them into your primary object type via a PySpark or Pipeline Builder transform. This avoids per-row function calls and makes the properties available as native columns everywhere — no function wiring needed and cleaner at scale.

Docs: Object Table widget — column configuration, function-backed columns, export behavior