Tenant Administration

Use the labeled sidebar to move between permitted work areas. Destinations are grouped by task; on smaller screens, the header navigation menu exposes the same choices. Open Settings for configuration and use breadcrumbs to return from a detail page. A visible destination does not replace its separate permission, branch-scope or availability checks.

The Settings hub groups destinations by outcome instead of presenting one long technical module list:

• Organization covers brand and identity, branches, the service catalog, and team access.
• Customer experience covers reviewed customer registration and customer-facing domains.
• Communications covers structured email and consent-aware messaging setup.
• Documents and billing covers document templates and online-payment setup.
• Advanced operations contains safety-gated capabilities such as private inspection video.

Open a destination card to make changes. Branch and service counts appear in their cards when verified. Badges identify paused, unavailable or setup-required states; empty groups are omitted. The hub is a navigation surface, and each destination rechecks your access.

The Brand and support workspace keeps tenant identity, contacts, customer copy and logo assets together. Choose a color or enter its hex value; Light and Dark previews update from your current edits before saving and preserve safe customer contrast. Staff styling is unchanged. Saving a changed tenant slug opens the new tenant address; update saved bookmarks.

Logo management accepts PNG, JPEG, or WebP, provides a 2:1 crop, and verifies/re-encodes the image before it becomes current. SVG is not accepted. Upload, preview and cleanup remain server-authorized; an unavailable logo section does not mean the saved brand details are empty. Refresh before retrying, and never copy signed image links or backend diagnostics into support notes.

Use Add branch, Add service package or Invite staff member to expand a creation form. Existing records remain visible without a full blank form above them.

The Branches workspace shows each location’s contact details, timezone, opening hours, booking intervals, capacity and status. Add every opening period, including periods before and after a break. Use Copy a day’s hours to apply all periods to selected days, then adjust exceptions. Copying replaces those days; save the branch to apply. Use Closes at midnight when needed. Days without a period are closed. Missing or unsupported saved hours pause online bookings until you configure them; walk-ins remain available. If saved hours cannot be edited, other changes keep them unchanged. Choose Replace opening hours only when you are ready to enter a complete schedule. Existing web address names stay unchanged; new ones are generated from the name and can be customized before saving.

The Service catalog workspace lets you set price, currency, duration, vehicle types, checklist items and branch availability. Add or remove checklist rows as needed; every saved row is shown. Each item can contain up to 180 characters. Unsupported older checklists or vehicle selections stay unchanged until you choose to replace them. Branch choices reflect your access.

If validation fails, the first field needing attention is focused and your draft stays in the form. Correct the highlighted fields and retry. Prices must use the selected currency’s decimal precision; extra decimal places are rejected rather than rounded. Saving temporarily disables editing. If someone else changed the same record, your save is stopped and your draft is kept. Compare it with the latest version in a separate tab, then reload and reapply only the changes still needed. After creation, choose Add another branch/service for a fresh form, or Open saved branch/service to edit it.

Tenant Admins own service-catalog creation and tenant-wide edits. Branch Managers can review only services and availability returned for their assigned branches; they do not receive catalog Save controls. The protected API rechecks both permission and all-branch scope for every mutation.

The People and access workspace separates current staff from invitation records and offers direct Staff members and Invitations views, a pending count, and search. Invite a person with one staff role and applicable branches. The first selected branch becomes primary; choose another selected branch when needed. Opening a staff member shows their tenant-local profile, role, branch access, and active/disabled state without exposing sign-in-provider identifiers. Resend, revoke, profile, role, and disable controls appear only when the signed-in Tenant Admin has the matching capability, and every submission is rebound, validated, ownership-checked, and audited by the server. Invitation links and provider failure details are not shown in this tenant workspace.

The Custom domains workspace shows only verified tenant-facing setup state: human status and guidance, the TXT host/value needed to prove control, safe timing and attempt summaries, and available actions. Request the bare hostname, publish the exact TXT proof, and run DNS checking. Activation and disable each require the canonical hostname plus ACTIVATE or DISABLE respectively. Tenant/user identifiers, stored metadata, provider or raw-DNS evidence, readiness internals, backend messages, and request IDs are not shown. Tenant-slug routing remains the fallback, and the server continues to own permissions, module readiness, tenant ownership, DNS resolution, status transitions, routing conflicts, and audit evidence.

The Email templates and delivery workspace groups service and identity emails, shows verified enabled/draft/published state, and preserves structured paragraphs, detail rows, system-link buttons, and footers. Choose a catalog item rather than editing templateType in the address. Preview uses Preview current edits without saving or sending email; save a draft, then publish when the desktop, mobile, and plain-text output are correct. Required identity templates cannot be disabled, and an unavailable delivery producer is separate from template validity. Provider diagnostics, credentials, one-time values, record identifiers, backend messages, and request IDs are not shown.

The Inspection videos workspace separates the tenant’s upload preference from actual availability. Save the preference, maximum size and allowed file types without a self-approval or evidence checklist. The current application has no working video safety-processing pipeline, so uploads and sharing stay unavailable even when the preference is on. Use photos or documents while that implementation is missing. Preference changes preserve review history and cannot release quarantined files. The workspace exposes no private media, provider evidence or backend diagnostics.

