Plan change requests

Some plan changes should just happen; others need a person to look at them first. A plan change request is a customer asking to move to a different plan, held for review instead of applied immediately. You approve or reject it, optionally with a note that goes back to the requester. (Sales)

Use it where a move has commercial consequences — an upgrade you want to price, a downgrade that would leave data inaccessible, a tier that carries a contractual commitment.

Requiring approval

Approval is a policy on the entitlement, not a global setting, so you can hold the grants that matter for review and let everything else self-serve. Set it on the entitlement’s Policies tab; see Policies for how entitlement policies work generally.

The default mode is RequireApproval — a customer’s plan change is captured as a request and held for review. Switch the entitlement to AutoApprove and the change applies immediately, but a request row is still recorded (reviewer “auto-approval”), so the audit trail is complete either way.

A few rules govern the requests themselves:

One pending request per entitlement — a second request is refused until the first is decided.
Requesting the plan the entitlement is already on, or an internal plan, is refused.
So is the plan a try offer on the same plan set issues its visitors’ licenses on. That plan is a taste rather than a tier — it stops at its allowance instead of charging past it — so an account landing on it would be worse off than on your entry plan.
The available plan set is snapshotted at submit, so you review exactly the options the customer saw — a plan-set revision published in between doesn’t change the options under review.
The requester is emailed when the request is received and again when it’s decided.

Reviewing the queue

Sales → Plan Requests is the queue. It opens on Pending — the ones waiting on you — and the status selector switches to Approved, Rejected or All when you need past decisions rather than the pending list.

Each row tells you what was asked and by whom:

Column	What it tells you
Requested	when the customer asked
Entitlement	which grant the change applies to
Change	the plan they are on and the plan they want
Requester	who asked
Status	Pending, Approved or Rejected
Reviewed	when it was decided — hover for the note that was left

Deciding a request

Approve or Reject on a pending row opens a short confirmation with an optional note. The note is shown to the requester, so it is the place to say why — “moving you to Scale from the 1st, as agreed” or “hold off until the current term ends”. A rejection without a reason reads as a system failure rather than a decision, so add one.

Approving applies the plan to the entitlement. The new plan’s feature values and quotas take effect, and the change appears on the entitlement’s Plan History alongside every other plan assignment, so there is a single audit trail whether a change was self-served or reviewed. Rejecting changes nothing; the customer stays on their current plan.

Where requests come from

Requests reach the queue from the customer side — your own application or the end-user portal — through the consumer API. Nothing in the admin portal creates one, which is deliberate: if you want to move a customer yourself, apply the plan directly from the entitlement’s Usage plans tab, no request needed.