MACD Orchestration Errors Due to Incorrect Subscription Replacement Linkages

Problem

When attempting to push MACD (Move, Add, Change, Disconnect) orders to the E-Commerce and Abstraction layer using the Order API or Hermes API, the operation fails with one of the following orchestration errors:

MODIFY_ORCHESTRATION_ERROR: MACD Process not allowed, already posted

or

MODIFY_ORCHESTRATION_ERROR: MACD Process not supported for the given subscription

These errors prevent MACD orders from being processed and block change order workflows.

Root Cause

The issue occurs when the Replaced Subscription and Replacement Subscription fields are incorrectly configured or interchanged between the old and new subscription records.

CloudSense tracks the MACD chain through these two fields:
- Replaced Subscription: Points to the subscription that was replaced (the old subscription)
- Replacement Subscription: Points to the subscription that replaced it (the new subscription)

When these fields are swapped or incorrectly populated:
1. The E-Commerce layer cannot correctly identify the MACD chain
2. Validation logic fails because it detects an invalid subscription state (e.g., a subscription that appears to have already been processed for MACD)
3. The orchestration engine rejects the MACD request with one of the errors above

Common scenarios that cause this issue:
- Scenario 1: New subscription (created later) has its Replaced Subscription field pointing to the old subscription, while the old subscription (created earlier) has its Replacement Subscription field pointing to the new subscription (fields are swapped)
- Scenario 2: A subscription has been processed for MACD multiple times, creating a complex chain where the linkages are not correctly maintained
- Scenario 3: MACD cancellation followed by a new MACD on the same subscription, where the system incorrectly interprets the subscription as already having an active MACD

Resolution Steps

Step 1: Identify the Affected Subscriptions

1. Review the error message or orchestration logs to identify the subscription IDs involved in the failed MACD

2. Note the subscription IDs (e.g., SN-000279420, SN-000280815)

3. Determine which subscription is the "old" (replaced) and which is the "new" (replacement):

4. Check the Created Date & Time on each subscription record
5. The subscription created earlier is the old subscription
6. The subscription created later is the new subscription

Step 2: Review Current Field Values

1. Open both subscription records in Salesforce

2. Check the Replaced Subscription and Replacement Subscription fields on each record

3. Document the current values in a table:

1. Identify the problem:
2. In the example above, the fields are interchanged
3. The old subscription (SN-000279420) should have Replacement Subscription populated, not Replaced Subscription
4. The new subscription (SN-000280815) should have Replaced Subscription populated, not Replacement Subscription

Step 3: Correct the Field Values

The correct configuration should be:

To correct the values:

1. Open the OLD subscription record (created earlier):
2. Clear the "Replaced Subscription" field (set to blank)
3. Populate the "Replacement Subscription" field with the ID of the NEW subscription

4. Save the record

5. Open the NEW subscription record (created later):

6. Populate the "Replaced Subscription" field with the ID of the OLD subscription
7. Clear the "Replacement Subscription" field (set to blank)
8. Save the record

Step 4: Verify Service Record Linkages (If Applicable)

In some cases, the Service records may also have misaligned linkages. Check:

1. Open the Service records associated with the subscriptions

2. Check if Service records have similar "Replaced Service" and "Replacement Service" fields

3. If present, correct them using the same logic:

4. Old Service: Replacement Service = New Service ID, Replaced Service = BLANK
5. New Service: Replaced Service = Old Service ID, Replacement Service = BLANK

Step 5: Retry the MACD Order Push

1. Return to the Order API or Hermes API and retry the MACD order push

2. Monitor the orchestration logs to confirm the MACD process completes successfully

3. Verify in the E-Commerce layer that the order has been processed without errors

Verification

After correcting the field values:

1. Query the subscriptions to confirm the linkages:

SELECT Id, Name, CreatedDate, csord__Replaced_Subscription__c, csord__Replacement_Subscription__c
FROM csord__Subscription__c
WHERE Id IN ('a5WBm000001irxq', 'a5WBm000001lRhS')
ORDER BY CreatedDate ASC

1. Expected result:
2. Old subscription: csord__Replaced_Subscription__c = null, csord__Replacement_Subscription__c = [NEW_SUB_ID]

3. New subscription: csord__Replaced_Subscription__c = [OLD_SUB_ID], csord__Replacement_Subscription__c = null

4. Retry the MACD push and confirm it completes without orchestration errors

Prevention

To prevent this issue in future MACD workflows:

• Implement validation rules on Subscription records to ensure Replaced/Replacement fields are correctly populated during MACD processing
• Audit MACD chains regularly to identify any misaligned linkages before they cause orchestration failures
• Document MACD workflows to ensure all team members understand the correct field population logic
• Test MACD scenarios in sandbox environments after any package upgrades or data migrations
• Review custom code that creates or updates subscription records to ensure it correctly populates the Replaced/Replacement fields

Important Notes

• The Replaced Subscription and Replacement Subscription fields form a bidirectional link between old and new subscriptions
• The old subscription (created earlier) should point forward to the new subscription via Replacement Subscription
• The new subscription (created later) should point backward to the old subscription via Replaced Subscription
• If these fields are swapped, the MACD chain is broken and orchestration will fail
• This issue can affect multiple MACD scenarios: upgrades, downgrades, plan changes, and cancellations
• Always verify the Created Date & Time to determine which subscription is old and which is new
• If you have a complex MACD chain (multiple changes over time), verify the linkages for all subscriptions in the chain