Skip to main content

Blueprint Lifecycle

A blueprint moves through several stages from initial creation to live automation. Understanding this lifecycle helps you build, test, and release automations confidently.

Lifecycle stages​

Draft  -->  Validate  -->  Run Once  -->  Publish  -->  Live
  ^                                                      |
  |____________________  Pause / Edit  __________________|

Draft​

When you create or edit a blueprint, you're working on a draft. Drafts are your in-progress work:

  • Edit freely without affecting anything live
  • Save often to preserve your changes
  • Drafts are private to the workspace -- they don't affect published workflows

Validate​

Before you can run or publish a blueprint, it must pass validation. The editor checks for:

  • Missing required fields on any node
  • Invalid expressions (syntax errors, broken references)
  • Missing credentials on integration nodes
  • No trigger (every blueprint needs exactly one trigger)

Validation issues appear as indicators on the affected nodes. Fix all issues before proceeding.

Run once (testing)​

Run once lets you execute the blueprint with test data without publishing it. This is your primary testing tool:

  1. Click Run once in the toolbar
  2. Provide test input data (for API triggers) or let the trigger simulate an event
  3. Watch the execution in real time
  4. Inspect each node's input and output in the execution report

Use Run once repeatedly as you build. It's safe -- it won't affect your published version.

tip

Always test in your staging workspace with test data. Run once executes the blueprint for real, including sending actual messages and making real API calls.

Publish​

When your blueprint is tested and ready, publishing creates an immutable version:

  • A new version number is assigned
  • The published version becomes the live version
  • Incoming triggers will execute this version
  • Previous versions are preserved in the version history

Think of publishing like creating a release. Review your changes and test thoroughly before publishing.

Live​

A published blueprint is live -- it actively processes incoming triggers. When a trigger fires (API call, attribute change), Orqio creates a workflow execution from the live version.

Pause​

You can pause a live blueprint to temporarily stop it from processing triggers:

  • No new executions will start
  • Already-running executions will complete
  • The blueprint remains published -- you can resume it at any time

Pausing is useful for maintenance, debugging, or when you need to temporarily stop an automation without deleting it.

Version history​

Every time you publish, Orqio saves the previous version. You can:

  • View past versions to see what changed
  • Restore a previous version if something goes wrong
  • Compare versions to understand the evolution of a blueprint

This gives you a safety net: if a new version causes problems, you can quickly roll back.

  1. Build in staging -- create and iterate on your blueprint in a non-production workspace
  2. Validate -- fix all validation issues
  3. Run once -- test with realistic data, inspect results
  4. Iterate -- repeat steps 2-3 until the blueprint works correctly
  5. Publish in staging -- make it live in staging and monitor
  6. Recreate in production -- build the same blueprint in your prod workspace with production credentials
  7. Publish in production -- go live and monitor the first few executions

Best practices​

  • Save drafts frequently. Don't lose work.
  • Test before every publish. Run once with realistic data to catch issues early.
  • Publish deliberately. Treat each publish as a release, not a save.
  • Use version history. If something breaks, restore the previous version quickly.
  • Pause before editing live blueprints. Pause the blueprint, make your changes, test, and publish the new version.