Skip to content

Feature availability

Availability is not permission. A user needs the right role and the school must also pass the feature, plan, limit, and—in controlled cases—platform rollout checks.

FeatureFreeStarterProEnterpriseImportant condition
Learning PlansAvailableAvailableAvailableAvailableOptional; enable it for mutations and automation; retained history stays read-only when disabled
Parent portal—Default onDefault onDefault onRequires a valid parent invitation and linked child
PDF reports—Default onDefault onDefault onApplies only to supported PDF outputs
CSV export——Default onDefault onExport permissions and supported report still apply
API read access———Plan default onAlso requires service read rollout, an active eligible school, key, scopes, and quota
API write access———Default offRequires explicit feature enablement and separate service write rollout
School logo branding———Default onSupports the school logo in approved views; not full white-labeling or a custom domain

“Default on” describes the plan baseline, not a guarantee for a particular school. Waqar may apply an authorized school-specific override, and other eligibility or capacity controls may still deny the action.

Disabling Learning Plans is a containment control, not a deletion operation. Authorized staff retain the existing progress, plan, assignment, and report history under a read-only banner. Otherwise eligible API clients with learning_plans:read receive the same retained resources with X-Waqar-Feature-Mode: historical-read-only; all planning mutations remain blocked.

Plans can define soft and hard capacities such as active students, halqas, staff, storage, API keys, requests, or exports. A soft limit can warn before a hard limit blocks additional use. The relevant school screen is the authority for current usage and effective limits.

Removing or changing a plan does not authorize users to bypass a limit by duplicating schools, accounts, or records.

API eligibility is deliberately layered. In addition to the plan feature, the school must be active and eligible, platform rollout must allow the access class, the key must be active and unexpired, the request must meet network and scope policy, and quotas must permit it. Write eligibility is independent of read eligibility.

  1. Confirm the active school and your role.
  2. Check the school plan, feature display, and current limits.
  3. Check whether the feature needs school-level enablement, such as Learning Plans.
  4. For API access, check rollout and key policy separately.
  5. Ask an authorized administrator to review the effective setting; do not infer availability from a menu item, database name, or older announcement.