Clinic Subscription Management Without Access Surprises

Clinic subscription management should give administrators a reliable answer to a practical question: which plan and modules can the clinic use today? CareClinic coordinates the subscription record, approved plan, optional modules, and recurring add-ons so those parts do not drift apart during a downgrade, renewal, or upgrade. That coordination matters when a clinic reaches a plan limit, enters a grace period, moves to Free, or returns to a paid plan.

The workflow is designed around clear ownership. A clinic administrator can review the plan and submit a change request. The Platform Admin reviews and applies the change. The system then reconciles the plan and its entitlements together. A scheduled lifecycle check handles reminders, grace periods, and overdue demotion, but it cannot use an old expired record to overwrite a newer approved subscription.

This article explains the advantages of that approach and the steps clinic and platform teams should coordinate. For current plan inclusions and capacity, start with CareClinic pricing and the CareClinic module list.

Why subscription coordination matters to daily clinic work

A subscription is not only a billing label. It can define the number of patients registered in a month, available staff accounts, storage, API access, and the optional modules included in the clinic workspace. If the plan says Enterprise while the module records still reflect Free, staff may see a plan change but remain unable to open the tools they expected. If an old expired subscription can take precedence over a newly approved one, a scheduled job may switch those tools off again.

That kind of mismatch creates operational confusion. A doctor may prepare to use Laboratory for a clinic session, only to find that the menu is unavailable. An administrator may enable Pharmacy after an upgrade and then discover that it disappeared the next day. The immediate symptom looks like a module problem, while the real cause sits in the relationship between subscription history, current plan status, and scheduled lifecycle processing.

CareClinic treats those records as one transition. The current subscription is selected using a defined order, and plan changes lock that selection while the new subscription is created. The tenant’s plan reference, module entitlements, and add-ons are reconciled in the same database transaction. If one required part fails, the transition does not leave a half-applied state.

For a clinic team, the benefit is a more dependable handoff. The plan shown after approval is the plan that governs module eligibility. For the Platform Admin, the benefit is one route for manual approvals and automatic demotions instead of several controllers and scheduled tasks applying different pieces of the change.

What happens when a paid plan reaches its end

CareClinic sends renewal reminders 15 days and 7 days before a paid term ends. If the plan is not renewed by the period end, the subscription moves to past_due and receives a seven-day grace period. The clinic retains access during that documented grace window, which gives the administrator time to coordinate renewal without an immediate interruption to paid-plan work.

The grace period is part of the current subscription state. It is not merely an email promise. The subscription remains discoverable by the application, and the access decision checks whether the grace end has passed. This distinction matters because a repository that reads only active subscriptions would make a valid grace period invisible to other parts of the system.

If the grace period ends without renewal, the scheduled lifecycle process moves the tenant to Free. That transition does four related jobs:

1. It retires the expired paid subscription and creates the current Free subscription.
2. It updates the clinic’s plan reference to Free.
3. It cancels recurring add-ons that should not continue after demotion.
4. It switches off optional modules that the Free plan does not include.

The clinic’s data is not deleted by this downgrade. Paid-only menus and routes become unavailable because their modules are off, but the records remain in the clinic workspace. When planning a renewal, administrators should still avoid promising staff that every paid workflow is available until the approved plan and module status have both been checked.

The public CareClinic user manual describes the reminder and grace schedule. Clinic administrators can use that section as the shared reference when coordinating with owners, doctors, and the CareClinic team.

A newer approved plan takes precedence over old history

Subscription history is useful for invoices, audits, and support. It becomes dangerous only when an older row can be mistaken for the current plan. Consider a clinic that has passed its paid grace period and is due to move to Free. Before the daily lifecycle job runs, the Platform Admin approves Enterprise and enables the required modules. The next scheduled check must recognize that Enterprise is now current.

CareClinic uses two safeguards for this case. First, the lifecycle query excludes an expired row when the same tenant has another active or trialing subscription. Second, the plan transition locks and rechecks the current subscription immediately before applying the change. The scheduled demotion carries the identifier of the expired subscription it selected. If the locked current identifier is different because an upgrade replaced it, the demotion stops.

This protects the outcome that matters to the clinic: the approved Enterprise plan remains current after the next lifecycle run. It also makes repeated scheduled runs safe. A job can encounter historical subscription records without treating them as permission to reverse a newer decision.

CareClinic includes a data migration for earlier records that may contain both an old past_due subscription and a newer active or trialing one. The migration retires the superseded past-due row and adds an index for current-subscription and lifecycle lookups. Platform operators should apply that migration before relying on the revised lifecycle behavior in an existing environment.

Plan changes follow a request and approval handoff

A clinic user should not be able to change the plan merely by updating a general tenant field. That would change a label without coordinating billing, subscriptions, modules, or Platform Admin review. CareClinic now directs tenant plan changes through the subscription workflow and rejects plan_id on the general tenant update endpoint.

The clinic-side sequence is straightforward:

