---
title: "Filtering"
description: "Learn more about how to configure your SDK to filter events reported to Sentry."
url: https://docs.sentry.io/platforms/powershell/configuration/filtering/
---

# Filtering | Sentry for PowerShell

When you add Sentry to your app, you get a lot of valuable information about errors and performance. And lots of information is good -- as long as it's the right information, at a reasonable volume.

The Sentry SDKs have several configuration options to help you filter out events.

We also offer [Inbound Filters](https://docs.sentry.io/concepts/data-management/filtering.md) to filter events in sentry.io. We recommend filtering at the client level though, because it removes the overhead of sending events you don't actually want. Learn more about the [fields available in an event](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/).

## [Filtering Error Events](https://docs.sentry.io/platforms/powershell/configuration/filtering.md#filtering-error-events)

Configure your SDK to filter error events by using the `BeforeSend` callback method and configuring, enabling, or disabling integrations.

### [Using `BeforeSend`](https://docs.sentry.io/platforms/powershell/configuration/filtering.md#using-before-send)

All Sentry SDKs support the `BeforeSend` callback method. Because it's called immediately before the event is sent to the server, this is your last chance to decide not to send data or to edit it. `BeforeSend` receives the event object as a parameter, which you can use to either modify the event’s data or drop it completely by returning `null`, based on custom logic and the data available on the event.

A `Func<SentryEvent, Hint, SentryEvent?>` can be used to mutate, discard (return null), or return a completely new event.

```powershell
Start-Sentry {
    $_.Dsn = 'https://key@127.0.0.1/1'

    # Capture all events in BeforeSend callback & drop them.
    $_.SetBeforeSend([System.Func[Sentry.SentryEvent, Sentry.SentryEvent]] {
            param([Sentry.SentryEvent]$event_)
            
            if ($null -ne $event_.Exception -and $event_.Exception.Message.Contains("Noisy Exception"))
            {
                return $null # Don't send this event to Sentry
            }
            
            return $event_
        });
}
```

Note also that breadcrumbs can be filtered, as discussed in [our Breadcrumbs documentation](https://docs.sentry.io/product/error-monitoring/breadcrumbs.md).

## [Filtering Transaction Events](https://docs.sentry.io/platforms/powershell/configuration/filtering.md#filtering-transaction-events)

To prevent certain transactions from being reported to Sentry, use the `TracesSampler` or `BeforeSendTransaction` configuration option, which allows you to provide a function to evaluate the current transaction and drop it if it's not one you want.

### [Using `TracesSampler`](https://docs.sentry.io/platforms/powershell/configuration/filtering.md#using-traces-sampler)

**Note:** The `TracesSampler` and `TracesSampleRate` config options are mutually exclusive. If you define a `TracesSampler` to filter out certain transactions, you must also handle the case of non-filtered transactions by returning the rate at which you'd like them sampled.

In its simplest form, used just for filtering the transaction, it looks like this:

```powershell
Start-Sentry {
    $_.TracesSampler = [System.Func[Sentry.TransactionSamplingContext, System.Nullable`1[System.Double]]] {
        param([Sentry.TransactionSamplingContext]$context)

    if (/* make a decision based on `samplingContext` */) {
      # Drop this transaction, by setting its sample rate to 0%
      return 0
    } else if (/* ... */) {
      # Override sample rate for other cases (replaces `options.TracesSampleRate`)
      return 0.1
    }

    # Can return `null` to fallback to the rate configured by `options.TracesSampleRate`
    return $null
    }
}
```

It also allows you to sample different transactions at different rates.

If the transaction currently being processed has a parent transaction (from an upstream service calling this service), the parent (upstream) sampling decision will always be included in the sampling context data, so that your `TracesSampler` can choose whether and when to inherit that decision. In most cases, inheritance is the right choice, to avoid breaking distributed traces. A broken trace will not include all your services. See [Inheriting the parent sampling decision](https://docs.sentry.io/platforms/powershell/configuration/sampling.md#inheritance) to learn more.

Learn more about [configuring the sample rate](https://docs.sentry.io/platforms/powershell/configuration/sampling.md).

### [Using `BeforeSendTransaction`](https://docs.sentry.io/platforms/powershell/configuration/filtering.md#using-before-send-transaction)

A `Func<SentryTransaction, Hint, SentryTransaction?>` can be used to update the transaction or drop it by returning `null` before it gets sent to Sentry. For example:

```powershell
Start-Sentry {
    $_.Dsn = 'https://key@127.0.0.1/1'

    # Add this to the SDK initialization callback
    $_.SetBeforeSendTransaction([System.Func[Sentry.SentryTransaction, Sentry.SentryTransaction]] {
            param([Sentry.SentryTransaction]$sentryTransaction)

            # Modify the transaction
            if ($sentryTransaction.Operation -eq 'http.server')
            {
                return $null; # Drop the transaction by returning null
            }

            return #sentryTransaction;
        });
}
```