Considerations and Limitations for Rebate Management

Considerations for Rebate Management

• Rebate Management is supported only on desktop and mobile devices.
• Run data processing engine jobs sequentially when you schedule a flow with Data Processing Engine action elements. If you clone the predefined Run Rebate DPE Jobs flow, it’s automatically implemented.
• Predefined data processing engine jobs are designed to run for all active programs, payout periods, and rebate types for all active rebate program members. To run the data processing engine jobs for specific programs, periods, rebate types, or members, pass the specific records as inputs for the Run Rebate DPE Jobs flow.
• It’s recommended to not associate more than 10,000 rebate types with over 100 unique rebate type filters with a single Data Processing Engine definition. Check the Data Processing Engine Limits. Either associate the rebate types to multiple definitions or modify the inputs so that only a subset of program rebate types or payout periods is processed in a single run.
• You can configure up to 100,000 benefits for a rebate type. When uploading large volumes of data using Data Loader, it's recommended to use the serial concurrency mode to ensure consistent results. Serial concurrency mode for Bulk API jobs ensures that batches are processed one after another, in the order they are received, rather than in parallel. Internal validation has been performed with up to 10 benefits per rebate type. Using significantly more may impact processing efficiency and make it harder to trace payout calculation logic during analysis.
• You can’t create reports on transaction journal records for Experience Cloud users.
• If multiple benefits exist for a given rebate type, sort the underlying data by rebate type before uploading it using Data Loader.
• In a multicurrency setup, set the same default currency for the Integration User and the Data Processing Engine Writeback User profiles. If you aren’t using a data processing engine writeback user, use the same default currency for the System Administrator profile assigned to the Data Pipelines Base User permission set. The Rebate Management objects use multicurrency constructs in this manner.
  • Transaction Journal: Transactions can be recorded in the desired transaction currency.
  • Rebate Member Product Aggregate: When a data processing engine job runs to compute aggregates, the currency from the Transaction Journal is converted into the Integration User profile’s currency. Then, the amounts are stored in the aggregate object in the Writeback User profile's currency.
  • Program Rebate Type Payout Source: Payout sources are created in the aggregate row's currency code after benefit computations.
  • Program Rebate Type Benefit: In the benefit setup, the maximum and minimum values provided are considered to be in the currency of the aggregate row and are evaluated accordingly.
  • When creating a Transaction Journal in an org where both Rebate Management and Channel Partner Inventory Management are enabled:
    • Specify the Journal Type for Channel Partner Inventory Management. The Journal Type determines how the Transaction Journal is used within Channel Partner Inventory Management processes. If the Journal Type is left blank during creation, the system defaults the Usage Type to Rebates.
    • Configure DPE filtering on Status for Rebates Transaction Journals. Rebates DPEs do not automatically exclude records based on the Transaction Journal Status field. If customers intend to use the Status field (for example, Approved, Rejected, or Pending) to control which records generate aggregates or payouts, they must explicitly configure filters in the Rebates DPE definitions. For example, to ensure that only eligible records are processed and to exclude any status other than Approved (such as Pending or Rejected), include filter logic such as: TransactionJournal.Status = 'Approved'.
    • Review legacy records for compatibility. If existing Rebates Transaction Journal records default to a Pending status, note that DPEs do not filter by Status by default and will process all PoS transactions. Ensure that the appropriate DPE filter logic is configured so that the correct records are processed and unintended records are not included or excluded.

Rebate Management Limitations

• Data Processing Engine Limits
• Troubleshoot Data Processing Engine Issues
• Things to Keep in Mind While Using Batch Management
• Flow Limits and Considerations
• Get Member Details from Transaction Journals When Loyalty Management and Rebate Management Are Enabled

Note Data Processing Engine isn’t available in Government Cloud or Government Cloud Plus.

Rebate Management Guardrails

Set up and maintain a rebate program with processes that calculate rebate amounts and generate payouts for rebate program members. These processes typically handle large volumes of rebate transactions across programs, periods, and members.

• Set up and maintain a rebate program with processes that calculate rebate amounts and generate payouts for rebate program members. These processes typically handle large volumes of rebate transactions across programs, periods, and members.
• Rebate Management supports high data volumes through batch processing using Data Processing Engine (DPE) and Batch Management. The recommended data volume guardrails have been tested and designed for scenarios where rebate payouts are issued to program members based on defined rebate types and associated benefits. These guardrails support effective planning and help ensure reliable performance during implementation. They are not strict technical limits, and actual results may vary depending on data size, complexity, and configuration.
  

  Note The guardrails for processing specific transaction journal volumes remain consistent across industries. When applying these guardrails in a different industry, replace the Order object and its related considerations and assumptions with the object that generates transaction journals and ledgers in that context. The guardrails may vary depending on the complexity of the customer's requirements.
  To view Rebate Management licensing and packaging details, see here.

Guardrails for End-to-End Orchestration Using DPE

The following scenario outlines an internally tested orchestration flow where transaction journals are processed through a data processing engine.

• Scenario 1

  Org Data Summary: Active counts of various data objects

  Object	Count	Details
  Rebate Program	5,000
  Rebate Program Member	15,000	3 members per program (two-level hierarchy with a parent)
  Rebate Periods	60,000	12 monthly periods per program
  Rebate Type	30,000	6 rebate types per program
  Program Rebate Type Benefits	180,000	6 benefits per rebate type
  Rebate Filters	90,000	3 eligibility conditions per rebate type
  Transaction Journal	25 million	140 journals per member per period

  

  Note These limits were tested internally. For higher volumes, contact your Salesforce admin.

Execution Summary

• DPE Used: Aggregate By Member
• Rebate Types Processed: 30,000
• Filters Processed: 90,000
• Recipe Size: 799.1 KB
• Unique Filters: 200

Processing Summary: The table below shows the number of rows processed in this recipe.

Calculation: 10,000 rebate types × 90 transaction journals/member × 3 members/program × 12 periods/program

Note These limits were tested internally. If your data exceeds these volumes or dimensions, clone and split the DPE jobs. For example, split 10,000 rebate types across two jobs of 5,000 each. For help, contact your Salesforce admin.

Guardrails for Rebate Payout Calculations

Org Summary

• Aggregate Records: 18,000,000
• Payout Periods: 180,000

Execution Summary

Note

The numbers above reflect internal testing. Actual performance may vary based on the customer's environment, configurations, and customizations. For higher volumes, contact your Salesforce admin.

The default batch size for rebate payouts is 2,000 records. You can adjust it between 200 and 2,000 based on data volume and custom logic. Reduce the size if Apex limits are hit, and adjust only after evaluating system needs. For help choosing a batch size, contact your Salesforce representative.

Things to Consider When Choosing a Rebate Processing Method

When deciding how to process rebates, evaluate the following:

• Storage limits for involved objects. Use archiving where needed.
• Org resource usage during external API calls.
• Limits related to
  • Flows
  • Apex
  • APIs
  • Data Processing Engine

Best Practices

Use the following practices to stay within guardrails and avoid performance bottlenecks:

• Archive or purge Transaction Journal, Rebate Payout, Rebate Aggregate, and Rebate Payout Source records that you no longer require.
• Process batches using Rebate Program or Program Rebate Type filters.
• Use serial mode in Data Loader for high-volume benefit uploads.
• The default batch size for processing rebate payouts is 2,000 records. You can adjust this value between 200 and 2,000 records, depending on your customizations and data volume. If Apex governor limits are encountered due to customizations, consider reducing the batch size. Adjust the value only after assessing your data and processing requirements.