Is your feature request related to a problem? Please describe.
I'm always frustrated when I need to manually start a workflow from the Temporal Web UI that depends on custom headers for context propagation (e.g., x-tenant-id in multi-tenant applications).
Currently, the Web UI allows me to specify Workflow ID, Task Queue, Input, Memo, and Search Attributes, but there's no way to add custom headers. This means I cannot test or manually trigger workflows that rely on header-based context without writing separate scripts or using the CLI, which defeats the purpose of having a user-friendly Web UI.
Describe the solution you'd like
I would like to see a "Headers" section added to the "Start Workflow" form in the Web UI, similar to the existing "Memo" and "Search Attributes" sections.
The interface could accept a JSON object where keys are header names and values are header values (strings):
{
"x-tenant-id": "tenant-123",
"x-user-id": "user-456"
}This would allow users to specify custom headers when starting workflows, just like they can do programmatically via the SDK:
await client.workflow.start(myWorkflow, {
taskQueue: 'default',
workflowId: 'my-workflow-id',
args: [{ data: 'value' }],
headers: {
'x-tenant-id': 'tenant-123'
}
});Describe alternatives you've considered
- Using Memo: This doesn't work because workflow interceptors and middleware typically read from headers via
workflowInfo().headers, not from memo
- Using Search Attributes: Same limitation as memo, plus search attributes have type constraints and are meant for querying, not context propagation
- Using Temporal CLI: This works (
temporal workflow start --header "x-tenant-id=tenant-123"), but requires CLI access and is less convenient than the Web UI
- Creating wrapper API endpoints: This adds unnecessary infrastructure complexity just to work around a UI limitation
Additional context
Many modern applications use header-based context propagation for cross-cutting concerns like tenant identification, tracing, authentication, etc. This pattern is common in multi-tenant SaaS applications and is inspired by standards like OpenTelemetry's baggage propagation.
Supporting custom headers in the Web UI would:
- Align the Web UI capabilities with what's possible via the SDK
- Improve developer and operations team productivity
- Make the Web UI a complete tool for workflow management, not just workflow monitoring
This feature would be particularly valuable for testing, debugging, and operational scenarios where manual workflow triggering is needed.
Is your feature request related to a problem? Please describe.
I'm always frustrated when I need to manually start a workflow from the Temporal Web UI that depends on custom headers for context propagation (e.g.,
x-tenant-idin multi-tenant applications).Currently, the Web UI allows me to specify Workflow ID, Task Queue, Input, Memo, and Search Attributes, but there's no way to add custom headers. This means I cannot test or manually trigger workflows that rely on header-based context without writing separate scripts or using the CLI, which defeats the purpose of having a user-friendly Web UI.
Describe the solution you'd like
I would like to see a "Headers" section added to the "Start Workflow" form in the Web UI, similar to the existing "Memo" and "Search Attributes" sections.
The interface could accept a JSON object where keys are header names and values are header values (strings):
{ "x-tenant-id": "tenant-123", "x-user-id": "user-456" }This would allow users to specify custom headers when starting workflows, just like they can do programmatically via the SDK:
Describe alternatives you've considered
workflowInfo().headers, not from memotemporal workflow start --header "x-tenant-id=tenant-123"), but requires CLI access and is less convenient than the Web UIAdditional context
Many modern applications use header-based context propagation for cross-cutting concerns like tenant identification, tracing, authentication, etc. This pattern is common in multi-tenant SaaS applications and is inspired by standards like OpenTelemetry's baggage propagation.
Supporting custom headers in the Web UI would:
This feature would be particularly valuable for testing, debugging, and operational scenarios where manual workflow triggering is needed.