The Deletion Scope That Doesn't Exist: Clearing Fields with Tags as a Proxy

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.