1. A clinic administrator opens Subscription > Plans.
2. The administrator selects the requested plan and billing cycle.
3. CareClinic records a pending request rather than activating the plan immediately.
4. The Platform Admin reviews the request and applies the approved transition.
5. The clinic administrator checks Subscription for the current plan and Settings > Modules for feature status.

Only one plan-change request can wait for review at a time. This prevents two pending requests from competing for the same clinic. If the administrator changes their mind, they should coordinate with the CareClinic team handling the pending request instead of submitting several alternatives.

The request boundary also improves accountability. Clinic administrators control what they ask for, while the Platform Admin controls what the platform applies. Billing arrangements, plan capacity, and module requirements can be confirmed before the workspace changes. The CareClinic contact page provides a direct route when the request needs context that does not fit the plan selector.

Module access follows the current plan or an active add-on

Optional modules support distinct workflows such as laboratory orders and results, pharmacy inventory, imaging, accounting, and reporting. Enabling one can expose new menus, routes, and setup tasks. The ability to switch on a module therefore needs to follow the clinic’s approved commercial entitlement.

CareClinic checks two sources before a tenant enables a module:

• The current access-granting subscription includes the module in its plan.
• An active module add-on covers that specific module.

Enterprise uses an all-modules entitlement. Other plans list the modules they include. If neither the plan nor an active add-on covers the requested module, the tenant-facing API refuses the enable action. This prevents a direct request from bypassing the same plan rules shown in the interface.

The clinic’s Settings > Modules page is a status view. It shows what is switched on but does not itself activate a new commercial entitlement. An administrator requests an add-on from Subscription > Subscription > Add-ons or contacts the CareClinic team. This detail is important for onboarding: telling staff to keep clicking a disabled module switch sends them to the wrong owner of the decision.

After a downgrade to Free, recurring add-ons are cancelled and modules outside the Free plan are disabled. After an upgrade, the approved plan establishes which modules are eligible. The Platform Admin can then coordinate the modules required by the clinic. System modules that the application needs for core operation remain protected from being switched off.

Module status and role permissions answer different questions. A module decides whether the clinic has the feature. Permissions decide which signed-in people can use actions inside it. If a doctor cannot open a feature after the module is confirmed, the administrator should review the person’s role rather than requesting the module again. The security and privacy controls explain the broader role and access model.

Proper coordination before and after a plan change

The strongest technical transition still needs a short operational check. Clinic administrators know which services are scheduled. Platform administrators know when the plan and billing decision will be applied. Doctors and staff know which tools their next shift depends on. Bringing those views together prevents a correct system change from becoming a surprise at the point of care.

Use this checklist for an upgrade, renewal, or downgrade:

A role-appropriate test does not require entering patient information. For example, an administrator can confirm that the expected module appears as enabled, while an authorized staff member confirms that its landing page opens. Clinics should not create dummy clinical records in a production workspace merely to test a plan change.

If a module is not present after approval, capture the clinic name, requested plan, approval time, and missing module. Do not send patient details. That information lets the platform team compare the approved plan with the current subscription and module status without introducing protected health information into a support message.

How this design improves support and recovery

Coordinated subscription management narrows the number of states a support team must investigate. The current subscription and tenant plan should agree. Modules should fit the current plan or active add-ons. A scheduled demotion should point to the same expired subscription that was current when the job selected it.

Those invariants make a support case easier to classify. If the plan request is still pending, the clinic continues on its current plan by design. If approval is complete but a module is not enabled, the Platform Admin can review the entitlement and module step. If the clinic is in grace, access should remain until the recorded grace end. If grace has passed without renewal, Free and its included modules are the expected state.

The transaction boundary also improves recovery from technical failure. Subscription replacement, tenant-plan synchronization, add-on cancellation, and module reconciliation commit together when the service owns the transaction. An exception rolls the transaction back instead of preserving only the first few changes. This does not remove the need for monitoring, backups, or migration discipline, but it reduces the chance of an internally inconsistent plan transition.

The daily lifecycle process should run on schedule. Platform operators should monitor its errors and apply platform migrations in deployment order. A corrected application cannot repair old records if its data migration is skipped, and renewal reminders cannot arrive if the scheduled command is not running.

What clinic leaders gain from a clearer plan lifecycle

The main advantage is predictability. A clinic can see its current plan, understand the grace window, and know why a module is available or unavailable. A new approval cannot be silently undone by an older expired subscription during the next daily check. Direct API calls cannot switch on a module the clinic has not purchased. General tenant updates cannot bypass the reviewed plan-change route.

That predictability supports better planning. Administrators can coordinate renewal before grace ends. Doctors can confirm required tools before a session. Platform staff can apply one transition and verify one resulting state. When a clinic moves to Free, paid modules switch off without deleting clinic data. When it upgrades, the current approved subscription becomes the authority for module eligibility.

Clinic software still depends on human handoffs. CareClinic makes those handoffs visible: request, review, apply, confirm. Use CareClinic pricing to compare capacity and plan inclusions, then coordinate optional module needs with the platform team before the date your staff need them.

Explore the CareClinic clinic management system and plan a subscription workflow that keeps administrators, doctors, and platform operations working from the same approved state.