Can I have branching logic in my protocol?

Because protocols are just data, logic must be implemented on the client side (in your code). Since runs aren't executed immediately after they're submitted - there may be an accumulation window or planning delays, for example - you need to think about how to break up your protocol into components.

In general, if you need branching logic in the middle of a protocol (e.g., atomically transforming one resource into another or gathering data), it's a sign something was poorly designed. Ideally protocols should be linear workflows whose only logic may be assertions about whether a step fails, but shouldn't otherwise have multiple destinies.

If you have a use that requires branching logic at a time-critical step, send an email to [email protected] to discuss. In the future we may expose mechanisms for behaviors such as flagging a run as "likely to have immediate children" but right now it's best if you discuss your application with us to ensure your requirements get met.