Object ID Ninja

AL Object ID Ninja: Please Register Your Intent

  • Reading time:2 mins read

Over the past four years, AL Object ID Ninja has quietly kept thousands of teams out of conflict trouble. To plan the next chapter responsibly, I need a simple signal from you.

What I’m asking

If you intend to keep using the hosted Ninja backend after 1 January 2026, please register your interest here:
👉 alid.ninja

This is not a subscription. It’s a no-commitment way to:

  • Lock a 35% lifetime “super-early-bird” discount
  • Help me finalize fair pricing and plan my activities in the transition period
  • Potentially lower the final prices for everyone (more committed teams → better economies of scale)

Your two paths (both remain available)

  • Stay on the hosted backend (premium): zero setup, zero maintenance, zero hassle (just like in the past) + new features + support + the upcoming management portal + mobile app.
  • Run your own backend: Ninja remains open to self-host on your Azure subscription, at your pace, under your control, but with you carrying the infrastructure cost, maintenance costs, and costs of supporting users who get stuck.

Why this matters now

To operate a reliable, supported, and evolving hosted service, I need to know roughly how many teams plan to stay. If there’s sufficient interest, I’ll proceed and continue investing in the hosted platform. If there isn’t, the shared backend will be shut down on 31 December 2025, and all teams will continue with their own deployments.

This is not pressure—just transparency. Running Ninja at scale carries real cost, and I want to make the right decision with you, not for you.

A straightforward pledge

My goal is simple: keep Ninja effortless for those who prefer a smooth experience on a managed service, and keep it open for those who prefer to run it themselves. If you’ve found value in Ninja and want the hosted option to continue, please raise your hand now:

👉 alid.ninja

Thank you for helping me plan wisely—and for everything you’ve built with Ninja so far.

Continue ReadingAL Object ID Ninja: Please Register Your Intent

End of free backend for AL Object ID Ninja

  • Reading time:4 mins read

EDIT: Click here to let me know if you intend to stay with Ninja premium backend and lock in your lifetime 35% discount.

I hoped I would never have to write this post.

When I first released AL Object ID Ninja back in September 2021, my dream was simple — to give every Business Central developer a painless way to manage object IDs, forever free.
And for four years, that dream held true.

Ninja has quietly prevented hundreds of thousands of conflicts across thousands of teams. It became the invisible backbone of smooth collaboration for our community — always there, always free.

But as Ninja grew, so did the infrastructure behind it. What once cost a few peanuts now costs a small fortune every month. To keep it running fast, reliable, and evolving, it’s time for Ninja to take its next step — from a free community service to a sustainable, premium platform.

What’s changing — and when

You can continue using Ninja for free until 31 December 2025.
After that, you’ll have two options:

  1. Self-host Ninja on your own Azure subscription — and keep it free forever.
  2. Subscribe to the new Premium Ninja backend — and enjoy a hassle-free, continuously improving experience.

Either way, you stay in control.

Read on if you want to learn more.

Continue ReadingEnd of free backend for AL Object ID Ninja
Read more about the article AL Object ID Ninja v1.1.0 released

AL Object ID Ninja v1.1.0 released

  • Reading time:2 mins read

I have just released version 1.1.0 of AL Object ID Ninja. Here’s what’s new.

Merge synchronization

In previous versions, you could only synchronize full information. This type of synchronization simply recorded in the back end whatever it finds in the front end. For example, if the back end had object IDs 50100..50105, and the front end only has object IDs 50104..50106, then the full synchronization, will drop whatever was recorded previously, and will replace it with 50104..50106.

This type of synchronization may be good enough for teams who are only just starting development in AL, and have no existing repos. They can just start assigning numbers, and then synchronize later as needed.

However, if you are an active team with dozens of developers working in different branches, and you start using AL Object ID Ninja after objects already exist in your repo, if you only run synchronization from master branch, then any of object IDs already assigned in those other development branches will not be visible to AL Object ID Ninja. Instead of preventing object ID collision, AL Object ID Ninja would lead you right into it in this case.

For all these scenarios, you have Update synchronization.

Continue ReadingAL Object ID Ninja v1.1.0 released
Read more about the article AL Object ID Ninja

AL Object ID Ninja

  • Reading time:9 mins read

One of the biggest obstacles to AL team development (is there any other kind?) is object IDs. IDs are supposed to be easy: just pick the next free one and off you go. AL Language even helps by suggesting the next available one through IntelliSense. But you are most likely not the only developer on your team. As soon as you add another developer to equation, and both of you use the built-in AL IntelliSense auto-suggest feature, you are inevitably heading towards object ID collision. The more developers there are, the more active your repository is, the more likely the collision.

Obviously, without some kind of a back-end that coordinates object ID assignment – preferably in real time – is absolutely necessary. And teams have come up with various solutions to this problem. They include:

  • “Who cares!”: the most heroic one, no object ID collision will ruin your day. Bring it on – you say! I’ll handle you – you say! These teams spend a lot of time resolving collisions post-factum.
  • Object “reservations”: you create an empty object of the desired type, push just that, create a PR that does nothing by that, and launch into the Hail Mary mode until your PR gets merged. The slower your validation pipeline is, the more likely it is that more than one developer will be saying their Hail Marys at the same time, and guess what – Mary will help one of them.
  • “Hey, folks”: you yell to announce to everyone that you are about to take an object ID. Or, in more advanced teams, you run a Teams team (uh, did I mention “team?”). This approach is not too robust, but generally yields better results than the above two.
  • Excel: the ways this tool gets used, geez. It’s a spreadsheet calculator, for Pete’s sake, but people have been using it for everything ranging from shopping lists to, well, object ID assignment sheets.
  • “When you have a hammer, every problem you see is a…” BC! The ways this tool gets used, too! Well, heck, yeah, isn’t it so freaking obvious that people will just create a BC app and deploy it internally so that everyone can use it. BC has nearly all facilities you need (that none of the above approaches does): primary key validation and concurrency. This is a very advanced stage in the evolution of object ID collision management solutions.
  • Automation. Yeah, baby! Now that there is a BC back end, and BC has APIs, let’s build an API that gives you next number, and then let’s do some front-end that fetches that from the back end, and then let’s somehow embed into VS Code. There is at least one tool that I know of, that does exactly this. And good that I didn’t know of it that Saturday morning nine days ago, because I would have zero motivation to take this evolution one big step further.

This is where AL Object ID Ninja joins the show! It’s zero-configuration, crazy-fast, mind-bogglingly simple solution for no-collision object ID assignment in AL. If you haven’t already (and if you are using Waldo’s AL Extension Pack, chances are you already have) go fetch yourself a copy.

Continue ReadingAL Object ID Ninja