Extension point for the Users table — add columns / independent fetches without patching iam-engine source #38

Summary

Requesting an extension point in the Users list/table so a downstream extension can add a
custom column and start an independent data fetch alongside the users query — without patching
iam-engine's own source.

Context

We (Fliit, a Fleetbase extension — fleetbase/fliit-api / FliitAU/fliit-extension) ship a
"Fleetbase Access tier" column in the IAM Users table, showing a user's access tier alongside
core Roles. Since iam-engine is a mounted engine, its components resolve in the engine's own
container — a host-app or extension-side override is never looked up — so today the only way to
add this column is a pnpm patch on iam-engine itself, touching:

• addon/controllers/users/index.js
• addon/routes/users/index.js
• two new table/cell/fleetbase-access component files

This is fragile by construction: any iam-engine release that touches those files can break the
patch (context no longer matches) with no signal until pnpm install either silently skips it
or fails outright. It happened on the v0.1.11 → v0.1.12 bump — addon/controllers/users/index.js
was rewritten by 458 lines in that release, so we had to stay pinned at v0.1.11 rather than take
the bump.

This is the same underlying work as fleetbase/core-api#251 (merged 2026-09-09, thank you for
that one) — reducing IAM Users list latency — just the frontend half of the same effort.

Ask

A registry/extension-point mechanism for the Users table — similar in spirit to what the
console header already does for extension nav items — that would let a downstream extension:

1. Add a column to the Users table without overriding addon/controllers/users/index.js or
   addon/routes/users/index.js directly
2. Start its own data fetch keyed by user, independent of and not blocking the main users query

Happy to scope this further or put up a draft PR against iam-engine if that's useful — wanted
to raise the shape of the problem first, since we're not sure what extension surface (if any)
you'd want to expose here versus other approaches on our end.