Clarification on CI360 Exclusion Event Occurrence Behavior for Real-Time Messaging Tasks

[subbu005]

Hi Team,

I need clarification regarding how Event Occurrence-based Exclusions work in SAS CI360 Real-Time Messaging tasks.

Business Requirement:
We want to suppress API/message execution if a customer has already performed more than 5 qualifying transactions within a rolling 24-hour window.

Example:

• Allow first 5 qualifying transactions
• Suppress from 6th transaction onward
• Customer should become eligible again after the rolling window expires

Current Configuration:
Task Type: Real-Time Messaging Task

Exclusion Configuration:

• Event: ESP
• Occurrences: > 5
• Date Range: Relative
• Time Period: Previous 1 day
• Attribute Condition: TranAmt > 50

Observed Behavior / Doubts:

1. Does CI360 evaluate occurrence counts based on:
   • historical matching events only?
   • or current incoming event + historical events?
2. Are occurrence counts evaluated per:
   • Customer + Event?
   • or Customer + Event + Task ID?
3. If a new task is created using the same event, will old historical event occurrences still be considered?
4. In UAT, we continuously reuse the same customer IDs for testing. Could previously processed matching events from earlier tasks or tests affect exclusion evaluation in newly created tasks?
5. If exclusion threshold is already satisfied due to historical matching events, is it expected that the first incoming event itself gets suppressed?
6. Is there any way to reset or isolate occurrence history per task during UAT testing?

Observed Example:
When attribute condition TranAmt > 50 is configured, sometimes API calls are immediately suppressed even for newly created tasks. However, after removing attribute conditions, some API calls are triggered before suppression starts.

We are trying to understand:

• how CI360 internally evaluates occurrence history
• how rolling windows are calculated
• whether exclusion evaluation is task-specific or event-specific

Please find the attachment of screent of ci360

Could someone please clarify the expected behavior and best practice for implementing transaction-frequency suppression in CI360 real-time tasks?

Thanks!