The Delete Option: How Rapidi Removes Orphaned Records

Most transfers you build in Rapidi are there to create or update records. A transfer with the Delete option ticked does the opposite: it removes records from the destination system that no longer exist in the source. It is the piece that keeps the two systems from drifting apart when records are cancelled, deleted, or archived on the source side.

Because a deletion transfer is the only transfer type that destroys data, it deserves its own configuration habits : a tight scope, a predictable position in the run order, and a proper test cycle before it goes live.

What the Delete option does

A transfer with only the Delete option ticked works by comparison:

1. Rapidi reads the destination records that fall inside the destination filters (delimitations).
2. For each one, it looks for a matching source record using the Table Link key fields.
3. If no matching source record is found, the destination record is deleted.

Example: SALES03_SF_DELETE

The transfer below removes Salesforce sales orders that no longer exist in Dynamics 365 Business Central.

Options

Only Delete is ticked. Add and Update are deliberately off . This transfer's job is not to keep field values in sync, that belongs to the transfers that run before it. Keeping the responsibilities separate makes both the run order and the log much easier to read.

Table Link (key fields)

These two pairs are the identity check. A Salesforce SalesHeader__c record survives only if a BC SalesOrder exists with the same document number and the same document type. Including Document_Type matters: without it, a quote and an order sharing a number could match each other and mask a real deletion.

Field List (mapping)

A deletion transfer writes nothing, so the field list stays minimal - just enough to identify the record. There is no reason to carry the full mapping from the add/update transfer over into the deletion transfer.

Filters Destination (delimitations)

This is the safety boundary, and it is the line worth reviewing hardest in any deletion transfer.

Unique_Key__c on the Salesforce side stores a composite key in the form COMPANY#DOCUMENTNO. The ##BEFORE function evaluates the part of the string that sits before the # separator, and the filter compares it to %%COMP% - the company currently being processed.

The effect: when the transfer runs for company A, only Salesforce orders belonging to company A are considered for deletion. Orders belonging to companies B and C are invisible to it, even though they live in the same Salesforce table. In a multi-company setup, dropping this filter would mean every company's run treats every other company's orders as orphans.

The %%COMP% and %%CONN% variables also let a single transfer definition serve every company in the setup, instead of maintaining one hard-coded deletion transfer per entity.