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 |
| Screen an entity the app does not support - a table of your own, or a standard table that is not covered | Sanction Screening Source |
Dependency
Add a dependency to the 365 business Sanction Screen app in the dependencies node of your app.json:
Code
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.
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:
- The implementation of the source builds a
bdev.Sanction Screening Modelrecord from the source record. OnAfterInitializeModelFromSourcelets other extensions add to it.OnBeforeMatchRecordlets other extensions correct it, or skip the screening.- The data is sent to the data sources and the result is written to the screening log.
- Matches are written as
bdev.OS Match Entryrecords 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.
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 says what to do about that.