Start a conversation

Fix: “Too many future calls” Error During Subscription Generation on Reused Opportunity/Solution (R37 / cssmgnt 37.0)

Contents

Overview

You may see the error message “Too many future calls error in apex job for subscription generation” when attempting to regenerate an order/subscription on the same Opportunity/Solution (commonly in MACD basket scenarios).

This has been observed in R37 (cssmgnt 37.0 / Solution Management) and is caused by a data-state conflict: one or more related csord__Solution__c records are already marked active (cssdm__active__c = TRUE) from a prior generation attempt. When the process is repeated, the post-order-generation subscription-linking step (for example, linkSubscriptions) can cascade into a Salesforce governor limit failure (“too many future calls”).

Solution

Error Message

“Too many future calls error in apex job for subscription generation”

When This Happens

  • Subscription generation succeeds on the first attempt, but fails on a second (or later) attempt when regenerating on the same Opportunity/Solution.
  • Commonly associated with generating an order multiple times for the same Solution (often in MACD basket flows).
  • Observed in R37 / cssmgnt 37.0, where a behavior change around the subscription-linking API has been noted.

Root Cause (Confirmed)

The Solution record you are generating on is already marked active:

  • Object: csord__Solution__c
  • Field: cssdm__active__c is TRUE

Re-running order/subscription generation against the same Solution can leave data in a state that triggers subscription-linking logic to fail, surfacing as a governor-limit style failure (“too many future calls”) in the Apex job.

Resolution (Data Remediation)

Important: This updates data on managed-package objects/fields. Apply changes in a sandbox first and follow your organization’s change control practices.

  1. Identify the affected Solution record(s)

    Run a SOQL query to find Solutions tied to the same main product used by the Opportunity/Solution you are regenerating:

    SELECT Id, cssdm__replaced_solution__c, cssdm__main_product__c, CreatedDate, cssdm__active__c
    FROM csord__Solution__c
    WHERE cssdm__main_product__c = '<main_product_guid>'

    Replace <main_product_guid> with the cssdm__main_product__c value for the Solution involved in your regeneration attempt.

  2. Revert the Solution fields to a pre-regeneration state

    For the identified csord__Solution__c record(s):

    • Set cssdm__active__c back to the appropriate value for your scenario (commonly reverting from TRUE to FALSE to allow regeneration).
    • Review cssdm__replaced_solution__c and revert/clear it as appropriate to restore the correct relationship state (this depends on how your Solution replacement flow is intended to work).
  3. Retry subscription generation

    Re-run the order/subscription generation on the same Opportunity/Solution after the field updates.

How to Verify the Fix

  • The subscription generation job completes without throwing “Too many future calls…”.
  • A new subscription/order output record is created as expected (confirm using your normal functional checks for the generation flow).
  • Re-running the same scenario should no longer fail immediately due to the Solution being pre-marked active.

Prevention / Operational Guidance

  • Avoid repeatedly generating orders for the same Solution without resetting the underlying Solution state (especially during investigation/testing loops).
  • If repeated regeneration is required for testing, document a repeatable “reset” procedure for the relevant Solution fields in your sandbox.

Frequently Asked Questions

1. How do I know this is the same problem?

You see the exact message “Too many future calls error in apex job for subscription generation”, and it typically happens on a second (or later) regeneration attempt on the same Opportunity/Solution after a prior attempt already created subscription-related records.

2. What data should I check first?

Check csord__Solution__c for the Solution tied to the Opportunity and confirm whether cssdm__active__c is already TRUE. If it is, identify all Solutions for the same cssdm__main_product__c and review cssdm__replaced_solution__c as well.

3. Is this a “stuck job” or Batch Engine problem?

Not typically in this scenario. When the first retry succeeds and the second fails, it strongly suggests a data/automation state change between attempts rather than an engine backlog. Focus on the Solution record state (cssdm__active__c) and regeneration behavior for the same Solution.

4. What if I revert cssdm__active__c and it still fails?

Capture the failing Apex job entry and logs for the run and re-check:

  • Whether multiple csord__Solution__c records exist for the same cssdm__main_product__c and need consistent field states
  • Whether cssdm__replaced_solution__c relationships are left in an unexpected state after the first generation attempt

If it continues, further investigation is required into what automation runs post-generation in your org for that object graph.

5. Does version matter?

This behavior was observed in R37 / cssmgnt 37.0 in the described case. If you’re on a different version, the same symptom may still occur, but the exact post-generation linking behavior can vary—confirm the Solution state and reproduce in a sandbox.

Choose files or drag and drop files
Was this article helpful?
Yes
No
  1. Matej Storga

  2. Posted

Comments