Operate your customer app with confidence.

Open the tenant’s administration hostname and sign in with the email address and password assigned by the tenant owner or GoApps during handoff. Customer mobile accounts use phone verification; those credentials do not grant administrative access.

The app type set during provisioning changes both the language and the management permission used for content.

A missing navigation item normally means either the feature is not enabled for the tenant or the current member lacks the relevant permission.

Access requires both layers to allow an action:

1. Tenant entitlement: GoApps enables the capability for the tenant during provisioning.
2. Member permission: An owner grants the capability to a manager or staff account.

Owners receive all member permissions, but a capability can still be unavailable when it is not part of the tenant’s entitlements. This prevents a local account from turning on a product feature that has not been provisioned.

A dash means the signed-in member cannot load that metric. It is not the same as zero.

Select Refresh in the top bar after another teammate makes a change. The workspace reloads only the datasets the current account can access. Recent activity combines the latest content updates and broadcasts; it is an operational summary rather than a complete audit log.

Field reference

• Use a clear subject with breathing room around the edges.
• Prefer a landscape or square composition that survives card cropping.
• Avoid putting critical prices or terms inside the image; keep them in editable fields.
• Upload directly from the device. The workspace stores the file and records the resulting asset URL automatically.
• Remove the selected image before saving if the item should have no image.

• Edit: update any customer-facing fields and save. The Updated timestamp changes.
• Hide: use the eye action to remove an item from the mobile feed without deleting its record.
• Republish: use the eye action again. Verify time-sensitive details before making an old item visible.
• Delete: permanently removes the item after confirmation. Prefer hiding when the item may return.

Search matches item names and descriptions. Category options are built from existing items. Establish a small approved category vocabulary before adding many records—for example, Mains, Sides, Drinks, and Desserts rather than several variations of the same label.

Broadcast history records the title, message, status, creation time, and creator. A queued result confirms that GoApps accepted the campaign for background delivery; it does not guarantee that every device displayed the notification. Delivery also depends on registered device tokens, notification permission, provider availability, and device connectivity.

Recommended message pattern

Title: specific event or benefit. Body: essential detail plus one action. Destination: the exact in-app screen that completes that action.

Search uses the customer’s phone number. Filter by Active or Disabled to narrow the table.

• Disable when access should be stopped. The account remains recorded but cannot be treated as an active account.
• Enable when the reason for restriction has been resolved.
• Joined shows account creation time; Last active reflects the latest recorded login.

The branding page updates the remotely configured splash experience. Store listing artwork, installed app icons, native launch screens, bundle identifiers, and store names belong to the signed mobile release and require a separate build-and-publish cycle.

Owners have all member permissions. Manager and Staff permissions come from the selected checkboxes and remain bounded by tenant entitlements.

Before opening

• Confirm prices, availability, service details, and active promotions.
• Hide items that should not be visible today.
• Review scheduled customer communications outside the platform, if used.

Before a broadcast

• Have a second person verify the title, dates, price, audience, and link.
• Confirm the destination works in the current production app.
• Verify the image contains no outdated information.

Monthly

• Review team membership and remove unnecessary privileges through the responsible owner or GoApps support.
• Review disabled users and confirm restrictions remain justified.
• Check branding and key content on a physical customer device.

• Sign out when using a shared or borrowed device.
• Do not save administrator passwords in shared browser profiles.
• Use separate accounts rather than sharing an owner login.
• Treat downloaded or copied customer data according to the organisation’s privacy rules.
• If an account may be compromised, stop using it and contact the tenant owner or GoApps administrator.

The Super Admin console uses the configured platform administrator password. A successful sign-in creates a signed session token valid for approximately eight hours and stores it in the current browser profile.

• Total tenants: every tenant record returned by the control database.
• Draft: manifests created but not marked active by the broader deployment lifecycle.
• Active: records whose stored status is active.
• App types: number of distinct vertical types represented.

Recent tenants shows the five newest records. Portfolio by type compares restaurant, boutique, salon, insurance, and generic records.

Search matches company name, tenant ID, and admin hostname. The type filter limits results to one app vertical. The table shows the tenant, app type, hostname, feature count, status, and manifest action.

Select View manifest to inspect the stored JSON. Use Copy JSON for a controlled handoff into another tool, or Download manifest to save a file named with the tenant ID. Treat manifests as operational configuration: verify the tenant identity before using one for deployment.

• Legal or trading company name and approved customer-facing app name.
• Best-fit app type: restaurant, boutique, salon, insurance, or generic.
• Approved company logo in JPG, PNG, WebP, or GIF under 8 MB.
• Unique tenant slug, admin subdomain, Android application ID, and iOS bundle ID strategy.
• Owner name, email, and optional phone number.
• Contracted feature entitlements and any features intentionally excluded.
• Production domain ownership, mobile signing ownership, and store-account ownership.
• SMS, push, and other provider requirements for the tenant’s launch market.

Tenant ID or subdomain conflicts return an error and do not create a duplicate record.

Use one canonical tenant slug everywhere. For example, acme-kitchen can produce:

• Tenant ID: acme-kitchen
• Admin hostname: acme-kitchen.goapps.com.gh
• Mobile ID: com.goapps.acmekitchen
• Worker: goapps-acme-kitchen-prod
• D1 database: goapps_acme_kitchen_prod
• R2 bucket: goapps-acme-kitchen-assets-prod

• Tenant identity: tenant ID, company name, app type, app ID, logo, hostname, and rights.
• Owner seed: name, email, and optional phone number.
• Cloudflare names: Worker, D1, R2, SMS queue, notification queue, and custom domain.
• Runtime variables: tenant, app, environment, public URL, splash defaults, and SMS sender.
• Database seed intent: tenant rights and owner admin email.

• Re-open the saved tenant and compare the manifest to the approved intake.
• Store the manifest in the approved configuration repository or deployment system.
• Transfer owner setup instructions through a secure channel.
• Record who owns Android, iOS, domain, and provider credentials.
• Confirm production secrets are created outside the manifest.
• Do not send platform credentials to the tenant.

Each white-label tenant receives a unique mobile identity and an isolated backend resource set. Source code remains shared through the vertical apps and common packages. Avoid copying shared code into tenant forks; drive differences through tenant manifests, branding assets, native identifiers, and deployment configuration.

• Keep the platform password and session secret in managed secrets, never source code or manifests.
• Rotate shared platform credentials when operator access changes.
• Use distinct tenant secrets for OTP/session hashing, admin bootstrap, SMS, push, and other providers.
• Never reuse a D1 database, R2 bucket, or queue binding across tenants unless the architecture explicitly changes.
• Review app IDs and custom domains for ownership conflicts before deployment.
• Store mobile signing credentials in the approved CI secret store.
• Record provisioning and deployment approvals outside the current console until full audit workflows are implemented.

The current implementation creates and lists tenant records, uploads a provisioning logo, and produces manifests. It does not yet edit or delete tenants, create infrastructure automatically, rotate credentials, manage individual Super Admin accounts, activate records, or publish mobile builds. Those actions must remain in controlled operational procedures until corresponding product workflows are implemented.