Building
Testing and publishing
Verify success and failure paths before a release.
Test before publication
Check disconnected blocks, required fields, valid IDs, duplicate command names, Custom IDs and both outputs of conditions. Read validation messages as instructions about specific blocks, not as a reason to delete the whole flow.
Use preview for what it can prove
The preview/simulation helps check message layout and sample variable substitution. It cannot verify Discord permissions, live credentials, role hierarchy, network delivery or external side effects. A successful visual preview is not a deployment test.
Publish and observe
Save your intended changes, publish the bot's flows, and wait for a valid result. Start or reconnect as required. Invoke one real command/event and check expected behavior plus timestamped logs. Keep the previous known-good design or an export before a large change.
Test negative paths
Try a member without permission, a missing storage record, an empty optional option and an API error. The bot should explain a denial without exposing internal errors or secrets. Check duplicate clicks and cooldown behavior. Stop testing destructive moderation on real members: use a dedicated test setup.
Release notes
Write what changed, new settings/permissions and how to verify it. Saving, publishing and running remain distinct even after the first successful release.