SolarOps Main Backoffice Manual

Version: 1.1 release-readiness candidate Date: 2026-07-18 Audience: SolarOps platform, support, billing and content administrators Environment: https://www.solarops.cloud Verified role: SUPER ADMIN

> Release notice: Package, promotion, public pricing, Paystack Test plan creation, callback/webhook settings, Knowledge Base drafting, Zoho demo evidence and desktop screenshots were browser-verified. Billing, package, Knowledge Base and bounded support-access repairs are verified in source and automated tests. Production migration, deployment, tenant entry, mobile capture and Paystack Test payment events remain incomplete.

Contents

1. Main Backoffice Overview 2. Main Backoffice Dashboard 3. Tenant Management 4. Package Management 5. Subscription Management 6. Add-ons and Temporary Access 7. Promotions 8. Platform Users and Permissions 9. Platform Support Administration 10. Knowledge Base Administration 11. Landing-page Management 12. Paystack Administration 13. Zoho Platform Administration 14. Affiliate and Reseller Administration 15. Platform Settings 16. Main Backoffice Troubleshooting

1. Main Backoffice Overview

UAT status: Passed for access and routing

Purpose. Main Backoffice administers the SolarOps platform across subscribers. Tenant work remains inside each subscriber context.

Who uses it. Authorised platform administrators only.

Before you begin. Confirm /account shows Main Backoffice and the role is appropriate. Do not enter or change another tenant unless explicitly authorised.

Steps.

1. Sign in and open /account. 2. Select Main Backoffice. 3. Confirm the header says SolarOps Main Backoffice. 4. Confirm the role badge; this pass displayed SUPER ADMIN. 5. Use Tenant switch to return to the account chooser and My Account for platform-account security. 6. Use Sign out only when the session should end.

Expected result. /backoffice opens without redirecting into a tenant.

Screenshot.

Screenshot captured: SolarOps protected platform administration overview.

Common problems. A platform user opening a tenant by default indicates context or membership routing that requires investigation.

Related features. Platform users, tenant management and audit responsibility.

Permissions. Platform access plus the relevant PLATFORM_* permission.

Mobile notes. Main Backoffice mobile layout was not tested.

2. Main Backoffice Dashboard

UAT status: Passed for load and summary values

Purpose. The dashboard provides platform-level subscriber and billing context.

Who uses it. Platform, support and billing administrators.

Before you begin. Treat counts as time-specific operational data.

Steps.

1. Open /backoffice. 2. Review subscriber, subscription, trial and package exception summaries. 3. Use the navigation groups to open subscriber, content and administration areas. 4. Investigate counts through the corresponding list rather than editing from assumptions.

Expected result. During this pass the dashboard showed 3 subscriber companies, 0 active subscriptions, 2 trials and 1 subscriber without a package. Billing mode was Manual.

Screenshot.

Screenshot captured: SolarOps platform dashboard with subscriber and subscription summaries.

Common problems. Zero active subscriptions does not mean billing is configured; compare subscription records and provider status.

Related features. Tenants, subscriptions, packages and platform settings.

Permissions. Platform dashboard access.

Mobile notes. Not tested at 390 x 844.

3. Tenant Management

UAT status: Partially Passed

Purpose. Tenant management reviews subscriber status, package, subscription, usage, features, support and temporary access.

Who uses it. Platform support, billing and administrators.

Before you begin. Confirm the authorised company. This pass was restricted to Sorted.

Steps.

1. Open Subscribers -> Companies. 2. Select Sorted. 3. Review company ID, status, package, users, projects, documents, currency, time zone, trial and billing source. 4. Use package, status, add-on, promotion or entitlement controls only with approval. 5. Grant support access is the supported temporary-access control; provide a reason and bounded duration. 6. Return through Tenant switch when support work is complete.

