LeanIX

The 720-Checkbox Problem: Automating LeanIX Permission Transport

Thomas Schreiner

Thomas Schreiner

— 2 min read
Share

The Math That Made Us Automate

Let's do some quick napkin math.

Picture a typical LeanIX workspace:

  • 9+ Fact Sheet types (Application, IT Component, Provider, you know the drill)
  • ~10 information items per type (fields, relations, fields on relations)
  • 2+ user roles beyond Admin (at minimum VIEWER and MEMBER)
  • 4 permissions per item (create, read, update, delete)

Multiply it out:

9 × 10 × 2 × 4 = 720 checkboxes.

Seven. Hundred. Twenty. Little checkboxes that we can configure — per workspace.

Now imagine you need to replicate a setup across multiple workspaces. Or you made incremental changes in Sandbox and need to promote them to PROD. Manually.

That's a recipe for carpal tunnel syndrome and configuration drift.

The Automation Promise

We decided to automate this. Transport permissions from one workspace to another. How hard could it be?

Narrator: It was harder than expected.

The LeanIX Meta Model API gives you everything you need — in theory. But there are some special cases that you need to be aware of.

Lessons Learned the Hard Way

1. The Node Name Puzzle

When setting permissions, every permission needs a node that it attaches to.

Strangely, during the process of building your permission transports, you find out that nodes are called differently, depending on whether we are referring to them in permissions management or in meta model management. In meta model management, relation subsections are referred to using their subsection name. In permission management, relations are referred to using their technical relation name, rel{A}To{B}. Most of the cases, both are identical, but they don't have to. We have observed cases where the section was called "affectedProject" even though the relation was called relContractToProject.

So: Don't trust the conventions of subsection names for relations. Scan the model, and - ideally - get some example action batches by modifying some permissions manually while having your browser debug panel open.

2. Relation Metadata

Here's a fun one, not strictly related to permissions transport, but I will add it here anyway: In general, a relation can be seen from two directions — once from A→B and once from B→A. So technically, it can be referred to using 2 different keys - rel{A}To{B} and rel{B}To{A}.

But there is one place in the LeanIX meta model where there is just one single definition: The data model (/models/dataModel), where you look up the multiplicities, activation conditions etc.

And the names are different - they don't follow the rel{A}To{B} pattern. Check your own model: You will find "applicationDataObjectRelation", but not "dataObjectApplicationRelation". So when scanning your data model for a specific relation, make sure to either scan the "from" and "to" blocks of your data model for the name that you are looking for, or you build the inverse relation name rel{B}To{A} and scan for that one.

Was It Worth It?

Absolutely.

A bit of gnarly debugging and a lot of "wait, why is this element different?" — we now have a tool that:

  • Transports all permissions from a source workspace to a target workspace
  • Can also transport permissions in the same workspace to another fact sheet type
  • Handles all the edge cases mentioned above
  • Takes about 30 seconds instead of 3 hours

The ROI kicks in immediately.

The Takeaway

LeanIX permission management is powerful but verbose. If you're doing it manually across multiple workspaces, you're either very patient or haven't discovered the pain yet.

And if you're automating it: read the meta model carefully. Don't assume naming conventions. Test with all your Fact Sheet types and relations, not just Application.

Your wrists will thank you. 🙌

Part of our ongoing series on "things we learned so you don't have to". Want to simplify your permissions management? Contact us at aronis.de.

Read more