When GUIDs Collide: The App ID Problem Nobody Expected

You know what’s supposed to be unique? Snowflakes. Fingerprints. And GUIDs.

A GUID (Globally Unique Identifier) is mathematically designed to be so astronomically unique that if you generated one hundred billion GUIDs per second, you’d still have a better chances of being struck by lightning twice and then winning the lottery, all on the same day, than generating a duplicate.

And yet, here we are. Talking about duplicate App IDs in Business Central.

The Problem That Shouldn’t Exist

Every AL app has an App ID in its app.json file. It’s a GUID. It should be unique. Microsoft doesn’t enforce uniqueness anywhere, but that’s fine because GUIDs are unique by design. Right?

Wrong.

AL Object ID Ninja has now seen close to 50,000 apps over the years. And among those 50,000 apps, I’ve found nearly 150 that share an App ID with at least one other app. That’s 150 lottery-winning, lightning-struck developers out there.

Except… they didn’t win anything.

How Does This Even Happen?

Let me walk you through the three ways developers accidentally create App ID collisions. And yes, I said “accidentally” because I genuinely believe nobody wakes up thinking “today I’m going to cause untold chaos in someone else’s production environment.”

Scenario 1: The Manual GUID

Some developers, for reasons that remain mysterious to me, decide to type their App ID manually.

You know the type. The developer who looks at a GUID like 63ad09c4-eaf9-4b69-a076-a07d434de6a7 and thinks: “That’s too complicated. Let me use something simpler.”

So they type a1b2c3d4-e5f6-7890-abcd-ef1234567890.

Congratulations. That particular “simple” GUID is currently used by at least 7 different apps. Two of them are published to AppSource. Published. To. AppSource.

Yep. I am serious. If you don’t trust me, go waste a few minutes of your life and check it yourself.

I don’t know what happens when two apps with the same App ID meet in a production tenant, and frankly, I don’t care to find out. But I suspect it involves error messages, confused support tickets, and at least one developer questioning their career choices.

Scenario 2: The GitHub Clone

This one I take personally.

I’ve published demo apps to GitHub. Waldo has published demo apps to GitHub. Pretty much anyone who has ever given a conference talk or created training materials has published demo apps to GitHub.

These repos are meant to be educational. They come with sample code, sample configurations, and yes, sample App IDs.

The intended workflow is:

1. Clone the repo
2. Learn from it
3. Create your own app with your own App ID

The actual workflow for some developers is:

1. Clone the repo
2. Change the app name
3. Ship it

I’ve seen apps in production that use App IDs I originally created for some “Hello World” demo years ago. These apps have different names, different publishers, different everything. Except that one thing that actually matters for uniqueness.

If you’ve ever cloned a demo repo and shipped it without generating a new App ID, there’s a non-zero chance your app shares its identity with someone else’s production system. Sleep well tonight.

Scenario 3: The Copy-Paste App

This is the subtle one.

Developer A creates an app. It works great. Developer B needs a similar app, so they copy Developer A’s project and start modifying it.

They change the name. They change the publisher. They change the description. They rewrite all the code. They update the dependencies. They feel very thorough and professional about the whole thing.

They forget to change the App ID.

Months later, both apps are in production at different companies. It’s like identical twins who got separated at birth, except instead of a heartwarming reunion, there’s a database collision waiting to happen.

Why Should You Care?

“But Vjeko” – I hear you say – “what are the odds that two apps with the same App ID will ever end up in the same Business Central tenant?”

Beats me, honestly. Should be near 0, I guess.

But you know what else had near 0 odds? Having duplicate GUIDs in the first place. We weren’t supposed to have any of those, and yet here we are with at least 150 of them.

The Business Central ecosystem is surprisingly small. Partners share customers. Companies merge. Consultants move between firms. Apps get acquired. Every one of these events increases the probability that two apps with the same App ID will meet.

And when they do meet? I honestly don’t know what happens.

What Ninja Is Doing About It

Here’s the good news: if you’re using AL Object ID Ninja (on the public platform), we’ve got your back.

Over the years, Ninja has seen tens of thousand different app IDs. It knows which ones are duplicates. It knows which app IDs are affected. And I’m working on a set of features that will:

1. Alert you if your App ID conflicts with another known app
2. Ensure isolation so that even if your App ID matches someone else’s, your object ID consumption remains completely separate from theirs
3. Provide visibility into the scope of the problem for your specific apps

These features are only available on the public platform (I don’t have visibility into self-hosted instances, nor do I want that level of integration into anyone’s private infrastructure). But it does mean there’s an added benefit to using the public platform: you get collision awareness and protection that simply isn’t possible any other way.

What You Should Do

If you discover that your app has a duplicate App ID, here’s my honest recommendation:

Create a new app.

Yes, really. Generate a new App ID, create proper upgrade and migration procedures, and transition your customers to the new app. It’s work, but it’s predictable work. Unlike the alternative, which is waiting for the day when your app and its doppelganger meet in production and throw a party to which unwilling developers will be invited.

Think of it like finding out you have the same social security number as someone else. Sure, nothing bad has happened yet, but do you really want to wait and see?

The Takeaway

GUIDs were supposed to be the one thing we didn’t have to worry about. The mathematics guaranteed it. The probability of collision was supposed to be so infinitesimally small that it wasn’t worth considering.

And yet, through the creative application of manual typing, repository cloning, and copy-paste development, we’ve managed to create collisions anyway. Nearly 150 of them, out of 50,000 apps.

The universe gave us a system that was mathematically guaranteed to produce unique identifiers, and we found a way to break it. If that’s not peak software development, I don’t know what is.

So here’s to the 150 lottery winners out there. You beat odds that were never supposed to be beatable. Unfortunately, your prize is a ticking time bomb in your app.json.

You might want to do something about that.