InsProductService getRatedProducts Limitations Explained

The InsProductService rating bottleneck

If you build on the Salesforce Industries (formerly Vlocity) Insurance product model, InsProductService.getRatedProducts is the method your quoting and underwriting runs through. It is the programmatic door into the Product Engine: hand it a set of products and it returns pricing and rating results. Push real volume through it and the performance constraints turn up fast enough to cripple a complex implementation.

The core limitations

getRatedProducts is synchronous and CPU-hungry. It executes rules, hits calculation matrix lookups, and evaluates attributes, so the deeper your product model, the more it costs you.

1. Payload size

Pass a long list of product IDs and the serialization and deserialization overhead, on top of the calculation engine logic underneath, can trip heap size limits. A rating procedure that depends on dozens of attributes expands its memory footprint exponentially.

2. Governor limits

getRatedProducts usually runs inside a synchronous transaction, an LWC controller call or a trigger, so it competes for the same Apex CPU time as the rest of your application. In complex orgs, large rating requests regularly exceed the 10,000ms CPU limit.

3. Execution scope

The service is designed for real-time interaction and has no native batch support. Loop through hundreds of products with getRatedProducts in a single transaction and you will get a LimitException.

Optimizing your input

The fix starts with asking for less. Stop requesting everything and request precisely what the rating engine needs.

Minimize attribute context

Send only the attributes the engine needs to compute the final price. Every extra one you pass adds calculation complexity.

// Optimized Input Map for InsProductService
Map<String, Object> inputMap = new Map<String, Object>();
inputMap.put('productIds', new List<String>{'01t...'});
inputMap.put('effectiveDate', Date.today());

// Pass only essential state
Map<String, Object> context = new Map<String, Object>();
context.put('Attribute', new Map<String, Object>{ 'Age' => 35, 'Region' => 'US-East' });
inputMap.put('context', context);

// Call the service
Map<String, Object> outputMap = new Map<String, Object>();
Map<String, Object> options = new Map<String, Object>();

InsProductService.getRatedProducts(inputMap, outputMap, options);

Cached lookups

Calculation matrices that rarely change should be cached at the platform level. When a getRatedProducts call is failing, audit the matrix lookup complexity inside the rating procedure. Repeated disk I/O for matrix data is one of those costs nobody sees until they profile for it.

When to pivot: alternatives for scale

When the requirement outgrows a synchronous getRatedProducts call, quoting a bulk list of hundreds of products for instance, the logic has to move out of the synchronous request-response cycle.

The asynchronous pattern

Use a Queueable Apex job or a Batch process that calls getRatedProducts in smaller, isolated chunks. One big request then cannot consume every governor resource available.

public class RatingQueueable implements Queueable {
    private List<Id> productIds;
    
    public void execute(QueueableContext qc) {
        // Process products in chunks of 5 to stay under limits
        for (Id prodId : productIds) {
            // Call InsProductService logic here
        }
    }
}

Off-platform rating

At extreme scale, rating thousands of variations per minute, the Salesforce Product Engine is probably the wrong tool. Push the heavy calculation out to an external service, a dedicated microservice or a high-performance calculation engine, and bring the results back into Salesforce through the API.

Best practices for architecture

Four habits keep an implementation performant.

• Profile the service. Use the Salesforce Developer Console or a monitoring tool such as the Vlocity Performance Profiler to track the CPU time your rating procedures consume.
• Validate inputs before the call. Null or empty values in the input map make the service error out or fall back to expensive default logic.
• Test with data volume. A unit test against one product proves nothing. Write performance test classes that mimic peak expected usage so you find the CPU ceiling before production does.
• Keep procedures lean. The logic inside your Rating Procedure matters as much as the calling method, so tune the Calculation Matrices to scan fewer rows.