Expected result. Sorted displayed company ID cmqntl9gq0001kz04p3n9waws, status TRIAL, package Trial, 4 users, 4 projects, 3 documents, ZAR, UTC, trial ended 2026-07-05 and billing source NONE.

Screenshot.

Screenshot captured: SolarOps account chooser showing the platform context and no Sorted tenant membership.

Common problems. A direct /sorted request returned 404 for the platform-only session. Bounded support access is implemented in source with reason, start, expiry, audit and explicit session ending, but it was not deployed or exercised.

Related features. Packages, subscriptions, add-ons, promotions and support.

Permissions. Subscriber view/manage and support-access permissions.

Mobile notes. Not tested.

4. Package Management

UAT status: Passed for create, duplicate, edit, persistence and public display

Purpose. Packages define commercial price, limits, features, trial, support level, provider references and public presentation.

Who uses it. Platform package and billing administrators.

Before you begin. Package records are the SolarOps source of truth. Paystack collects payments; it must not become the entitlement engine.

Steps to create or edit a package.

1. Open Subscribers -> Packages & Plans. 2. Use the package form to enter Name, descriptions and public card text. 3. Set ZAR billing currency, launch monthly price, standard monthly price, annual price and approximate display-currency values. 4. Set trial days and each user/storage/warehouse/branch/project/client/inventory limit as numeric, unlimited or custom. 5. Select the included feature checkboxes. 6. Set support level, grace days, sort order, public/featured flags and active status. 7. After migration and deployment, enter separate verified Paystack Test mappings for introductory monthly, standard monthly and annual phases. 8. Save the package. 9. Reopen it and verify every persisted value. 10. Open /pricing to confirm intended public output.

Steps to duplicate.

1. Open the source package. 2. Use the visible duplication control. 3. Change name, description, prices, limits, features and public text. 4. Save and reopen.

Configured examples.

| Package | Launch monthly | Standard monthly | Annual | Trial | Users | Warehouses | Projects | Storage | Public | Featured | | --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | --- | --- | | Solo | R299 | R499 | R4,990 | 14 days | 2 | 1 | 10 | 5 GB | Yes | No | | Starter | R599 | R899 | R8,990 | 14 days | 5 | 2 | 30 | 15 GB | Yes | No | | Growth | R999 | R1,499 | R14,990 | 14 days | 15 | 5 | 100 | 50 GB | Yes | Yes | | Professional | R1,799 | R2,499 | R24,990 | 14 days | 40 | 10 | 300 | 150 GB | Yes | No | | Enterprise | R3,499 | R4,999 | R49,990 | 14 days | Custom | Custom | Custom | 500 GB+ | Yes | No |

Expected result. All five records reopened with the configured prices, limits, features and visibility. Growth appears first on public pricing because it is featured. The legacy Trial package remains active for existing data but is no longer public.

Screenshot.

Screenshot captured: SolarOps Growth package editor in the deployed administration interface.

Common problems.

- The deployed editor is still the legacy one-currency, two-plan-code interface. The repaired source separates ZAR billing values, approximate display values and three provider phases. - Phase mappings must not be entered until the additive migration and source deployment are complete. - The deployed Enterprise record still uses practical numeric stand-ins. The repaired source supports explicit custom and unlimited limit modes. - Package audit history and safe deactivate-with-subscribers behaviour were not tested.

Related features. Promotions, public pricing, subscriptions and add-ons.

Permissions. Package management.

Mobile notes. Use desktop until the package editor is mobile-verified.

5. Subscription Management

UAT status: Source lifecycle Passed; browser subscription workflow Not Tested

Purpose. Subscription administration should manage trial, active, paused, cancelled, overdue, free, custom and provider-backed states without deleting tenant data.

Who uses it. Billing and platform administrators.

Before you begin. Confirm the tenant, package, cycle, price, provider mode and effective date. Never move existing subscribers during a configuration test.

Steps. Exact subscription mutation steps are withheld. Retest must cover manual EFT, invoicing, Paystack, package changes, renewal, temporary full access and any scheduled changes using an approved test subscription only.

