Summary
When a workflow job template contains multiple approval nodes, all approval
nodes currently share the same set of notification templates (configured at the
workflow job template and/or organisation level). There is no way to route
different approval nodes to different notification channels.
Use case
Enterprise workflows commonly have multiple approval gates serving different
purposes: security review, change management, finance sign-off. Each gate needs
to notify a different audience through a different channel (for example,
security team via Slack, change board via MS Teams webhook, finance via email).
Today all approval nodes fire the same notification templates, creating noise
and slowing down response times. Operators work around this by nesting
workflows (each with its own notification set) or by including the node name in
Jinja2 templates, but neither approach provides true per-node routing.
Proposal
Add a notification_templates_approvals M2M field to
WorkflowApprovalTemplate, exposed via the REST API at
/api/v2/workflow_approval_templates/{id}/notification_templates_approvals/.
When node-level templates are configured they take precedence; when empty, the
existing WFJT/Organisation-level templates are used (fully backward compatible).
Related
Summary
When a workflow job template contains multiple approval nodes, all approval
nodes currently share the same set of notification templates (configured at the
workflow job template and/or organisation level). There is no way to route
different approval nodes to different notification channels.
Use case
Enterprise workflows commonly have multiple approval gates serving different
purposes: security review, change management, finance sign-off. Each gate needs
to notify a different audience through a different channel (for example,
security team via Slack, change board via MS Teams webhook, finance via email).
Today all approval nodes fire the same notification templates, creating noise
and slowing down response times. Operators work around this by nesting
workflows (each with its own notification set) or by including the node name in
Jinja2 templates, but neither approach provides true per-node routing.
Proposal
Add a
notification_templates_approvalsM2M field toWorkflowApprovalTemplate, exposed via the REST API at/api/v2/workflow_approval_templates/{id}/notification_templates_approvals/.When node-level templates are configured they take precedence; when empty, the
existing WFJT/Organisation-level templates are used (fully backward compatible).
Related