@GeorgeH17281400 I suggest opening a support ticket and attaching details of the alerts. Depending on how the application is built, there might not be a straightforward answer. Would it be helpful to have a Ruleset name included in the alert?

@GeorgeH17281400

This isn’t a product defect PDC tags an alert with the application from the requestor’s active access group; if the session never switches, it falls back to the operator’s default, which is why you’re seeing the wrong app. The fix is to ensure the right application context is set before work starts: set the intended access group on the portal/login, or explicitly switch application at the start of the flow (use the Switch Application action or a small utility that calls setApplicationByName). For background work, always set the access group on each Queue Processor, Job Scheduler, and Agent schedule (and in the Application rule’s “Access group for agents”). For services/listeners, use an authentication profile that resolves to an operator/access group for that specific app. Avoid multi-app “general” operators for automation; create per-app service accounts. After this, alerts will land under the correct application in PDC. If you want automatic cross-app detection, log an enhancement with Pega Support, but today it’s by design.

@GeorgeH17281400

Following the resolution of the INC-C52115 with Pega Support, here more details on the issue - We use DX APIs to access our platform. When a user have multiple AccessGroups, no matter under which application context the api call is made (.../app/xxxx/api/ ;.../app/yyyy/api/ ), all the alerts were logged under the default access group of the user. 

This is a Platform issue, and it will be fixed for new alerts in future versions: Pega Infinity '24.2.4, '25.1.2, '26.1