Expected result. One auditable subscription state is authoritative and access follows policy.

Screenshot. No disposable subscription was created.

Common problems. The deployed model is still legacy. The repaired source adds introductory phase, successful-cycle count, transition timestamps, provider references and recovery fields; do not administer these as live capabilities before migration and deployment.

Related features. Packages, promotions, add-ons and Paystack.

Permissions. Subscription and billing management.

Mobile notes. Not tested.

6. Add-ons and Temporary Access

UAT status: Partially Passed for control availability; mutations Not Tested

Purpose. Add-ons and temporary access extend selected entitlements without changing the base package or payment plan unnecessarily.

Who uses it. Platform and support administrators.

Before you begin. Reuse an existing add-on where appropriate. Specify reason, start, expiry and expected removal behaviour.

Steps.

1. Use Add-ons for the reusable add-on catalogue. 2. Open the authorised subscriber to assign or remove approved add-ons. 3. Use bounded temporary access for support or promotion access. 4. Verify entitlement and expiry without altering Paystack billing for free feature access.

Expected result. Entitlements change only for the chosen tenant and are auditable.

Screenshot. Not captured.

Common problems. Duplicate add-ons, no expiry, Paystack billing changed for a free entitlement and no audit history.

Related features. Packages, tenants and promotions.

Permissions. Add-on and subscriber entitlement management.

Mobile notes. Not tested.

7. Promotions

UAT status: Browser configuration Passed; source lifecycle Passed; deployed payment transition Not Tested

Purpose. Promotions describe offers independently of the base package.

Who uses it. Platform billing and marketing administrators.

Before you begin. Confirm the package, currency, cycle, eligibility, dates, redemption limits and whether the engine can enforce the terms.

Steps.

1. Open Subscribers -> Promotions. 2. Enter Name and a unique Slug. 3. Choose ACTIVE and INTRODUCTORY_PRICE. 4. Enter Intro price, Renewal price, Currency ZAR and Billing cycle MONTHLY. 5. Set the start date and per-customer limit. 6. Select New customers only. 7. Select exactly one eligible package. 8. Set the promotion end date to 2026-12-31. 9. Leave Auto apply off until the repaired source is migrated, deployed and mapped to verified provider plans. 10. Describe the first three successful monthly billing cycles and standard price. 11. Save and verify the offer on /pricing.

Configured promotions.

| Promotion | Package | Intro | Renewal | Starts | Ends | Auto apply | | --- | --- | ---: | ---: | --- | --- | --- | | MANUAL-UAT - Solo Launch Pricing | Solo | R299 | R499 | 2026-07-18 | 2026-12-31 | No | | MANUAL-UAT - Starter Launch Pricing | Starter | R599 | R899 | 2026-07-18 | 2026-12-31 | No | | MANUAL-UAT - Growth Launch Pricing | Growth | R999 | R1,499 | 2026-07-18 | 2026-12-31 | No | | MANUAL-UAT - Professional Launch Pricing | Professional | R1,799 | R2,499 | 2026-07-18 | 2026-12-31 | No | | MANUAL-UAT - Enterprise Launch Pricing | Enterprise | R3,499 | R4,999 | 2026-07-18 | 2026-12-31 | No |

Expected result. All five offers persisted as active, monthly, new-customer promotions with zero redemptions and appeared beside the correct public package.

Screenshot.

Screenshot captured: Five active SolarOps launch-pricing promotions ending 31 December 2026.

Common problems. The deployed form still lacks the new successful-cycle and mapping controls. The source schema and services now model duration, phase, successful-payment count, idempotent transition and failed-payment access states. Do not enable automatic application before migration, deployment and Test event verification.

Related features. Packages, pricing, subscriptions and Paystack.

Permissions. Promotion management.

Mobile notes. Admin form not tested on mobile.

