Current behavior
A reusable workflow can be started in two ways: by another workflow or automation via the "Pass to reusable workflow" step, or manually by a teammate from the Help Desk (⌘K → "Trigger reusable workflow"). Inside the workflow itself, there is no way to tell which of the two happened — branch conditions can only use people, company, and conversation data, and none of it reflects how the workflow was started.
The problem
The same reusable workflow often needs to behave differently depending on how it was launched:
- When a teammate triggers it manually, automatic reassignment steps are unnecessary or actively harmful — they can pull the conversation away from the very teammate who just triggered it.
- For reporting and downstream logic, we want to set attributes differently per trigger source, so that manually triggered runs don't distort automation statistics (and vice versa).
- Some steps only make sense in one mode — e.g. an intro message or a snooze that fits the automated path but is redundant when a human is already handling the conversation.
Because the trigger source is invisible, the only options today are:
- Duplicating the workflow into a "manual" and an "automated" version and keeping both in sync forever — which defeats the purpose of reusable workflows, or
- Having every parent workflow set a custom conversation attribute right before the "Pass to reusable workflow" step and branching on it inside the reusable workflow. This is fragile: every caller must remember to set it, the attribute has to be reset afterwards, and a manual trigger can't set anything beforehand at all.
Proposed idea
Expose the trigger source inside reusable workflows — ideally as a boolean system attribute, e.g. "Workflow triggered manually" (true/false), available in branch conditions and when setting attributes.
Example: if "Workflow triggered manually" = true → skip the reassignment branch and tag the run as manual; otherwise run the full automated path.
A richer "Trigger source" attribute (manually / by another workflow) would be even more flexible, but even the minimal boolean would already let a single reusable workflow safely serve both cases instead of being duplicated.
Who would benefit
Any workspace that uses reusable workflows both as building blocks inside automations and as manual one-click actions for teammates in the Help Desk. Today those teams either maintain near-identical duplicated workflows or build fragile attribute-based workarounds; a native flag would remove the need for both.