Subscription coverage and product access¶
Subscription status, workspace status and a person's permissions answer different questions. A plan may provide coverage while a particular person still lacks a product assignment. An administrator may also have billing recovery access while ordinary product use is blocked.
This page explains the newer backend coverage rules. It does not certify a connected frontend journey, a deployed payment provider or that every organization qualifies for automatic renewal.
Available, grace and blocked¶
| Coverage state | Meaning |
|---|---|
| Available | The current plan's commercial conditions permit product access at this instant. Tenant, account, membership, product and operation permissions still apply. |
| Grace | Paid coverage has ended, but a currently usable saved automatic-payment method permits a limited renewal grace period. This is not proof that renewal has succeeded. |
| Blocked | The current terms do not permit product access. The cause may be expiry, inactive workspace/subscription, missing reliable plan information or a plan change whose old authority has ended. |
Do not infer commercial access from a single label such as Active or Past Due. The platform evaluates the effective plan, precise coverage dates and current authority together.
Trial, paid and free plans have different boundaries¶
A trial permits access only before its recorded expiry. At the expiry instant it no longer qualifies under trial coverage. A saved payment method does not add the paid-renewal grace period to a trial.
A paid plan permits access before the end of its covered term. Without a usable saved automatic-payment method, that coverage ends at the exact expiry. Where the saved method is freshly verified as usable, paid renewal grace can last at most three days after expiry. It ends earlier if the method ceases to be valid or the old plan's effective authority ends. At the exact grace deadline, access is blocked under those terms.
For example, a paid term ending at noon on Monday could qualify until noon on Thursday. If its usable-method validity ends on Tuesday morning, that earlier boundary applies. This example describes the maximum conditional window, not an extra paid term or a guarantee that the provider will collect payment.
An enabled, non-trial free plan has no paid-through expiry. When such a plan is actually in effect, an old trial end date is not reused to block it. That does not mean every expired trial automatically moves to a free plan, nor that free-plan access bypasses tenant status or permissions.
Saved-method availability is checked when grace is needed¶
Current paid coverage does not require the platform to validate a saved method merely to remain available before expiry. Grace is different: saved-method details must still match the organization and the current stored version, remain usable and be enabled for automatic charging in the environment.
A missing, revoked, expired or unusable method cannot justify grace. If the authority needed to check it is unavailable, the platform reports that verification problem; it must not be explained to the reader as a proven declined payment. Neither a remembered checkbox nor an old successful payment alone establishes present eligibility.
See saved payment methods and renewal consent for recording limits, removal, delayed payment capture and separate cleanup.
Read plan dates carefully¶
The plan summary includes the applied plan's name, code, trial flag, expiry, displayed days to expiry and access state. The displayed days round up a partial remaining day and never go below zero. They are a convenience, not the access deadline: zero days may accompany grace or blocked access, and the exact timestamp still matters.
For a non-trial free plan the expiry and days fields are absent. Missing plan information is different from a free plan and should not be presented as unlimited or available by default. A later catalog name or price change does not by itself rewrite the organization's already applied plan snapshot.
Plan changes and existing sessions¶
A scheduled plan change creates a boundary for the old plan's authority. Its grace period cannot extend that old authority through the change. The platform must reconcile the current plan before granting access under the replacement terms. An open page or older permission result is not a promise that access will continue beyond these boundaries.
When access changes, ask the administrator to distinguish coverage expiry, plan transition, workspace suspension, payment verification and the person's own assignment. If a payment is unresolved, use the subscription retry explanation before another attempt. Payment acceptance, plan application and restored user access remain separate outcomes.
Read how a payment becomes subscription coverage for trial conversion, early and late renewal, calendar dates, invoices and the separate workspace-readiness steps.
If an existing connection closes¶
A connection opened before paid coverage expires can close at that expiry so a new connection checks current authority before using any grace period. Connections already in grace are checked again while they remain open. A successful later payment does not extend the original connection's recorded deadline in place.
Commercial access changes can also disconnect existing connections for the affected workspace, including idle ones. A disconnection by itself therefore does not prove that a payment failed or that access was permanently revoked. Reconnection still needs current workspace, account and product authority. The documentation does not promise a universal reconnect delay or prove that every deployed client handles it automatically.
If reconnecting fails, retain the workspace name, time and displayed message, and distinguish inability to verify access from confirmed expiry or suspension. Ask the administrator to inspect the current state before attempting another payment. An open page or old connection status is not a substitute for that check.