8. Platform Users and Permissions

UAT status: Partially Passed for current role; user mutation Not Tested

Purpose. Platform roles separate super administration, support, billing, content and reseller responsibilities.

Who uses it. Super Administrators.

Before you begin. Apply least privilege and do not modify real users without a restoration plan.

Steps. Use Subscriber & Platform Users to review the appropriate account. Adding, deactivating and reassigning platform roles were not tested.

Expected result. The current account displayed SUPER ADMIN and could open Main Backoffice.

Screenshot. Not captured.

Common problems. Platform permission names appearing in tenant roles, stale access after deactivation and excessive default permissions.

Related features. Tenant isolation, audit and support access.

Permissions. Platform user management.

Mobile notes. Not tested.

9. Platform Support Administration

UAT status: Support route captured; bounded access policy source-tested; ticket lifecycle Not Tested

Purpose. Platform support should triage tenant-linked tickets, assignment, priority, notes, escalation and resolution.

Who uses it. Platform support administrators.

Before you begin. Confirm tenant authorisation before opening data.

Steps. The Support route loaded and was captured. The source now requires a reason and bounded duration for tenant support access, records start/end audit events, rejects expired access and provides an explicit end-session action. No support ticket lifecycle or tenant entry was browser-tested.

Expected result. Support records remain tenant-linked and internal notes are protected.

Screenshot.

Screenshot captured: SolarOps protected support administration route.

Common problems. Missing tenant link, internal notes exposed, no escalation history and unresolved tickets closed.

Related features. Tenant management and temporary access.

Permissions. Platform support management.

Mobile notes. Not tested.

10. Knowledge Base Administration

UAT status: Six drafts created; source administration and access controls Passed; image upload Blocked

Purpose. Knowledge Base administration manages categories, articles, tags, visibility, attachments, drafts and publication.

Who uses it. Platform content administrators.

Before you begin. Only publish browser-verified instructions. Main Backoffice procedures must be internal.

Steps.

1. Open Support & Content -> Knowledge Base. 2. Choose or create an appropriate category. 3. Enter a descriptive title, summary/body, tags, audience, role requirements and related articles. 4. Use PUBLIC, TENANT, SELECTED_ROLES or PLATFORM_ADMIN in the repaired interface. 5. Save incomplete or deployment-dependent content as a draft. 6. Upload only safe screenshots, add alt text and captions, and confirm the immediate preview. 7. Use protected draft preview and revision history before publication. 8. Test search, package/module filters and server-side visibility before publishing.

Expected result. Six labelled drafts were created in the deployed legacy editor and remain unpublished: pricing, package configuration, Paystack Test plans, three-payment transition, failed-payment access and Zoho demo expense. The repaired source adds categories, status, audiences, selected roles, revisions, protected preview, image alt/caption fields, search and server-side access filtering.

Screenshot.

Screenshot captured: SolarOps Knowledge Base administration with saved draft content.

Common problems. Publishing internal instructions publicly, using legacy visibility values after migration, broken image preview, missing alt text and instructions that do not match the deployed UI. Image upload remained blocked because the ChatGPT Chrome extension did not have file-URL access.

Related features. Public Knowledge Base, screenshots and manuals.

Permissions. Knowledge Base/content management.

Mobile notes. Authoring should use desktop until verified.

11. Landing-page Management

UAT status: Passed for package and promotion propagation; content editing Not Tested

Purpose. Public-site administration controls pricing, offers, contact details and legal/support content.

Who uses it. Platform content and package administrators.

Before you begin. Public changes are immediate customer-facing claims.

Steps.

1. Update package public fields through Packages & Plans. 2. Update offers through Promotions. 3. Save and reopen the source record. 4. Open /pricing and verify public wording, order and visibility. 5. Use dedicated contact/legal controls for business information rather than hard-coded changes.

Expected result. All five configured packages and five offers appeared immediately; the hidden Trial package card did not.

