Platform
These applets run the platform rather than a business. They are registered with an applet
type of ROOT-ADMIN or ROOT-USER in the applet registry, they read and write the shared
akaun_master database rather than a tenant’s, and most of them authorise on the caller’s
platform system-administrator rank — a claim carried in the login token — rather than on the
permission tables a tenant administrator manages. A tenant’s own finance or operations staff never
open them.
Three platform applets are documented in other sections and are not repeated here:
- Developer SysAdmin Applet — the applet registry console: registering an applet, its vendor, store listing, pricing and catalogue placement.
- Tenant Admin Applet — one tenant’s own administration: its users, roles and installed applets, from inside that tenant.
- Applet Store — where a signed-in user browses and installs applets.
Platform-level reference for the system administrator console: tenants and their users, platform users, catalogues, subscriptions, applet stores, hostnames and the system-administrator list itself
Platform-level reference for the earlier tenant-maintenance applet: list tenants, create one, edit its name and status, add members, and set a per-tenant password policy
Platform-level reference for the original applet-registration screen: list the applets in the registry, register a new one with its code, router link, bundle URL and custom element tag, edit or delete it
Platform-level reference for the self-service screens that let a signed-in (or access-key-authenticated) user change, or add, the e-mail address and mobile number on their login, with a verification code at each step
A registry row with no screens: the applet record that ETL (extract-transform-load) client logins are catalogued and installed against, so that they can be granted access like any other applet user