import { Callout } from "zudoku/ui/Callout";

# 365 business Sanction Screen

`365 business Sanction Screen` checks persons and companies of political, criminal, or economic interest against sanction and PEP data sources, directly from Microsoft Dynamics 365 Business Central.

This page is the entry point for extending the app from your own extension. There are two ways to do that, and they solve different problems:

| You want to | Start here |
| --- | --- |
| Change what is screened, or skip a screening, for an entity the app already supports | [Extensibility Events](extensibility-events.mdx) |
| Screen an entity the app does not support - a table of your own, or a standard table that is not covered | [Sanction Screening Source](sanction-screening-source.mdx) |

## Dependency

Add a dependency to the `365 business Sanction Screen` app in the `dependencies` node of your `app.json`:

```json
    {
      "id": "41560e3b-51bf-4a0e-85a6-87280c6fe580",
      "name": "365 business Sanction Screen",
      "publisher": "365 business development",
      "version": "18.3.0.0"
    }
```

<Callout type="info" title="Which version you need">
The events have been available since 18.2. Adding a source of your own needs **18.3**: the screening methods a source implementation calls became public with that version.
</Callout>

## How the screening is put together

Four public objects carry the extension model. Knowing what each one is for makes both extension paths easier to follow.

| Object | Type | What it is for |
| --- | --- | --- |
| `bdev.Sanction Screening Source` | Enum (`5524070`), extensible | One value per screenable entity. **The value is the table id of the source table** - `18` for `Customer`, `23` for `Vendor`. The enum states which implementation screens it. |
| `bdev.ISanctionScreening` | Interface | What an implementation has to provide: screening one record, screening a batch, and answering questions about the last result. |
| `bdev.Sanction Screening Model` | Table (`5524070`), temporary | The data that is sent to the data sources: name, address, country, date of birth, registration numbers. An implementation fills it from its source record. |
| `bdev.Sanction Screen Integ.` | Codeunit (`5524125`) | The integration point: the events, and the screening methods an implementation calls. |

A screening always runs the same way, whichever entity it is for:

1. The implementation of the source builds a `bdev.Sanction Screening Model` record from the source record.
2. `OnAfterInitializeModelFromSource` lets other extensions add to it.
3. `OnBeforeMatchRecord` lets other extensions correct it, or skip the screening.
4. The data is sent to the data sources and the result is written to the screening log.
5. Matches are written as `bdev.OS Match Entry` records and can be cleared as false positives.

The screening log is the evidence an audit rests on - every screening ends up there, including the ones a source of yours performs. It is printed by the [audit report](../../en-us/365-business-sanction-screen/audit-report.mdx).

## What your own source gets for free

An entity you add through the enum is not a second-class citizen. Because the product iterates over the enum rather than over a fixed list:

- screenings of your entity appear in the **screening log** and in the **audit report**, with the full screening context;
- the **gap analysis** of the audit report walks your source table too and reports records that were never screened or whose interval has elapsed;
- the **retention policy** covers the log entries of your entity like any other.

What it does **not** get automatically is the job queue: the batch report has a fixed data item per built-in entity. [Sanction Screening Source](sanction-screening-source.mdx) says what to do about that.

## See also

- [Extensibility Events](extensibility-events.mdx)
- [Sanction Screening Source](sanction-screening-source.mdx)
- [Documentation - 365 business Sanction Screen](../../en-us/365-business-sanction-screen/index.mdx)