As a developer working in a sandbox, I want to turn my workflow on, so that I can check a real request or a schedule reaches it before I promote.
Part of #4852 (Sandbox DevX epic).
What's broken
A sandbox clone arrives as a draft with its triggers off, which is right. But a sandbox has no control to turn it back on. Go live and Switch to draft are both hidden inside a sandbox, and so is the lifecycle badge. The only lifecycle control a sandbox has is Promote.
So inside a sandbox you can still hit Run and pass input by hand, but you cannot receive a real webhook call and a schedule will never fire.
On staging today you can, using the enabled toggle in the header. This epic removes that toggle deliberately, because enablement becomes a consequence of the lifecycle, and that is the right call. But it removes it everywhere, and in a sandbox nothing replaced it. That is a capability people have now and would lose, which is not something we should ship.
Why this is small
The state we want already exists and is already permitted. A live workflow inside a sandbox stays editable, deliberately: the editing rule reads that a live workflow is read-only only on its own project. So "on, and still being worked on" is a designed state for a sandbox. There is simply no way to reach it from the UI.
So this is a button, not a new concept, and not a new per-trigger mechanism.
What to build
One control in the sandbox header that turns the sandbox's workflow on and off, using the same lifecycle transitions the parent uses.
Copy needs deciding. "Go live" is wrong here: nothing is going into production, the workflow starts answering on the sandbox's own URL. Something closer to the sense of turning the sandbox on.
Two things that are already safe and need no work. A sandbox webhook answers on a URL namespaced by its own project and unique within it, so it can never collide with the parent's live endpoint. And a sandbox that is on behaves exactly as any enabled workflow does today, which is the parity we are restoring rather than new behaviour.
While we are here, delete the trigger enabled control component. It was built for a footer the inspector rewrite removed, nothing renders it, and this issue makes it unnecessary rather than something to re-home.
Worth knowing, not in scope
A sandbox runs with the parent's real credentials, so turning it on means a real request can write to the production system it was cloned from. That is #4860 and it is the thing that makes this safe to use, but it is not a reason to hold this.
Turning a workflow on outside the lifecycle also skips the activation limit that going live respects. Worth confirming whether that matters, since this route goes through the lifecycle and would respect it.
Acceptance criteria
As a developer working in a sandbox, I want to turn my workflow on, so that I can check a real request or a schedule reaches it before I promote.
Part of #4852 (Sandbox DevX epic).
What's broken
A sandbox clone arrives as a draft with its triggers off, which is right. But a sandbox has no control to turn it back on. Go live and Switch to draft are both hidden inside a sandbox, and so is the lifecycle badge. The only lifecycle control a sandbox has is Promote.
So inside a sandbox you can still hit Run and pass input by hand, but you cannot receive a real webhook call and a schedule will never fire.
On staging today you can, using the enabled toggle in the header. This epic removes that toggle deliberately, because enablement becomes a consequence of the lifecycle, and that is the right call. But it removes it everywhere, and in a sandbox nothing replaced it. That is a capability people have now and would lose, which is not something we should ship.
Why this is small
The state we want already exists and is already permitted. A live workflow inside a sandbox stays editable, deliberately: the editing rule reads that a live workflow is read-only only on its own project. So "on, and still being worked on" is a designed state for a sandbox. There is simply no way to reach it from the UI.
So this is a button, not a new concept, and not a new per-trigger mechanism.
What to build
One control in the sandbox header that turns the sandbox's workflow on and off, using the same lifecycle transitions the parent uses.
Copy needs deciding. "Go live" is wrong here: nothing is going into production, the workflow starts answering on the sandbox's own URL. Something closer to the sense of turning the sandbox on.
Two things that are already safe and need no work. A sandbox webhook answers on a URL namespaced by its own project and unique within it, so it can never collide with the parent's live endpoint. And a sandbox that is on behaves exactly as any enabled workflow does today, which is the parity we are restoring rather than new behaviour.
While we are here, delete the trigger enabled control component. It was built for a footer the inspector rewrite removed, nothing renders it, and this issue makes it unnecessary rather than something to re-home.
Worth knowing, not in scope
A sandbox runs with the parent's real credentials, so turning it on means a real request can write to the production system it was cloned from. That is #4860 and it is the thing that makes this safe to use, but it is not a reason to hold this.
Turning a workflow on outside the lifecycle also skips the activation limit that going live respects. Worth confirming whether that matters, since this route goes through the lifecycle and would respect it.
Acceptance criteria