The Document templates workspace manages Invoice, Estimate, Inspection report, and Service history layouts as strict structured data. Choose the document from the catalog, then review its A4 margin, print signal, labels, supported blocks and order, content columns, safe text variables, and available tenant mark. Use Move up/down to order blocks and Preview current edits to inspect the rendered sample PDF without saving. Download the sample if it does not display. Publishing creates an immutable official version used only for future server-rendered documents. Logo upload/crop remains in Brand and support. Template identities, signed logo URLs, processing evidence, private artifacts, backend diagnostics, and request IDs are not shown.

The Online payments workspace separates payment requests from Test/Live checkout. Follow Set up online payments to save credentials, resolve configuration checks and explicitly enable the selected checkout environment. Changing credentials turns checkout off until the new setup is enabled. Provider/privacy review reminders remain separate from checkout activation and payment integrity.

Main areas

The Customer registration settings workspace separates tenant module availability from accepting new public requests. Select an active default branch; same-name choices include location and web address name to distinguish them. Explain the staff-review step in public terms copy, and open public intake only when a review owner is ready. Use Add a change note for an optional reason. Saving is fail-closed: Motornauts closes intake first, updates the tenant feature decision, and reopens intake only after server entitlement, dependency, readiness, branch-ownership, and permission checks pass. The workspace intentionally omits entitlement sources, raw readiness state/reasons/owners/next steps, internal branch identifiers, updater identities, backend diagnostics, and request IDs.

The separate Registrations workspace is for authorized staff decisions, not module setup. It uses the staff member’s current branch scope, shows the registration plate as the request anchor, and keeps applicant, contact, address, vehicle, consent, and review context together. Tenant Admin, Branch Manager, and Service Advisor access still depends on the explicit read/review permissions. A pending request must be refreshed before a confirmed approve or reject decision; linked profile, customer, vehicle, reviewer, tenant, and branch identifiers remain internal.

The public registration page is a separate customer-facing surface. It uses the tenant’s safe name, logo, support contact, and derived customer signal while keeping ink, focus, and status semantics platform-controlled. It clearly states that submission creates no portal access, retains ordinary values after a safe validation failure, and requires fresh bot verification for every retry. Public success and error states do not display applicant request references, duplicate-record evidence, readiness details, or backend diagnostics.

Use the Readiness Gates guide before telling staff or customers that a module is live. It lists the tenant-side fields, safe examples, completion signals, and support handoff points for setup-incomplete and provider-not-ready states.

Readiness cards intentionally use plain setup or verification guidance. They do not expose provider evidence, credential details, internal readiness codes, tenant identifiers, request IDs, or rollout phases. A module card being visible does not grant access: every destination and mutation rechecks TenantContext, permissions, entitlements, dependencies, and readiness on the server.

Tenant administration changes should be treated as operational decisions. Users should record support context for changes that affect access, customer visibility, pricing, or readiness. Feature-module changes are serialized per tenant: Motornauts rechecks dependencies at commit and preserves limit/metering settings that were not part of the change. If another module decision wins the race, refresh the module state before retrying rather than assuming both changes applied.

Each tenant staff member has one effective staff role across all of their selected branches. You can assign the same role to multiple branches, but Motornauts does not support simultaneous staff roles for one tenant membership. Change the member role and branch selections together when their responsibilities change. Tenant Admin is the exception to branch selection: it always has all-branch access within its tenant.

Revoking an invitation requires typing REVOKE; disabling active staff access requires typing DISABLE. A disabled membership remains in operational history. These confirmations reduce accidental changes but do not replace server permission, tenant ownership, branch scope, and audit enforcement. Refresh the workspace before retrying a stale invitation or member action.

Enter service prices as ordinary currency amounts, such as LKR 1,250.50. For LKR the maximum is 9,999,999.99. Motornauts rejects negative, oversized or overprecise amounts; it does not round them. The maximum and permitted decimal places depend on the selected currency.

Tenant and branch timezones must use valid IANA timezone identifiers. Tenant and service catalog currencies must use ISO-4217 currency codes, and the Phase 2 customer locale is en only. Payment providers can still be narrower than the catalog currency list; PayHere-backed online payment requests remain provider-gated and should not be treated as multi-currency-ready until provider, account-plan, and currency readiness say so.

Vehicle create and edit surfaces use the shared Motornauts maker catalog. Staff can keep reading older vehicle records that show a non-catalog make, but changing the make requires choosing a listed maker. Public registration requests and staff-created vehicle records reject unsupported makes, unsafe model characters, far-future years, and registration numbers outside the safe letters/digits/spaces/hyphens baseline.

When a public registration uses an email already linked to a tenant customer, approval is blocked. Use account recovery or a separately authorized staff-assisted identity-reconciliation process; never overwrite an existing customer’s login contact from public registration data. Staff profile names and phone numbers edited here are tenant-local display details. They do not change the person’s shared sign-in identity or their profile in another workshop. Email remains an identity-provider attribute; use the supported invitation or account-recovery workflow to change it.