License harvesting

Licenses sit idle whenever someone opens an application and stops working in it. License harvesting returns those licenses to the pool automatically, so a colleague who is being denied access gets a seat instead.

Harvesting is the one OpenLM capability that acts on a user's machine, so the decisions you make when you set it up matter more than the settings themselves. This page covers those decisions end to end. For the fields, dialogs, and exact behavior of each control, see Process Manager, where you configure all of it.

Before you start

Activate Process Monitoring in Products, install the Workstation Agent on the machines you want to harvest from, and, for applications that check out from a license server, configure Brokers and License Servers. You need an administrator role to change any of it.

How a license gets harvested

Four conditions have to hold before anything happens on the workstation. Each one is a separate setting, so you can stop the chain at whichever point suits your organization.

1. The Workstation Agent decides the process is idle. By default that means no keyboard or mouse input directed at the application. You can additionally require its processor, I/O, and user-mode usage to stay below thresholds you set.
2. It stays idle past the Idle Time Limit. Only then does the process become a candidate. Being a candidate is not the same as being released.
3. The license pool comes under pressure. The release fires once usage of the pool reaches the Release Processes After % threshold. Below that threshold, idle processes are left alone, because reclaiming a seat nobody is waiting for only annoys the user.
4. No exclusion protects the session. If the user, their group, or the command line that started the process is exempt, monitoring continues but the release does not fire.

Only then does the Agent run the release method you chose.

note

Idle-time tracking and the release methods draw on your OpenLM token entitlements. If your subscription runs short of tokens for a feature, monitoring for that process waits until tokens free up. Your OpenLM account manager can tell you your plan's allocation.

Choose a release method

The release method decides what happens to the user's unsaved work. Pick the highest method in this list that your application supports, and treat the last one as a fallback rather than a default.

Method	What happens to unsaved work	Use it when
Extension	Saved, then the application closes	The application is one of the supported titles below. This is the safest outcome available.
Suspension	Untouched: the process is frozen, not closed	The application checks out from a license server but has no extension. Users resume from the Personal Dashboard.
Procedure	Depends on the steps you compose	You need a specific sequence, or you want a save attempt with a fallback.
None	Nothing: the process is monitored only	You want idle-time reporting without any automatic release.

Extension-based save and close is available for AutoCAD, ArcMap, ArcCatalog, ArcGlobe, ArcScene, ArcGIS Pro, MATLAB, SolidWorks, Petra, Kingdom, CATIA, and Harmony Enterprise.

Compose a procedure when you need a fallback

Build a procedure when you want the Agent to try to save the work before it does anything more disruptive. A procedure is an ordered list of actions the Agent runs on the process: Agent save and close, Agent suspend, and Agent kill. Each step after the first runs either once the previous step finishes or only if the previous step succeeded.

That condition is what makes a procedure useful. A procedure that tries to save and close, and suspends only if the save succeeded, is safe. A procedure that kills unconditionally is not.

danger

Agent kill force-closes the application without saving, and the user's unsaved work is lost. Use it only where no other method works, and tell the affected users before you turn it on.

Decide what must never be harvested

An application that is busy for hours without a keystroke looks exactly like an abandoned one. Simulations, renders, solver runs, and batch scripts are the sessions that harvesting damages, and they are the reason a rollout gets reversed.

Exempt them with Process Release Exclusion, which suppresses the release while idle-time monitoring continues. You can exclude by:

• User or group: protect a named person or everyone in a group, such as your simulation team.
• Command-line pattern: protect particular invocations rather than whole users. A pattern such as -f *.tcl protects every batch run started that way, while the same application stays harvestable when someone opens it interactively.
• Schedule: apply user and group exclusions only inside a recurring window, so overnight and weekend runs are protected and daytime licenses keep recycling.

A session is protected when any one of these matches. Command-line patterns ignore the schedule and apply at all times.

tip

Ask the teams who run long jobs how they start them before you write the patterns. The command line they use is usually more precise, and more stable, than a list of names that changes whenever someone joins the team.

Tune the thresholds

Start conservative. It is much easier to tighten a threshold after a quiet month than to re-earn trust after an incident.

Setting	Default	What to consider
Idle Time Limit	15 minutes	How long a genuine pause in your users' work lasts. The minimum is 3 minutes; for MATLAB it is 15 unless the release method is None or Extension.
Release Processes After %	80	How scarce the pool has to be before disruption is justified. Lower values harvest more aggressively.
Report as "Idle" After	1 minute	Reporting only. It sets when idle time is linked to the feature session and shown in Usage > Currently Consumed Licenses. It has no effect on when a process is released, but the Idle Time Limit must be at least this value.
System resource thresholds	2% each	Turn these on where input alone misleads you. If busy processes are being flagged idle, sample real values from a few workstations and set the thresholds from what you see.

What the user experiences

Harvesting only stays deployed if the people it affects can see what happened and undo it.

Through the Personal Dashboard, users get process release alerts as browser notifications, or as in-app messages where browser notifications are not allowed. Alerts collect in the notifications menu so nothing is missed, and a Process released alert links straight to Harvested Applications, where the user reopens the application with Resume.

Waiting colleagues do not have to rely on the timer either. From License in use in the License Repository, a user can see who holds a feature and send a Close App notification asking for it. Set the minimum interval between those requests in Agents Hub.

Confirm what happened

Review Process Sessions after each change. Each row is one completed session, with how long it ran, how much of that was idle, and a Shutdown Reason saying how it ended: a normal exit, a suspension by the Agent, or another release method. That column is what turns a user complaint into something you can investigate.

To release a single process by hand, for example while you are testing or when someone asks for a seat urgently, use Execute Release Method on the Active Processes page.

Harvest SaaS subscription seats

Subscription seats have no license server to reclaim from, so they follow a separate path. Subscription Optimizer frees unused seats on supported SaaS platforms and reassigns them to eligible users, with the eligibility rules defined in License Access Control. It supports Autodesk Cloud and LinkedIn Sales Navigator, and notifies users when a seat is assigned, reassigned, or unavailable.

A rollout sequence that works

Roll harvesting out in this order. Each step tells you something you need before the next step increases the risk.

1. Monitor first. Set the release method to None and turn on Track Process Idle/Active Periods. Let it run for a week and read Process Sessions.
2. Find the long-running exceptions. Look for sessions with high idle time that were real work, and ask those teams how they start the application.
3. Write the exclusions before you turn the release on. Users, groups, and command-line patterns first, schedule second.
4. Turn on the gentlest method that works. Extension where it exists, then Suspension, then a procedure that saves before it does anything else.
5. Start with a generous Idle Time Limit and a high release percentage. Tighten only once the reports are quiet.
6. Tell users what to expect and where Resume lives. One message before the first release prevents most support tickets.
7. Review Process Sessions weekly at first, then whenever you change a threshold.

Related

• Process Manager: where processes, procedures, exclusions, and thresholds are configured.
• Workstation Agent: the agent that detects idle time and runs the release.
• Personal Dashboard: what the user sees, and where they resume.
• Subscription Optimizer: the same idea for SaaS subscription seats.
• Agents Hub: agent policies, including the Close App notification interval.