<turbo-stream action="update" target="wiki_card"><template>

<h1>The Delete Option: How Rapidi Removes Orphaned Records</h1>
<div class="trix-content"><p>Most transfers you build in Rapidi are there to create or update records. A transfer with the <strong>Delete</strong> 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.</p><p>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.</p><h2>What the Delete option does</h2><p>A transfer with only the <strong>Delete</strong> option ticked works by comparison:</p><ol><li>Rapidi reads the destination records that fall inside the destination filters (delimitations).</li><li>For each one, it looks for a matching source record using the <strong>Table Link</strong> key fields.</li><li>If no matching source record is found, the destination record is deleted.</li></ol><h2>Example: SALES03_SF_DELETE</h2><p>The transfer below removes Salesforce sales orders that no longer exist in Dynamics 365 Business Central.</p><p></p><figure class="attachment attachment--content"><table class="table table-bordered"><thead><tr><td>Setting</td><td>Value</td></tr></thead><tbody><tr><td>Description</td><td>Delete SFDC sales orders that are no longer in D365 BC %%COMP%</td></tr><tr><td>Group</td><td>ORDER</td></tr><tr><td>Source / Source Layout</td><td>%%CONN% / NAVODATA001</td></tr><tr><td>Destination / Destination Layout</td><td>SFORCE001 / SFORCE001</td></tr><tr><td>Source Table</td><td>SalesOrder</td></tr><tr><td>Destination Table</td><td>SalesHeader__c</td></tr><tr><td>Options enabled</td><td>Enabled, Delete</td></tr></tbody></table><figcaption class="attachment__caption"></figcaption></figure><p></p><h3>Options</h3><p>Only <strong>Delete</strong> is ticked. <strong>Add</strong> and <strong>Update</strong> 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.</p><h3>Table Link (key fields)</h3><p></p><figure class="attachment attachment--content"><table class="table table-bordered"><thead><tr><td>Source Field</td><td>Destination Field</td></tr></thead><tbody><tr><td>No</td><td>Name</td></tr><tr><td>Document_Type</td><td>Document_Type__c</td></tr></tbody></table><figcaption class="attachment__caption"></figcaption></figure><p></p><p>These two pairs are the identity check. A Salesforce <code>SalesHeader__c</code> record survives only if a BC <code>SalesOrder</code> exists with the same document number <em>and</em> the same document type. Including <code>Document_Type</code> matters: without it, a quote and an order sharing a number could match each other and mask a real deletion.</p><h3>Field List (mapping)</h3><p><br></p><p></p><figure class="attachment attachment--content"><table class="table table-bordered"><thead><tr><td>Source Field</td><td>Destination Field</td></tr></thead><tbody><tr><td>No</td><td>Name</td></tr></tbody></table><figcaption class="attachment__caption"></figcaption></figure><p></p><p>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.</p><h3>Filters Destination (delimitations)</h3><p><br></p><p></p><figure class="attachment attachment--content"><table class="table table-bordered"><thead><tr><td>Field Name</td><td>Filter</td></tr></thead><tbody><tr><td>##BEFORE("Unique_Key__c",'#')</td><td>%%COMP%</td></tr></tbody></table><figcaption class="attachment__caption"></figcaption></figure><p></p><p>This is the safety boundary, and it is the line worth reviewing hardest in any deletion transfer.</p><p><code>Unique_Key__c</code> on the Salesforce side stores a composite key in the form <code>COMPANY#DOCUMENTNO</code>. The <code>##BEFORE</code> function evaluates the part of the string that sits before the <code>#</code> separator, and the filter compares it to <code>%%COMP%</code> - the company currently being processed.</p><p>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.</p><p>The <code>%%COMP%</code> and <code>%%CONN%</code> variables also let a single transfer definition serve every company in the setup, instead of maintaining one hard-coded deletion transfer per entity.</p></div>
</template></turbo-stream>

