What are the performance considerations when an OmniScript has many Steps and several server-side actions?
Suggested answer
Perceived speed in an OmniScript is dominated by how many server round trips the user waits through and when they happen.
1. Consolidate calls. Several Data Mapper actions firing in sequence should usually be one Integration Procedure call. Each separate action is a full client-to-server round trip.
2. Cache what does not change. Reference lookups that return the same data on every visit are strong candidates for input caching on the action, so navigating back and forth does not re-fetch.
3. Fetch late, not early. Loading everything on Step one makes the first screen slow and wastes calls for users who abandon. Retrieve data on the Step that needs it.
4. Prefer Turbo Extract for simple reads. Where a single sObject and no formulas are involved, the lighter Data Mapper type is measurably faster.
5. Do not block on work the user does not need. Logging, notification and analytics calls can be fired without waiting for a response.
6. Watch repeatable blocks. An action inside a repeatable block multiplies by the number of instances the user creates; move it server-side into a loop instead.
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.