What are the trade-offs of moving orchestration from an OmniScript into an Integration Procedure?
Suggested answer
The performance case is strong, but it is not free.
1. Gains: one round trip instead of several; reusability across OmniScripts, FlexCards and external callers; a single place for error handling; the ability to use looping, caching and conditional execution that the client cannot do efficiently; and less data crossing the wire because the Response Action returns only what the caller needs.
2. Costs: the logic is now further from the screen, so debugging spans two components; intermediate values that were visible in the OmniScript data JSON are no longer on the client; and a change to the Integration Procedure affects every consumer, so it needs versioning discipline and regression testing.
3. The boundary that works: the OmniScript owns everything that depends on what is currently on screen; the Integration Procedure owns everything that happens between the user pressing a button and the answer coming back.
4. A practical caution: an Integration Procedure that has grown to forty elements with deep nesting is harder to maintain than the four actions it replaced. Split it, or move the genuinely complex part into Apex that the procedure calls.
Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.
Community comments (0)
No comments yet.
Sign in or create a free account to add a comment. Comments are moderated before they appear.