# \[Request\] Interface-level derived properties and an object-type column in Object Table/List

**URL:** <https://community.palantir.com/t/request-interface-level-derived-properties-and-an-object-type-column-in-object-table-list/7414>\
**Category:** Product Feedback\
**Tags:** ontology-management, workshop\
**Created:** [October 27, 2026, 7:01pm UTC](https://community.palantir.com/t/request-interface-level-derived-properties-and-an-object-type-column-in-object-table-list/7414 "2026-10-27T19:01:14Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![dehling](https://yyz1.discourse-cdn.com/palantir/user_avatar/community.palantir.com/dehling/32/6941_2.png) [@dehling](https://community.palantir.com/u/dehling)\
**Post date:** [October 27, 2026, 7:01pm UTC](https://community.palantir.com/t/request-interface-level-derived-properties-and-an-object-type-column-in-object-table-list/7414/1 "2026-10-27T19:01:14Z")

</div>

I am building a Workshop application that makes use of an Ontology Interface to display multiple inheriting types into a single Object Table. Two limitations make this cumbersome to scale.

## **1. Definition of Derived Properties Once Upon an Interface**

As a simple example, lets assume a **Person** interface is implemented by both a **Employee** and **External Partner** types. The interface then defines a Link Constraint - mapping to another concrete **Task** object type, which **Employee** and \*\* External Partner\*\* can inherit.

I would like to define a calculation once, then expose it in an interface-based Object Table or Object List widget where the interface definition drives the link resolution not the concrete type definition. I would like to calculate the count of tasks assigned to a Person, and therefore either of the derivative types mentioned.

```auto
Person.openTaskCount = count(assignedTasks where status = "Open")

```

Currently I cannot configure this at the interface level. Defining equivalent calculations as separate derived properties for each implementing object types create maintenance overhead as well as duplicate work across implementing types. In this binary example this isn’t bad, but in certain lines of work like inventory management this becomes somewhat of a glass ceiling.

**Requested Capabilities:**

- Define linked aggregations and derived properties on an interface
- Resolve properties and links thru each implementing type’s mappings
- Expose the results in interface-based Workshop Object Tables and Object Lists
- Automatic support for new implementing types without duplicating the calculation

## **2. Display an inheriting object type as a column/row in an Object Table or List**

When **Employee** and **External Partner** types exist in the same widget due to the backing source being an Object Set hydrated from an Interface the default behavior is to have tabs that define the subsets. When squashed into a unified view I’d like to make use of an **Object Type** columns without the addition of a separate discriminator Property on each type - similar to how the **Object Title** is a selectable option presently.

**Requested Capabilities:**

- Add the concrete type’s display name as a standard column
- Ideally support sorting and filtering via this type display name

## **Existing Workaround**

I understand that a **Function on Objects (FOO)** could be leveraged here as a stop gap by centralizing the aggregation logic and returning calculated values or concrete object-type labels for display in the table.

```auto
import { Function, FunctionsMap, Integer } from "@foundry/functions-api";

import {
  Employee,
  ExternalPartner,
  Task,
  ObjectSet,
} from "@foundry/ontology-api";

interface PersonColumns {
  objectType: string;
  openTaskCount: Integer;
}

export class PersonTableFunctions {
  // Define the calculation once for both concrete types.
  private async calculateColumns(
    tasks: ObjectSet<Task>,
    objectType: string,
  ): Promise<PersonColumns> {
    const openTaskCount = await tasks
      .filter((task) => task.status.exactMatch("Open"))
      .count();

    return {
      objectType,
      openTaskCount,
    };
  }

  @Function()
  public async employeeColumns(
    employees: ObjectSet<Employee>,
  ): Promise<FunctionsMap<Employee, PersonColumns>> {
    const result = new FunctionsMap<Employee, PersonColumns>();

    for (const employee of await employees.allAsync()) {
      const tasks = employees
        .filter((person) => person.id.exactMatch(employee.id))
        .searchAroundAssignedTasks();

      result.set(employee, await this.calculateColumns(tasks, "Employee"));
    }

    return result;
  }

  @Function()
  public async externalPartnerColumns(
    partners: ObjectSet<ExternalPartner>,
  ): Promise<FunctionsMap<ExternalPartner, PersonColumns>> {
    const result = new FunctionsMap<ExternalPartner, PersonColumns>();

    for (const partner of await partners.allAsync()) {
      const tasks = partners
        .filter((person) => person.id.exactMatch(partner.id))
        .searchAroundAssignedTasks();

      result.set(
        partner,
        await this.calculateColumns(tasks, "External Partner"),
      );
    }

    return result;
  }
}

```

My request is specifically oriented towards native, declarative support rather than having to generate custom function code and wiring for such rudimentary inheritance patterns. Functions are useful for more complex business logic requirements, but a linked-object count and an object-type column feel like capabilities seem like out of the box features.

Is either capability already supported through a configuration of beta feature I’ve missed? If not, are there plans to support these patterns at a future date?