Feature Request: Support Custom Headers / Append User for ValidateAndFetch Workflow Field
F
Fairy tale Canidae
Summary:
We need Harness IDP workflows to support sending custom headers, including user email, from the ValidateAndFetch field type.
Currently, appendUser works with SelectFieldFromApi, but it does not work with ValidateAndFetch. As a result, workflows that use a button-based validation pattern cannot pass required user context, such as email, to backend APIs.
Module
IDP
Category
Feature Request / Enhancement
Priority
High
Log In
F
Fairy tale Canidae
It looks like this is a duplicate ticket, there is already one created last week. you can close this ticket. thanks.
F
Fairy tale Canidae
Use Case
We are building an IDP workflow where users select a project/module and then explicitly validate whether AD groups exist.
The workflow should allow the user to click a button:
Validate AD Groups
This button should call the backend API:
POST /hoover-service/idp/ad-groups/validate
with the request body:
body:
key: "{{parameters.project}}"
sysId: "{{parameters.sysId}}"
and headers:
headers:
Content-Type: application/json
source: workflow
email: logged-in-user-email
The backend requires the email header for authorization/audit purposes.
Acceptance Criteria
ValidateAndFetch supports appendUser with location: headers.
ValidateAndFetch supports sending logged-in user email as a request header.
Custom headers configured under request.headers are sent to the backend.
Template values such as {{ formContext.user.email }} are resolved before the request is sent.
Existing proxy allowedHeaders behavior continues to work.
The behavior should be consistent across supported field types, especially SelectFieldFromApi and ValidateAndFetch.
Users can keep the button-based validation experience without switching to SelectFieldFromApi.
Customer Ask
Please add support for sending custom headers and/or appendUser headers from the ValidateAndFetch workflow field type.
This is needed so we can preserve the button-based user experience while passing required user context to our backend APIs for authorization and auditing.
F
Fairy tale Canidae
Option 2: Support Custom Headers with Template Resolution
Allow workflow expressions such as user email to be resolved and sent as custom headers in ValidateAndFetch.
Example:
request:
method: POST
headers:
Content-Type: application/json
source: workflow
email: "{{ formContext.user.email }}"
Expected result:
email: logged-in-user@company.com
source: workflow
Currently, the header value is not being resolved properly for this field type.
Expected Behavior
When using ValidateAndFetch, Harness should allow sending headers such as:
headers:
Content-Type: application/json
source: workflow
email: "{{ formContext.user.email }}"
or support:
appendUser:
data:
- email
location:
- headers
The backend should receive:
Content-Type: application/json
source: workflow
The API should then be able to authorize the request and return a successful response.
Actual Behavior
SelectFieldFromApi sends the email header successfully using appendUser.
ValidateAndFetch does not send the email header.
Manually setting email: "{{ formContext.user.email }}" also does not work as expected.
Backend receives the request without the required email header.
API returns 401 Unauthorized.
F
Fairy tale Canidae
Impact
Our backend service requires the user email header for authorization and auditing. Since ValidateAndFetch does not send the email header, the API returns a 401 Unauthorized response.
Example failing API:
Plain TextPOST /hoover-service/idp/ad-groups/validate
Observed response:
Plain Text401 UnauthorizedShow more lines
The same backend proxy and allowed headers configuration works successfully with SelectFieldFromApi.
Proxy configuration:
proxy:
endpoints:
/platform-api:
pathRewrite:
/api/proxy/platform-api/?: /
headers:
Content-Type: application/json
Accept: application/json
allowedHeaders:
- source
- email
Business / User Experience Need
We need to keep this interaction as a button-based validation experience for end users.
The current workaround suggested is to replace ValidateAndFetch with SelectFieldFromApi, since appendUser works there. However, this is not ideal because:
SelectFieldFromApi behaves like a dropdown/select field.
It triggers automatically based on input availability.
It does not provide the intended user experience of clicking a Validate AD Groups button.
The validation action should be explicit and user-driven.
Our requirement is to present a button such as:
Validate AD Groups
When the user clicks the button, Harness should send the configured request along with required headers, including user email.
Requested Enhancement
Please enhance Harness IDP workflows so that ValidateAndFetch supports one or both of the following:
Option 1: Support appendUser in ValidateAndFetch
Allow this configuration to work the same way it works in SelectFieldFromApi:
appendUser:
data:
- email
location:
- headers
Expected result:
email: logged-in-user@company.com
source: workflow
F
Fairy tale Canidae
Current Behavior
In Harness IDP workflow forms, the appendUser functionality successfully sends the logged-in user’s email as a request header when using SelectFieldFromApi.
Example working field type:
ui:field: SelectFieldFromApi
ui:options:
path: proxy/platform-api/hoover-service/idp/projects?sysId={{parameters.sysId}}
appendUser:
data:
- email
location:
- headers
request:
method: GET
headers:
source: workflow
For this field, the backend receives the email header correctly.
However, the same approach does not work for ValidateAndFetch.
Example not working field type:
adGroupsValidation:
title: Validate AD Groups
type: string
ui:field: ValidateAndFetch
ui:options:
button:
title: Validate AD Groups
position: left
path: proxy/platform-api/hoover-service/idp/ad-groups/validate
appendUser:
data:
- email
location:
- headers
request:
method: POST
headers:
Content-Type: application/json
source: workflow
body:
key: "{{parameters.project}}"
sysId: "{{parameters.sysId}}"
valueSelector: data.hasAdGroup
setContextData:
hasAdGroup: data.hasAdGroup
The backend does not receive the email header for the ValidateAndFetch request.