Who Owns That Feature?

Open lmstat and you’ll see features: ANSYS, nx_design, CATIA_V5_HARDWARE, acad_2024. Open your purchasing system and you’ll see applications: ANSYS Mechanical, Siemens NX, CATIA, AutoCAD. The two lists overlap, but they aren’t the same list, and the mapping between them is where a lot of license-management work quietly accumulates errors.

LiMon builds and maintains that mapping for you. The mental model is small once you see it, and the rest of this piece is about laying it out clearly so you don’t have to find each part out by accident.

The three entities in the model

Servers. A license daemon — FlexLM, RLM, LM-X, DSLS, Sentinel — running somewhere on your network and serving features. LiMon polls it, watches what it has, and records what’s checked out.

Applications. A business-facing entity your team actually thinks about: “ANSYS Mechanical,” “NX,” “CATIA V5.” An application is a name your finance department recognizes and an annual cost line everybody understands. You bring one into existence by clicking “Add Application” — either picking from LiMon’s library of common product templates (which pre-fills sensible feature-matching patterns for that product) or by starting from scratch. Many license servers serve more than one application; some applications are split across multiple servers for region, redundancy, or failover reasons.

Deployments. The link between the two. Most of the time they materialize as a side effect of the application flow — you tick servers on the application you just added (or open an existing app and link more servers later) and a deployment record is created for each tick. If you’d rather work from the other end, the Deployments admin page lets you create them directly: pick an application, pick a server, choose the scope mode, save. Either path produces the same record. Each deployment carries some metadata around environment (PROD/TEST/DEV/DR), whether it’s active, and the feature scope mode we’ll get to next.

Servers come from whatever you’ve configured for polling — they exist whether or not you’ve labeled what’s on them. Applications, by contrast, are inert on their own: an application with no servers attached is just a name on a list, doing nothing. The work the rest of the system does — attribution, usage tracking, cost reporting — only kicks in once an application has at least one deployment.

Shared vs. Exclusive: options when linking a server

When you link a server to an application, you pick a feature scope mode. There are two:

Exclusive. This server hosts only this application. Every feature served from it — current and future — belongs to this app, automatically. The first time LiMon refreshes attribution after the link, every feature on the server is claimed. Anything that shows up later (a new entitlement, the vendor adds a SKU, a renewal brings in an extra module) is also claimed without you doing anything. This is the default when you link a server to an app, because the most common case really is one server, one application.

There can only be one active exclusive deployment per server. That’s because of what exclusive means.

Shared. This server hosts multiple applications, and ownership of each feature has to be sorted out somehow. Multiple Adobe products on one license server is the classic example; Siemens apps like Simcenter or Amesim running in parallel is another. With Shared, linking the server alone doesn’t claim any features. They stay unattributed until a feature-mapping rule on one of the co-deployed applications tells LiMon what belongs to whom.

The right choice usually isn’t a tradeoff. If the server really does only serve one product, leave the default Exclusive on and move on. If it is serving features from multiple business-facing applications, mark the link as non-exclusive (Shared) and accept that you’ll do a little setup once with feature mappings.

How features actually get attributed

When LiMon refreshes attribution on a server — which happens after polling picks up new inventory, after you change a deployment, after you edit a feature mapping, or on demand — it walks through every feature currently visible on that server and asks four questions in order:

1. Was this feature already attributed to an application still actively linked here? If yes, keep it. Earlier attribution decisions are sticky — once a feature has been claimed by an app on a server, refreshes don’t undo it as long as that app is still attached to the server.
2. Is there an active Exclusive link on this server? If yes, all unattributed features go to that application as an automatic claim.
3. Does exactly one of the co-attached applications have a feature-mapping rule that matches this feature name? If yes, that application claims it. Rules can be exact names (nx_design) or SQL-style LIKE patterns (CATIA_V5_%), defined once per application in the feature-mappings admin page.
4. Did more than one application’s pattern match? Then the feature is ambiguous — none of them claim it. LiMon would rather surface the conflict than silently pick a winner.

If none of those four resolves the feature, it stays unresolved and shows up as “Unmapped” on the server view.

Two things worth internalizing about this:

• Patterns only count for applications already linked to the server. A pattern rule on Application X has no effect on Server Y unless X is attached to Y. This avoids the trap where a generic pattern accidentally claims features on a server the application has nothing to do with.
• Ambiguity is a feature, not a bug. When two applications could legitimately claim a feature, leaving it unattributed forces you to look at it. You’ll either drop one of the competing patterns, tighten the one that was too broad, or discover that the server actually shouldn’t be shared between those two applications in the first place.

The “Priority” fields

LiMon has two unrelated priority numbers related to deployments and mapping. They do very different jobs.

Deployment priority

Visible on each deployment card on the application detail page. Default 1, lower numbers come first. Its purpose is to order an application’s deployments when you view them, so you can signal “this is the primary site for this app” without that being a separate field.

What it explicitly does not do: decide who wins when two applications share a server and both have rules that match the same feature. That case lands in the ambiguous bucket above. Deployment priority is a per-application display hint, not a cross-application arbiter.

So if you have AutoCAD and Inventor both linked Shared to the same server, and both their pattern lists somehow match dwg_export, raising or lowering deployment priority numbers won’t fix it. Tightening one of the patterns will.

