Keeping Track of Fact Sheet Resource Links - The Smart Way

A customer wanted to filter applications by whether they have a documentation resource. Calculated fields can't see documents. The elegant answer? Make LeanIX call itself.

Share

The deceptively simple request

A customer came to us with what sounded like a trivial ask:

"I want to filter my applications into two buckets — the ones that already have a documentation resource, and the ones that don't."

Sounds easy, right? It isn't. At least not as easy as you'd hope. Let's walk through the rabbit hole, because the way out is genuinely elegant.

Attempt #1: Calculated field

The instinctive first move for any LeanIX admin: a calculated field. Define a rule, derive a hasDocumentationLink value, done.

Except — calculated fields still can't access factSheet.documents. The documents relation simply isn't exposed to the calculation engine. So the one piece of data we need is exactly the piece we can't reach.

Dead end.

Attempt #2: Automations

Next idea: LeanIX Automations. Surely we can trigger on a document change and flip a field?

Nope. Automations have no trigger for document created or document deleted. The event we care about doesn't exist in the automation trigger catalog.

Dead end #2.

Attempt #3: External automation

Okay, let's bring our own infrastructure. This part is genuinely trivial:

Register a webhook on DOCUMENT_CREATED and DOCUMENT_DELETED.

Point it at a small service (a Lambda, a container, whatever).

The service reads the event, sets hasDocumentationLink accordingly via the GraphQL API.

It works. But now we own a server. We own deployment, secrets, monitoring, uptime. For a one-line field update, that's a lot of external surface area.

So the question nagged: does it really have to be external? Can't we do this 100% in standard LeanIX?

The plot twist

Turns out: yes. And it's much more elegant than any of the above.

Webhooks were the right instinct all along. Here's the insight that unlocks everything:

  • Modern LeanIX webhooks support OAuth 2.0.
  • LeanIX itself speaks OAuth 2.0.
  • And — who ever said a webhook has to call an external URL?

What if the webhook just... called an internal URL? Say, the GraphQL service? If you shape the payload cleverly, the webhook becomes its own processor. No Lambda. No container. No external anything.

LeanIX calling LeanIX.

Putting it together

Step 1 — Create a push webhook

Point the target URL directly at the GraphQL service.

Step 2 — Subscribe to the events

DOCUMENT_CREATED and DOCUMENT_DELETED.

Step 3 — Configure OAuth

Use the LeanIX OAuth endpoint:

  • Client ID: apitoken
  • Client Secret: the API token of a technical user (Member role)
  • Body parameter: grant_type=client_credentials — don't forget this one.

Step 4 — The callback / payload transformer

This is where the magic happens. The webhook processor inspects the event: is a document of type documentation being added or removed from an Application? If so, it builds a GraphQL mutation that sets the single-select field hasDocumentationLink — yes on create, no on delete.

/** @returns {{ payload: any; targetMethod: 'POST' | 'PUT' | 'GET' | 'DELETE'; targetUrl: string; active: boolean; }} */
export function main() {
  data.active = false;
  var p = data.payload;
  var fs = p.fsIdAndRev;

  if (p.fsType === 'Application' && p.documentType === 'documentation') {
    var deleted = (p.type === 'DocumentDeletedEvent');

    data.payload = {
      query: 'mutation($id:ID!,$patches:[Patch]!){updateFactSheet(id:$id,patches:$patches){factSheet{id}}}',
      variables: {
        id: fs.id,
        patches: [
          { op: 'replace', path: '/hasDocumentationLink', value: deleted ? 'no' : 'yes' }
        ]
      }
    };

    data.active = true;
  }

  return data;
}

And — boom — it works.

Why this is the elegant solution

  • Zero external infrastructure. No server, no Lambda, no container, nothing to deploy or monitor.
  • 100% standard LeanIX. Webhooks, OAuth, GraphQL — all native capabilities.
  • Self-contained security. The OAuth credential lives inside LeanIX's own webhook config; nothing leaks to a third party.
  • Event-driven and instant. The field updates the moment a documentation resource is added or removed.

Once hasDocumentationLink is a real single-select field, your original request becomes trivial: filter, report, build a KPI, drive a dashboard — whatever you need. The applications with and without documentation are now one click apart.

The takeaway

The best integration is often the one you don't build externally. Before you reach for a Lambda, ask whether the platform can talk to itself. With LeanIX webhooks + OAuth + GraphQL, a surprising number of "we need a server for that" problems quietly disappear.


Want help turning your LeanIX data quality ideas into no-code automations? That's exactly what we do at Aronis. Get in touch.

Read more