Screenshot.

Screenshot captured: SolarOps public pricing generated from package and promotion configuration.

Common problems. Featured cards change order; blanking inherited marketing text may not clear as expected. Professional required an explicit Priority support badge.

Related features. Packages, promotions, contact details and legal pages.

Permissions. Public-site and package/content management.

Mobile notes. Public mobile layout not captured.

12. Paystack Administration

UAT status: Test plan and endpoint configuration Passed; payment-event lifecycle Not Tested

Purpose. Paystack collects ZAR payments. SolarOps remains responsible for package entitlements, promotions, lifecycle policy and audit.

Who uses it. Billing administrators.

Before you begin. Confirm the dashboard visibly says Test. Never reveal keys, charge a real customer or alter an existing real subscription.

Verified steps.

1. Open the authenticated Paystack SolarOps business. 2. Confirm the dashboard visibly says Test before every write. 3. Create five Launch monthly plans with a maximum of three invoices. 4. Create five uncapped Standard monthly plans. 5. Create five uncapped Annual plans using the Annually interval. 6. Reopen the consolidated plan list and verify names, codes, ZAR amounts, intervals and zero subscriptions/revenue. 7. Set the Test callback URL to https://www.solarops.cloud/billing/paystack/callback. 8. Set the Test webhook URL to https://www.solarops.cloud/api/webhooks/paystack. 9. Do not expose API keys and do not run a payment or create a subscription during documentation-only configuration.

Observed result. All 15 required Paystack Test plans were created exactly once. Launch plans have a three-invoice limit; Standard monthly and Annual plans are uncapped. The plan list showed zero subscriptions and zero revenue. Callback and webhook URLs were saved. No charge, checkout, subscription or webhook event was executed.

Required plan set. See paystack-plan-mapping-register.md.

Source verification result.

- Secret-key operations are server-side. - Transaction verification, HMAC SHA-512 signature checks and duplicate-event protection are preserved. - Provider mappings are phase-aware for INTRODUCTORY, STANDARD and ANNUAL, with environment, amount, currency, interval and verification state. - Checkout rejects missing, mismatched or unverified mappings. - Successful events count introductory cycles idempotently and prepare one standard-plan transition after the third success. - Reusable authorisation and cancellation values are encrypted before storage. - Failed-payment states and the billing recovery cron are represented and unit-tested.

Expected result. After the additive migration and source deployment, enter the 15 verified codes in their exact Test phase mappings. Then run approved Test checkout, duplicate webhook, three-success transition, cancellation and failed-payment recovery tests.

Screenshots.

Screenshot captured: Paystack Test plan list showing all 15 SolarOps plans with zero subscriptions and zero revenue.

Screenshot captured: Paystack Test detail for the Growth Launch plan at R999 monthly with three invoices.

Common problems. Never use a launch invoice limit as the complete SolarOps transition engine. Never map a Test code into Live, or a Launch code into the Standard phase. The current deployed package editor is the old two-field interface; mapping remains pending until migration and deployment.

Related features. Packages, promotions, subscriptions and failed-payment policy.

Permissions. Billing administration and server-side provider configuration.

Mobile notes. Provider administration is desktop-only unless Paystack documents otherwise.

13. Zoho Platform Administration

UAT status: Partially Passed on Zoho side; SolarOps side Blocked

Purpose. Platform integration administration supports tenant connection status, callback, mappings, catalogue/customer sync and errors.

Who uses it. Platform integration and tenant accounting administrators.

Before you begin. Confirm the tenant and Zoho organisation; avoid bulk operations.

Steps.

1. Review the authenticated Zoho organisation. 2. Confirm Sorted and the safe labelled UAT expense. 3. Do not expose or change tokens. 4. SolarOps integration status, callback, catalogue staging, mappings, duplicate prevention, sync errors and disconnect require a tenant-access retest.

