---
schema_version: "1"
id: 438dbc7124b11122206b3a4a1fbddf583a14a423e5080384ee240409ad4fc1aa
title: Best Practices for Investigating Report Anomalies
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/xcloud/264-0-0/real_time_em_threat_detection_bestpractices.md
canonical_url: https://help.salesforce.com/s/articleView?id=xcloud.real_time_em_threat_detection_bestpractices.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 687c06db9bf02e63faaec2bbb2e4dcba2a649d5ab499f3cbe1b4ba15a4f3b802
description: Keep these tips and best practices in mind when you investigate unusual user behavior. They can help you find the information you require to make a well informed conclusion about your data’s safety.
products:
  - Salesforce Platform
  - Cross Cloud
release: "264"
---
# Best Practices for Investigating Report Anomalies

Keep these tips and best practices in mind when you investigate unusual user behavior. They can help you find the information you require to make a well informed conclusion about your data’s safety.

### Required Editions

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition">
      <colgroup>
        <col>
      </colgroup>
      <tbody>
        <tr class="">
          <td class="slds-cell-wrap" style="vertical-align:top;">Available in both Salesforce Classic (not available in all orgs) and Lightning
            Experience.</td>

        </tr>
        <tr class="">
          <td class="slds-cell-wrap" style="vertical-align:top;">
            <p>Available in: <strong>Enterprise</strong>, <strong>Unlimited</strong>, and <strong>Developer</strong>
              Editions</p>
            <p style="margin-bottom:0;">Requires Salesforce Shield or Salesforce Event Monitoring add-on
              subscriptions.</p>
          </td>

        </tr>
      </tbody>
    </table>

Identify the involved user.

Keeping customer privacy in mind, we cannot access customer data or any data inside the reports. As a result, we can provide only the user ID of the user who generated the report that is marked as an anomaly. Use this user ID to locate the username and other details about the person associated with the detection event.

Field: ReportAnomalyEvent.UserId

Use the timestamp.

Our detection model already considers various features derived from the timestamp to determine report generation activity as anomalous or not. You can use this timestamp to narrow down the set of events you must review. You can also determine if the time of report generation was unusual for the user who generated the report.

Field: ReportAnomalyEvent.EventDate

Use contributing factors as a guide.

The contributing factors JSON output shows the features in descending order of contribution. As you start your investigation into the event logs, keep an eye out for the top contributing features. If these features look unusual, they can provide more evidence that confirms the anomaly or even indicate a possible data breach.

Field: ReportAnomalyEvent.SecurityEventData

Consider the anomaly in the context of the user's typical behavior.

Using the ReportAnomalyEvent field values, try to determine whether the user activity within the detection event is typical for the user. For example, consider if it's typical for a user to generate a report from the IP address provided.

Field: ReportAnomalyEvent.SourceIp

Consider the size of the report.

We consider the size of the report to determine if the report generation was anomalous. A user generating a larger report than usual can indicate an unauthorized data export attempt. For example, an attacker obtained unauthorized access to the user's account and exfiltrate as much data as possible before losing access. Alternatively, it could mean that a disgruntled employee is exfiltrating data for use beyond the needs of the employer.

Field: ReportAnomalyEvent.SecurityEventData (specifically the rowCount feature name)

Not all anomalies are malicious.

While some anomalies can indicate a malicious intent, other anomalies can be legitimate but unusual. Our detection model can produce detection events that are unusual but not malicious. For example, if an employee gets promoted to a new role and starts generating larger reports, our model can flag this behavior as anomalous.

#### See Also

- [Training and Inference Steps](https://help.salesforce.com/s/articleView?id=xcloud.real_time_em_threat_detection_steps.htm&release=264.0.0&type=5 "Similar to other machine learning or statistical models, our detection model has a familiar two-step process: a training step and an inference or detection step. As a customer, you don't perform either of these steps—Salesforce performs them for you. You only review the detection events generated by our detection mode and take further action if necessary.")
- [_Platform Events Developer Guide_: ReportAnomalyEvent](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_reportanomalyevent.htm)
- [_Platform Events Developer Guide_: ReportEvent](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_reportevent.htm)