Typeahead User Custom Field Not Working as a Report Prompt

1. No
2. Yes
3. Not that I’m aware of
4. Not that I’m aware of

As per the attached screenshots, I’m using a typeahead field as a prompt on a project report

he zero-row result makes sense once you know how the value is stored, and it isn't something wrong with your setup.

A typeahead custom field doesn't store a bare user ID. It stores a JSON envelope as the field's value — reading the DE: field back through the API returns the literal string {"objCode":"USER","name":"Jenny Dawkins","ID":"5bc636d2..."} rather than the ID on its own. I checked this directly against a v17.0 instance because I hit the same wall from the API side. Two things fall out of it.

Asking for the sub-key on its own, the DE: field name followed by :ID, returns nothing. Not an error, not an empty value: the column is simply missing from the response. Workfront parses the :ID as part of the field name rather than as a selector into the value.

So a prompt built on that ID field has nothing to match against. It resolves and displays the name because the UI does its own user lookup on what you typed, and then the filter compares that bare ID against a record set where every stored value is the full envelope string. Nothing equals it, so you get zero rows. Expected given the storage, which answers your first question, and probably why it isn't documented anywhere I've found either.

What I'd try first for filtering: filter on the full field rather than the ID, with a contains modifier. The person's name is inside that envelope, so a cicontains match on the whole DE: field should select the right rows. I'd test it in preview before building on it, and there are limits worth knowing either way — it's a string match, so two people sharing a surname will collide on a partial, and the envelope captures the name at the moment the value was written, so if someone's name changes in Workfront the stored envelopes keep the old spelling until those records are rewritten.

If you end up rebuilding the field, one trap worth knowing in advance: the referenced object type on a typeahead has to be set when the field is created. Workfront rejects any attempt to add or change it afterward with "You cannot change the referenced object value for an existing Typeahead field." So repairing a typeahead means a new field plus a value migration, never an edit to the existing one — worth deciding before you invest more work in the current one.

For a genuinely reportable "who owns this" on tasks, I'd also weigh a real assignment or job role over a custom field where you can. The native ones filter and prompt without any of this.

The custom-form gotchas I keep open-sourced document the envelope behavior and the create-time trap with the exact API responses: github.com/Thousand-Cuts/wf-toolkit

Correcting myself: I tested this against a live tenant and I had the mechanic wrong above.

Filtering a typeahead by the bare ID does work. The filter engine indexes the field by the referenced object's ID, not by the JSON envelope the API returns on read — so eq against the full ID matches, and the name-based cicontains I suggested matches nothing at all. I checked it the other way too: a cicontains probe for the literal string objCode, which sits inside every stored envelope, returned zero rows. If the engine compared against the stored text, that would have matched everything.

So the storage shape isn't what's breaking your prompt, and you should ignore the workaround I gave you. What does still hold from my first reply is the read-side quirk — asking for the :ID sub-key returns the row with the column silently missing.

Which points somewhere more useful: at the API level a filter on that field works when it's handed an ID, so the failure is above the filter. Either the prompt layer isn't passing what you'd expect, or the separate "...ID" field you added is its own field with its own values rather than a view onto the typeahead. I'd check what that companion field actually contains on a record where the prompt returns nothing — if it's empty or holds something other than the 32-character user ID, that's your answer.

One caveat on my test: I ran it on a typeahead pointing at projects rather than users, through the API rather than a report prompt. The indexing behavior should be the same, but I haven't proven it for your exact case.