Let me choose primary key already

Ask the Community Get Answers
1

I might have misunderstood something, but…

I’m building a non-trivial CRM in Knack with users, leads, sites, orders, jobs, commissions, and multiple external integrations (Zapier, auth, booking systems, etc.). Overall, Knack works surprisingly well for this scale.

But there is one architectural decision that is frankly indefensible in 2025:

Display Field is hard-coupled to the key/value used in relationship dropdowns.

There is no way to:

  • define a true primary key (technical identifier)

  • separately define a human-readable display label

  • choose which field a connection dropdown should display

This violates basic database design principles that have existed since at least the 1980s.

In any relational system worth the name:

  • Primary key = stable, technical, machine-oriented

  • Display label = mutable, human-oriented

  • These are not the same thing

In Knack, they are forced to be the same.

Concrete problems this causes

To assign a user to a record, I want:

  • the key to be an immutable internal ID (or record ID)

  • the label to be something readable (name, email, role)

Instead, I’m forced to:

  • either expose technical IDs to humans (unusable UX), or

  • pollute the Display Field with composite strings like
    aID | Firstname Lastname | email, or

  • build proxy objects / lookup tables, or

  • pre-fetch data via Zapier into synthetic “A/B fields” just to get a usable dropdown

This is absurd.

I now have automation that:

  1. Looks up a user by email

  2. Pulls a pre-combined “ID + name” field

  3. Writes that back into Knack

  4. Uses that as the Display Field
    …all because I cannot tell Knack:
    “Use field X as the key and field Y as the label.”

This is not a “nice to have”.
This is foundational.

What this blocks or complicates unnecessarily

  • Clean integrations

  • Stable identifiers

  • Refactoring display names

  • Internationalization

  • Any serious CRM or ERP-like workflow

  • Any app where dropdown usability matters at scale

Requested feature (minimal and sufficient)

At object or field level:

  • Define Primary Key field (technical)

  • Define Display Label field (UI)

  • Or, at minimum: allow relationship fields to choose which field is shown in dropdowns

No breaking changes required.
Just decouple identity from presentation.

Right now Knack forces developers to work against 40+ years of established database logic for something as basic as assigning a user from a dropdown.

Everything else in the platform is “good enough to very good”.
This one decision creates disproportionate pain.

Please reconsider this architecture.

2

Hi @Alex3,

As you may know, each table record in Knack is assigned a unique record ID that looks something like 692e37fa8ad579bfge69a8d0. While it may not look like it on the surface UI, this is the true primary key.

When dealing with a connection field (e.g. field_30), the record field data is always structured like so:

field_30_raw: [
  { 
    id: "692e37fa8ad579bfge69a8d0", 
    identifier: "Stephen Chapman" 
  }
]

Where id is the unique record ID, and identifier is the display field for that connection’s table.

When passing this record to Zapier or equivalent, you should not need to rely on the display field to retrieve your unique ID, as you can use field_30_raw[0].identifier.

When returning data back into Knack, your PUT/POST body would look like:

{
   field_30: ["692e37fa8ad579bfge69a8d0"]
}

The only thing I would personally change about Knack is having changeable display fields per form, e.g. form 1 shows {Name} | {Email} and form 2 shows just {Name}.

Let me know if you’d like a quick call if that doesn’t quite make sense.

1 Like
3

Thanks for the reply and explanation. This does for sure increase reliability for external connections and I can put it to use.

I do still wish to be able to choose primary key myself, for a variety of reasons.

1 Like