{"_id":"54ecf790172d6b2b003b317a","user":"54e3d35e464a9c3700f7ca7f","category":{"_id":"54e68328154f8e0d0007b55c","project":"5476bf0f817e8d080031f988","version":"5476bf10817e8d080031f98b","__v":8,"pages":["54e68e63a43fe13500db387a","54e68e98bdcbdc21000d55e6","54e6ca051415460d009fc118","54ecf59b172d6b2b003b3178","54ecf790172d6b2b003b317a","54eec2f35bf74a0d00ef4063","56d10611376b040b005b3135","56e36cf4f7d7a71700234792"],"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-02-20T00:43:20.640Z","from_sync":false,"order":3,"slug":"design-rules-limitations","title":"Developing on Transcriptic"},"parentDoc":null,"project":"5476bf0f817e8d080031f988","version":{"_id":"5476bf10817e8d080031f98b","__v":17,"project":"5476bf0f817e8d080031f988","createdAt":"2014-11-27T06:05:04.263Z","releaseDate":"2014-11-27T06:05:04.263Z","categories":["5476bf10817e8d080031f98c","5477c46cf3736008009e9eb5","5477c474f3736008009e9eb6","5477c47ef3736008009e9eb7","5477c48ff3736008009e9eb8","5477c4948deb230800808bf0","54e68328154f8e0d0007b55c","54e90194c8e0c00d007ac061","54eed2275bf74a0d00ef4076","54f7a7be0a3cbb0d00d666fb","559b0ebf7ae7f80d0096d871","55d697f9ae529e0d00d34f03","562d4dcc8c6e5a0d00d6ed1d","562e591c4376430d006f17e0","568f0e73bdb9260d00149d8c","5719542aac1e2e0e001834c6","57a14a8ed778850e0047e230"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"__v":3,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-02-24T22:13:36.783Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"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.\n\nIn 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.\n\nIf you have a use that requires branching logic at a time-critical step, send an email to [team:::at:::transcriptic.com](mailto:team@transcriptic.com) 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.","excerpt":"","slug":"branching-logic","type":"basic","title":"Can I have branching logic in my protocol?"}

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 [team@transcriptic.com](mailto:team@transcriptic.com) 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.