Suggested answer

This is the single most common design question in OmniStudio work, and the answer is usually about round trips, reusability and maintainability rather than raw capability.

1. Keep it in the OmniScript when the logic is about the user's experience — showing or hiding a Step, validating a field, setting a value the user will see next. Anything that needs the current screen state belongs here.
2. Move it to an Integration Procedure as soon as two or more server calls have to happen together, when the same sequence is needed by more than one consumer, or when the intermediate data is of no interest to the client. One call instead of four is usually the biggest single performance win available.
3. Drop to Apex only when the declarative tools genuinely cannot express the requirement: complex algorithms, bulk processing patterns, callouts with unusual authentication, or operations that need explicit transaction control. Expose it through an invocable or remote class so the Integration Procedure stays the orchestrator.
4. The trade-off to state explicitly: declarative components are easier for admins to maintain and migrate but harder to unit test; Apex is testable and precise but concentrates knowledge in a smaller group. Most teams keep the ratio deliberately weighted towards declarative and treat new Apex as something that needs justifying.

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.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.