Orchestration

Procly is software that orchestrates Stages. Orchestration means deciding the order, timing, dependencies, and what happens if something changes or goes wrong. It turns a bunch of individual Stages into a single, smart process.

Procly orchestrates Tasks to run in Stages. It follows rules about when Stages can or should start for a Task, or be blocked from starting until a condition is met. Tasks can be running in multiple Stages at the same time, and can be run in parallel or sequentially. A Task can also be moved between processes.

Control flow: Moving Tasks between Processes

A Task is meant to be in one process at a time. However, there are times when you need to move a Task between processes. For example, you might want to move a Task from one process to another because the first process runs into an exeptional case that the first process does not handle. Procly does not try to create the entire flow chart of a workflow in one big circuit diagram. You create a flat, linear pipeline of Stages that usually represents the common/happy path of a workflow. Then you can add additional paths for exceptional or additional cases.

An example of this would be a process that is used to intake a new client for a service business. The common path would be to collect their basic information, confirm eligibility, and schedule their first appointment. However, if the client does not meet certain criteria (for example, location, budget, or required documentation), you might want to move the Task to a different branch of the process for follow-up, referral, or rejection. Additionally, you might want to add a process that filters for spam and qualifies the customer before moving them to the second process to handle intake.

This is a powerful way to model complex workflows for many reasons:

• Intuitive comprehension and reasoning — Flat, linear Stage sequences represent the primary happy path clearly, while exceptional cases are handled by routing Tasks to separate Processes. This avoids bloated, spaghetti-like flowcharts and makes the overall orchestration far easier to understand, explain, and reason about at any scale.
• Granular security and data privacy controls — Permissions can be enforced precisely at the Process or Stage level, isolating sensitive data and actions so only authorized users (human or automated) gain access — preventing broad exposure across the entire orchestration.
• Team and organizational autonomy (swim-lane style) — Each team or sub-organization can own and evolve their own small Processes independently. Task handoffs between Processes enable clean delegation and reduce cross-team coordination overhead — true decentralized orchestration.
• Effective isolation for testing — Small Processes and individual Stages are straightforward to test in isolation (unit-style) or as part of controlled end-to-end scenarios, with minimal dependencies on the broader system.
• Built-in scalability — Independent Processes and parallel-capable Stages allow horizontal scaling of specific workflow segments (e.g., high-volume intake vs. low-volume exceptions) without re-architecting the entire orchestration.
• Strong auditability and traceability — Discrete Processes and explicit Task movements create natural audit trails with clear boundaries, handoffs, and state transitions — making compliance reviews, debugging, and historical analysis much more reliable.
• Safe, low-risk versioning and updates — You can version and deploy individual Processes or Stage sequences independently. Changes to one path (happy or exceptional) don't force redeployment of the entire workflow.
• Rapid iteration and safe experimentation — Modular Processes make it simple to prototype alternative paths, add conditional branches, or test new logic by routing a subset of Tasks to experimental Processes with minimal production impact.
• Native support for A/B testing and controlled rollouts — Route portions of Tasks to variant Processes (e.g., new intake logic vs. legacy) side-by-side, compare outcomes, and gradually shift traffic — all within the same orchestration framework.
• Low-risk rollback and recovery — When issues arise, revert or reroute just the affected Process(es) — restoring the Task to a prior or fallback Process — instead of halting or rolling back the entire workflow.