Expected result. Zoho organisation Sorted and Free plan were verified. SolarOps integration behaviour remains unverified.

Screenshot.

Screenshot captured: Zoho Books Sorted demo organisation showing the labelled UAT expense.

Common problems. Wrong tenant/organisation, bulk overwrite, duplicate records and token leakage.

Related features. Tenant accounting, product catalogue and sales.

Permissions. Platform/tenant integration administration.

Mobile notes. Not tested.

14. Affiliate and Reseller Administration

UAT status: Not Tested

Purpose. Reseller administration should manage attribution, referral, leads, customers, commissions, payouts, packages, profile, material and support.

Who uses it. Reseller and platform administrators.

Before you begin. Confirm the commercial programme and approved test reseller.

Steps. A Resellers navigation entry was visible, but no workflow was attempted.

Expected result. Referral and payout data are auditable and tenant attribution is explicit.

Screenshot. Not captured.

Common problems. Missing dashboard, incorrect attribution, unauthorised payout controls and public exposure.

Related features. Tenants, packages and billing.

Permissions. Reseller administration.

Mobile notes. Not tested.

15. Platform Settings

UAT status: Not Tested

Purpose. Platform settings govern defaults, branding, contact data, communications, payment/accounting integrations, notifications and audit.

Who uses it. Super Administrators and narrowly authorised specialists.

Before you begin. Record current values and impact. Never paste secrets into browser-visible general settings.

Steps. Routes for settings, integrations, contact details and service configuration exist, but no settings were changed.

Expected result. Each change is validated, auditable and reflected only in its intended surface.

Screenshot. Not captured.

Common problems. Missing menu entries, hard-coded public information, secrets in client-visible fields and unaudited changes.

Related features. Public site, Paystack, Zoho, support and packages.

Permissions. Relevant platform settings permission.

Mobile notes. Not tested.

16. Main Backoffice Troubleshooting

UAT status: Operational guidance

Purpose. Resolve platform issues without weakening tenant isolation or billing controls.

Who uses it. Platform administrators.

Before you begin. Record role, route, subscriber, timestamp and safe error details.

Steps and common problems.

1. Platform user opens a tenant: return to /account; review platform access and tenant memberships separately. 2. Package controls missing: verify the platform permission; do not grant tenant permissions as a workaround. 3. Package does not save: preserve entered values, record validation, reopen the page and file a bug before retrying. 4. Subscriber cannot be edited: confirm exact subscriber and permission; do not alter database records directly. 5. Add-on does not apply: verify source package, tenant assignment, dates and entitlement audit. 6. Pricing does not update: reopen the package/promotion, confirm public/active flags and check /pricing. 7. Promotion does not expire or transition: current model lacks successful-cycle logic; leave auto-apply off. 8. Knowledge Base image does not register: keep the article draft and record upload/preview evidence. 9. Public article does not display: check visibility and published state. 10. Affiliate page is broken: record the route and do not invent a replacement programme. 11. Paystack status is incorrect: confirm Test/Live visibly; never infer from plan names. 12. Zoho unavailable: verify the authorised organisation without exposing tokens. 13. Settings missing: compare role permissions and navigation registration; test direct-route protection.

Expected result. The issue is isolated and recorded without destructive data or permission changes.

Screenshot. Not applicable.

Related features. UAT matrix and bug register.

Permissions. Troubleshooting does not grant additional rights.

Mobile notes. Include viewport in any mobile issue.

Administrator Safety Checklist

- Confirm context and subscriber before every mutation. - Use Paystack Test mode only for UAT. - Do not expose secrets or customer data. - Do not migrate existing subscribers during package setup. - Keep Auto apply off until migration, deployment, phase mappings and Test payment-event evidence are complete. - Map Test plan codes only to the matching environment, package and phase after deployment. - Keep deployment-dependent or unverified Knowledge Base content unpublished. - Record bugs before attempting source changes. - Do not commit, push, merge or deploy without approval.