You do not have to use the Publish Gate right now — a workflow without it publishes fine. It remains the recommended way to keep builds and test runs from firing real actions, and the rest of this page describes how it behaves when you do use it.
Publishing
The Publish Gate piece
The safety piece that keeps real actions from firing while an agent is being built or tested.
What it is
gravity-piece-publish-gate is a first-party Gravity piece with a single action, "Continue Only If Published". When the step runs, it checks how the flow is executing. The steps below it run only when the automation is published and enabled and is executing its published version, that is, a real run of a live agent. In every other situation (building, draft preview, test runs), the gate stops the run cleanly and reports that the steps after it were skipped.
Currently optional
Design properties worth knowing:
- It cannot be bypassed. The piece hides the "continue on failure" and "retry on failure" options, so a failed check can never fall through to the real actions.
- The platform forces the strict check at publish and at clone time, so even flows published before the current version behave safely.
How and where to use it
Never edit your exported JSON by hand
Add the gate only from the step picker inside the Activepieces flow editor. Do not paste the step (or anything else) into an exported JSON file — hand-edited exports are missing internal fields the editor writes, and they fail to import when you upload them here. If the piece is not available in your Activepieces workspace, simply build without it: the gate is optional, and the platform enforces the same safety behaviour automatically when your agent is published.
Place the gate after the trigger and the content-preparation steps, and before every step that has an external effect: sending an email, posting to a social network, writing to a spreadsheet, calling an external API on the user's behalf. Everything below the gate is skipped automatically while the flow is being built or tested, so a builder can iterate freely without spamming real channels.
Example layout from a real agent: Web Form trigger, then Generate Image, then Continue Only If Published, then Respond on UI and Send Message to a Channel. The image generation runs during tests; the delivery steps only run on the live agent.
One exception to note
The pre-publish end-to-end test that gates every publish runs the flow as a genuinely published and enabled automation, so the gate passes and the real actions fire exactly once. This is intentional. It is how the platform verifies the agent actually works before it goes live.