The measure of a blocking system is not how it handles the apps you meant to block. It is how it handles the morning the blocked app turns out to be the one the payroll run depends on. ManageEngine has a built-in answer: user requests and temporary, just-in-time access. Here is how to run that door well.
Every application control rollout meets the same test. Somewhere in week two, a blocked dialog appears on the screen of someone doing real work — the export tool only accounts uses, the label printer utility nobody documented. At that moment your system either has a fast, official way to say yes, or the office invents an unofficial way: shared admin passwords, personal laptops, files carried home. The request route is not a weakness in the policy. It is what makes the policy survivable.
The option is set during policy deployment: allow users to request applications which are unmanaged. Switch it on from the beginning, for blocklist and allowlist policies alike. A user who hits a block then gets a request button instead of a dead end, and you get a structured request — which app, which PC, which user — instead of a phone call you have to reconstruct later.
Write the blocked-app message to match: name the policy, and tell the user the request route exists. A dialog that explains itself prevents the screenshot being forwarded to the whole office with the caption that IT has broken the computers again.
ManageEngine's just-in-time access grants permission that is temporary and time-bound: approve the label utility for four hours, or for today, and the permission expires by itself — no follow-up ticket, no forgotten hole. Match the grant to the need the user described. Month-end export tool? Until the end of the week. One-off file conversion? Two hours.
Reserve permanent approval for the third or fourth identical request. The pattern, not the first ask, is the evidence that an app belongs on the allowlist for that group.
When the same app is requested by the same department repeatedly, stop granting exceptions and fix the list: add the app to the allowlist (or remove it from the blocklist) for that custom group only. Accounts gets its export tool permanently; the rest of the office stays blocked. The audit log keeps the history of how the decision was reached, which is exactly what you want if the decision is ever questioned.
Do the opposite too: an exception nobody has used in a quarter quietly expires at the review. Exception lists grow by accident and shrink only on purpose.
The one route that must stay closed: handing a user local administrator rights, or the admin password, to get around a block. An admin can stop the agent, edit the policy, and install anything — the exception has just eaten the entire policy, for that PC, forever, with no audit trail of what happened next.
If a genuine emergency ever forces it, the honest version is supervised and temporary: IT connects, does the task, disconnects, and the request route gets fixed the same day so the emergency does not repeat.
Every click shown live in the ManageEngine console — application groups, policy deployment and the audit-to-strict switch.
▶️ Watch Full VideoA message that the application is blocked by policy — you can customise that message during deployment — and, if you enabled requests, a way to ask for access. The user does not get a technical error or a broken-looking crash. Always write the message to say why the block exists and what to do next; a clear dialog prevents most support calls.
A temporary yes. Instead of permanently allowlisting an app, the admin approves it for a limited time — a few hours or days — and the permission switches itself off when the time ends. The grant and its expiry are recorded in the audit log. It fits one-off needs exactly: real access for real work, with no permanent hole left behind.
Stop treating it as an exception. If a department needs an app every day, the app belongs on that department's allowlist (or off its blocklist) as a permanent, recorded decision. Exceptions are for the rare and the temporary. Daily needs handled as daily exceptions create queue noise, annoyed users, and an audit log that hides the real rule inside a pile of one-offs.