When a license needs an approval

Most software is licensed the moment you take it. Some is not: the offer says a decision has to be made first, and only then is a license issued. You see this as a license request in EntitleKit rather than an immediate grant.

Who decides

The offer names the decision maker. There are three cases, and the request tells you which one applies to it:

  • Nobody — the license is issued automatically.

  • Your own account — an administrator of your account approves it in EntitleKit.

  • An outside authority — the company that controls licensing for that software. This is common when the software is licensed per robot under a contract: the vendor, a compliance desk, or a partner licensing system holds the decision, not you.

An outside authority is a machine integration, not a person with a console login. Requests go to it, and its decisions come back on their own schedule, so an outside decision may take longer than an internal one.

The life of a request

  1. Draft — you have created it but not sent it. Nobody can act on it yet.

  2. Pending — submitted and waiting for the decision maker.

  3. Information required — the decision maker needs more from you before deciding. Supply what was asked for; the request goes back to pending. Nothing about the original request is lost.

  4. Approved or Refused. A refusal comes with a reason you can read and act on.

  5. Issuing, then Issued — approval and issuance are separate. A request can be approved and still be waiting for its license to be minted; only Issued means a license exists.

  6. Failed — issuance did not complete. This is a technical outcome, not a refusal, and it can be retried.

Later on, an issued license can also become Expired or Revoked.

You can withdraw a request you should not have made, as long as nobody has decided it yet. A withdrawal is recorded as yours; it is not filed as a refusal, so it never appears in the decision maker’s record as a verdict they did not make.

Approving on the authority’s behalf

An outside authority can delegate approval back to the customer. When it does, the requests that would have gone out to it are decided inside the owning account instead — your administrators approve them in EntitleKit, with no round trip to the vendor.

Delegation is granted by the authority, not requested by you, and it can be scoped two ways:

  • to one account, or to every account that takes that offer; or

  • to a branch of your organization — an organizational unit and everything under it, so new sites inherit the delegation as they are created rather than needing a change each time.

Two things are worth knowing before you rely on it:

  • The authority keeps a final say. It can step in on a delegated request and decide it itself, and for a robot-held license it can still refuse after your administrator has approved — up until issuance actually begins. Once a license is being minted, that window has closed.

  • Delegation can be withdrawn. If it is revoked while a request is in flight, the next decision or issuance on that request is refused rather than quietly proceeding on authority nobody holds any more. The same applies if the account moves out of the delegated branch of your organization. File the request again under whatever authority now applies.

Reading a decision

Whoever decided, the request keeps the whole trail: who decided, when, the reason code and the explanation written for you, and the reference the authority recorded on their side. Use that reference when you contact the vendor about a refusal — it is the same identifier in both systems.

Nothing in a decision is edited afterwards. A mistaken approval is corrected by a compensating action — a revocation or a replacement — which is added to the trail rather than replacing what was already recorded.