Feature-mapping rule priority

Visible on each row of the Feature Mappings admin page. Default 100, lower numbers come first. Its purpose is to break ties within one application’s rule list: if Application X has two rules that both match the same feature name, the one with the lower priority number wins and assigns its display name and package metadata to that feature.

The canonical use case is a broad fallback alongside a specific carve-out. Suppose CATIA has a catch-all rule CATIA_* at priority 100, and a more specific CATIA_V5_DESIGNER at priority 10. When CATIA_V5_DESIGNER shows up on a server, the specific rule wins and the feature gets the right display name; everything else matching CATIA_* falls through to the broad pattern and gets the generic label. Without rule priority, you’d have to write every pattern to be mutually exclusive — which gets tedious fast for a product with dozens of features.

Like the deployment field, this priority does not arbitrate cross-application ambiguity either. Each application’s rule list is evaluated independently — within-app priority picks the best match for that app, and only then does LiMon check whether more than one application made a claim. If two did, the feature still goes to the ambiguous bucket regardless of which side had the lower priority number.

A quick mental model

Different scopes, no interaction:

• Deployment priority ranks an application’s servers against each other (which one is primary).
• Feature-mapping priority ranks an application’s rules against each other (which pattern wins when several match within the same app).
• Neither one decides anything between different applications. Cross-application conflicts always resolve through the ambiguity rule above.

I see an unmapped feature. How do I claim it?

The supported path:

1. Confirm the application is actually attached to the server in question. No link, no pattern can claim anything there.
2. Go to the Feature Mappings admin page and create a rule whose pattern matches the feature name — exact or LIKE — and assign it to the application.
3. Saving the rule triggers an attribution refresh for affected servers. If the feature was sitting in the unresolved bucket and no competing application’s pattern matches the same name, it gets claimed and moves into the application’s feature list on the next refresh cycle.

If it was in the ambiguous bucket rather than unresolved, adding another rule won’t help — you’ll just deepen the ambiguity. The fix is to look at the other applications that have matching patterns and either drop the competing pattern or narrow it down.

If you genuinely have a single-application server but it’s currently set as Shared, the bigger hammer is to flip the link to Exclusive — that will auto-claim every feature on it, no patterns required. Just be aware this is server-wide: anything currently on the box, plus anything that shows up later, ends up attributed to that one application.

A diagnostic technique that costs nothing

When something looks wrong with an application’s feature list, the cheapest check is to compare two pages:

• The server detail page shows every feature currently licensed on that server, regardless of attribution. It’s the ground-truth inventory.
• The application detail page shows only the features attributed to that application across all its deployments. It’s the filtered view.

Any feature that appears on the server page but not on the application page falls into one of three buckets:

• Claimed by another application on the same server.
• Ambiguous — multiple applications had matching patterns and none of them got it.
• Unresolved — no pattern matched and the deployment didn’t auto-claim.

You can usually tell which by glancing at the other applications deployed on the server, but the resolution source for each claim is recorded too, so an admin tool can show you the reason directly when the side-by-side isn’t enough.

Why the model is shaped this way

In the real world, license servers don’t always follow the tidy “one server, one product” model. Publishers bundle multiple titles onto a single daemon. Vendors consolidate acquired products onto whichever server they already had running. A team reuses an existing license server for a small new tool because spinning up another one isn’t worth it. In all of those cases, the raw list of feature names a daemon returns — acdlt_2024, prem_pro, solver_token_a — doesn’t on its own tell anyone which features belong to which budget line, which application, which renewal conversation.

LiMon’s attribution model is the smallest layer that bridges those two views, and most of its downstream benefits fall out of it for free. The same mapping that decides “this feature belongs to AutoCAD” also drives the friendly naming you see across dashboards, reports, expiration views, and denial summaries — so IT and procurement end up looking at the same words on the same page instead of arguing across raw vendor mnemonics. It also gives you a clean way to scale up a shared server without having to split it: two CAD pillars on one daemon stays one daemon. LiMon does the attribution work; the underlying license server doesn’t have to be reshaped.

The model itself tries to be opinionated where opinions are cheap and explicit where stakes are real:

• Attribution is sticky — once a feature has been claimed for an app on a server, refreshes don’t undo it for as long as that app is still attached there.
• Exclusive links are an honest “this is the only owner” signal that picks up new features automatically and never has to be revisited.
• Pattern rules let you encode the obvious mappings once and stop maintaining them.
• Ambiguous cases get surfaced rather than silently picked, because a wrong silent pick is worse than an unmapped feature you can see.

The net effect is that the parts of the system that can be automated quietly are, and the parts where someone needs to think are visibly waiting for someone to think about them. That’s the difference between a tool that helps you manage licenses and one that just shows you numbers.

Where LiMon fits

LiMon polls FlexLM, RLM, LM-X, DSLS… servers on your network, builds and maintains the application-to-feature mapping described above, and turns it into utilization reports, audit-defense documentation, and renewal-conversation ammunition. It runs on your hardware — no cloud, no agents on the license servers, no phone-home. Request an evaluation to try the attribution workflow, then choose Standard or Professional for the server scale, analytics, and audit reports that put the model to work.