Contents
- Overview
- Solution
- How to Verify the Fix
- Prevention / Operational Guidance
- Frequently Asked Questions
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__cisTRUE
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.
-
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 thecssdm__main_product__cvalue for the Solution involved in your regeneration attempt. -
Revert the Solution fields to a pre-regeneration state
For the identified
csord__Solution__crecord(s):- Set
cssdm__active__cback to the appropriate value for your scenario (commonly reverting fromTRUEtoFALSEto allow regeneration). - Review
cssdm__replaced_solution__cand revert/clear it as appropriate to restore the correct relationship state (this depends on how your Solution replacement flow is intended to work).
- Set
-
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__cfor the Solution tied to the Opportunity and confirm whethercssdm__active__cis alreadyTRUE. If it is, identify all Solutions for the samecssdm__main_product__cand reviewcssdm__replaced_solution__cas 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__cand it still fails? -
Capture the failing Apex job entry and logs for the run and re-check:
- Whether multiple
csord__Solution__crecords exist for the samecssdm__main_product__cand need consistent field states - Whether
cssdm__replaced_solution__crelationships 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.
- Whether multiple
- 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.
Matej Storga
Comments