> ## Content Index > Fetch the complete content index at: https://blog.aronis.de/llms.txt > Use this file to discover other available public pages before exploring further. # The Deletion Scope That Doesn't Exist: Clearing Fields with Tags as a Proxy - URL: https://blog.aronis.de/the-deletion-scope-that-doesnt-exist-clearing-fields-with-tags-as-a-proxy/ - Published: 2026-08-21T12:26:30.000Z - Updated: 2026-08-21T12:26:30.000Z - Author: Thomas Schreiner - Tags: LeanIX, Automation, Integration, #Import 2026-08-27 21:48 ## The problem: syncing *away* data is harder than syncing it in Most people think about integrations as a one-way street of *adding* data. A 3rd-party system sends you a payload, you map it onto your LeanIX Fact Sheets, one field gets updated, everyone's happy. But there's a quieter, nastier half of the problem that almost nobody plans for: **what happens to the Fact Sheets that are no longer in the payload?** Say an external system owns a single attribute on your Applications — let's call it `externalRiskScore`. Every night it sends you a list of applications and their scores, and you dutifully write that value onto each matching Application. Clean. Then one day, App X drops out of the source system. It's decommissioned there, or it falls out of scope, or the vendor simply stops tracking it. The external system doesn't send you a "delete" event — it just… stops mentioning App X. And now `externalRiskScore` on App X is **stale forever**. It's a ghost value. It looks authoritative, it's on the Fact Sheet, and it's a lie. Nobody knows it should have been cleared, because the *absence* of data is the signal — and absence is the one thing a straight import can't see. ## Why the obvious fixes don't work The intuitive reaction is "just add a deletion scope for the field." In an ideal world you'd tell the integration: *these are the only Applications that should have a value in this field; clear it everywhere else.* LeanIX has a concept of **deletion scope** for integrations — and it's actually pretty broad. You can scope deletions to **Fact Sheets**, **relations**, **subscriptions**, and **tags**. What you *can't* scope to is an individual **field**. So you can say "any Application not in my payload should be archived," or "remove this relation," or "remove this tag" — but there's no "any Application not in my payload should have *this one field* cleared, and otherwise be left completely alone." And archiving is exactly what you don't want here. App X is a perfectly valid, living application. It just isn't tracked by *this particular* external system anymore. Nuking the whole Fact Sheet because one third-party attribute went away would be catastrophic. The other tempting option is a nightly reconciliation script: pull every Application, diff it against the last payload, clear the field on the ones that dropped out. That works, but now you own a stateful diffing job, you have to persist "what did the payload contain last time," and you've built a second integration to babysit your first one. There's a much more elegant way — and it uses machinery LeanIX already gives you. ## The trick: turn field-presence into a *tag*, then delete the tag Here's the insight. LeanIX **does** have a deletion scope — for **tags**. And LeanIX **does** have automations that fire on **tag changes**. Chain those two together and you get a field-level deletion scope for free. The proxy works in three moves: **1\. Tag everything that's in the payload.** When the integration writes `externalRiskScore` onto an Application, it *also* applies a marker tag — say `has-external-risk`. So every Application currently in the source system's dataset carries this tag. The tag is nothing more than a "this app is in the set" flag, maintained automatically by the same import that writes the field. **2\. Put the deletion scope on the *tag*, not the field.** Now configure the integration's deletion scope on that tag. This is the part LeanIX supports natively: any Application **not** in the incoming payload gets the `has-external-risk` tag **removed**. The Fact Sheet itself is untouched — no archiving, no other fields disturbed. The only thing that changes is the tag disappears. **3\. Clear the field when the tag disappears.** Add an automation that watches for the **removal** of `has-external-risk`. Its one job: when an Application loses that tag, set `externalRiskScore` back to empty. That's the whole mechanism. The tag's presence mirrors "is in the dataset." The deletion scope removes the tag the moment the app falls out. The automation treats *tag removal* as the deletion signal the field itself never had. ``` 3rd-party payload ──▶ writes externalRiskScore + applies tag "has-external-risk" │ ▼ deletion scope on the TAG ──▶ app not in payload? ──▶ remove "has-external-risk" │ ▼ automation on tag-removal ──▶ clear externalRiskScore ``` ## Why this is genuinely clever (and not just a hack) It's tempting to file this under "duct tape," but look at what it actually buys you: - **No external state.** You never have to remember what the last payload looked like. The tag *is* the memory, and it lives on the Fact Sheet where it belongs. LeanIX's own deletion scope does the diffing for you. - **Surgical, not nuclear.** Only the one field gets cleared. The Application keeps living, every other attribute untouched. You get field-level precision out of a Fact-Sheet-level feature. - **Self-healing and idempotent.** If an app leaves and comes back into the payload, it gets re-tagged and re-populated automatically. If it stays out, the field stays empty. There's no drift to reconcile. - **Auditable.** The tag change shows up in the Fact Sheet's audit log. You can literally see the moment an app dropped out of the source system — which is often more visibility than the "field silently went stale" world ever gave you. - **Composable.** Nothing here is bespoke to `externalRiskScore`. Swap the field, swap the tag, and you have a reusable pattern for *any* single-field integration that needs to clear on absence. ## The one thing to watch The tag is load-bearing, so treat it as internal plumbing: - **Don't let humans hand-edit it.** If someone manually strips `has-external-risk`, they'll accidentally trigger the clear-the-field automation. Lock the tag down (dedicated tag group, ideally not freely assignable) so it stays a machine-owned signal. - **Mind the ordering.** Make sure the import applies the tag in the *same* run that writes the field, so a Fact Sheet is never briefly "in the payload but untagged" (which the deletion scope could misread). - **Name it honestly.** Call the tag something that screams "managed by the X integration — do not touch." Future-you, staring at the tag list six months from now, will thank you. ## The takeaway LeanIX gives you deletion scopes for Fact Sheets, relations, subscriptions, and tags — but not for fields. It does, however, give you a deletion scope for **tags**, plus **automations on tag changes** — and that's enough to *compose* the field-level feature you wish existed. That's the mindset that separates a healthy LeanIX inventory from a stale one: the platform's primitives are more powerful in combination than any single feature is alone. When you can't find the button you want, ask what signal you *can* produce — and what would happen if you deleted it. --- *Struggling with third-party integrations that quietly leave stale data behind? This is exactly the kind of problem the Aronis Automation Platform for SAP LeanIX was built to solve.* [*Let's talk.*](https://aronis.de/#contact)