Description -
When using external lookup fields in Workfront (e.g., dropdowns that fetch values from external systems via webhook), there's currently no way to know which Workfront object or record the user is editing or interacting with when the webhook call is triggered. This limitation hinders the ability to tailor results or logic based on the specific context of the Workfront record, such as a project, task, or custom form.
Why is this feature important to you -
As an integration architect working extensively with Workfront Fusion and other middleware platforms, we frequently design experiences where dynamic dropdowns should return context-aware results. For example, showing different vendor lists, funding sources, or templates based on the portfolio, project type, or requestor. Without knowing which Workfront record the user is interacting with, we are forced to build complex workarounds, cache lookups, or create duplicative forms, all of which introduce fragility and increase cost and implementation time. This change would enable smarter, more responsive external lookups and unlock a wide range of enterprise use cases.
How would you like the feature to work -
When a user interacts with an external lookup field and the webhook is triggered, Workfront should include the context of the record (e.g., record ID, object type, or other related metadata) in either the HTTP headers or the body payload of the webhook request. Ideally, this would be configurable so admins can choose to send fields like projectID, customFormID, or even specific custom field values (e.g., selected portfolio or request type) to allow for contextual logic in the receiving system or Fusion scenario.
Current Behaviour -
Currently, Workfront external lookup webhooks send no identifying information about the record or object the field is on. This results in a "blind" call to the external system with no context, preventing the use of record-specific logic, filtering, or validation in the external lookup response.
