Platform
“I logged in and there are no applets at all.” If that, or “my colleague can see it and I cannot”, or “the scheduled job never ran” brought you here, the answer is probably one folder over. The pages in this folder describe consoles that BigLedger’s own staff use to run the platform: tenants, logins and the applet registry. Your own administrator works in Tenant Admin, the Scheduler and the approval settings, which are documented elsewhere.
Whose screen it is, and what it changes
Most of the first six are BigLedger’s. Platform SysAdmin authorises on a platform system-administrator rank carried in the login token, and Tenants V2 on platform permissions on the login, not on the roles your tenant administrator manages. Each page says what the screen changes behind it and where it stops.
| Applet | Whose screen | What it is for |
|---|---|---|
| Platform SysAdmin | BigLedger’s platform system administrators | Tenants, which logins belong to each and at what rank, and the catalogues that decide which applets a login is offered |
| Tenants V2 | BigLedger staff | The same tenants, through the older screen. Its Add Member writes to the tenant you are signed into, not the one on screen |
| Developer and Developer SysAdmin | BigLedger’s platform developers | The applet registry. Registering an applet installs it for nobody; that is Platform SysAdmin’s step |
| ETL Virtual Applet | Nobody opens it | A registry row an integration’s service login is installed against, so it gets a rank like a person |
| Issue Tracker | A support desk tracking issues for the customers it serves | Issues, sprints, a kanban board, and an optional two-way GitHub sync |
| Change Email Phone Number | The person whose login it is | Changing the e-mail or mobile number you sign in with, copied into every tenant the login is linked to |
The next four are where a tenant’s own people work:
| Applet | Whose screen | What it is for |
|---|---|---|
| Tenant Admin | Your tenant’s OWNER and ADMIN users | Who is a user, which roles and permission sets exist and what each is scoped to, and which applets are installed for whom. For a new tenant, or its first owner, go to your BigLedger contact |
| Applet Store | Any signed-in user | Installing, for your own login, an applet from a catalogue you are offered |
| Scheduler | Your tenant administrator | Clocks: a background job, a timetable and a status. It knows nothing about whether the job worked |
| Workflow Design and Document Approvals | Your tenant administrator | A status track on a document, or an approval sequence with e-mails. The two features do not read each other |
Which one to pick
- A new colleague needs to sign in. Tenant Admin, once your tenant has an owner. For a new tenant, or its first owner, go to your BigLedger contact.
- They sign in to an empty launchpad. Their login is linked to the tenant but nothing is installed for it. Install from Tenant Admin (Platform Users > Available Applet), or let them install from the Applet Store what their catalogue offers. If the applet is in no catalogue you are offered, ask your BigLedger contact.
- “My colleague can see it and I cannot.” For example, a stock controller who cannot run a report that works from your login, or a branch supervisor who can pick every branch’s location. Both are roles and permission sets in Tenant Admin. A permission with no target is unrestricted, so check the scope before the role (Teams and Permissions).
- You want a new sign-in e-mail. Change Email Phone Number, from your profile, rather than asking an administrator.
- A job should run every night. The Scheduler.
- A purchase order should wait for a manager. Document Approvals, not Workflow Design: a status track sends no approval e-mail.
What runs when nobody presses a button
Two kinds of background work run without a button. Finalise starts one primary job processor, which queues only the follow-on jobs (journal, stock, points, e-invoice and others) your tenant is subscribed to; the Scheduler does not list subscriptions, so ask BigLedger which your tenant holds (How work actually runs). Clocks in the Scheduler fire on a timetable; a new tenant gets a set of defaults, all ACTIVE. Last Run Date proves only that a clock fired, and Run Now’s success only that the job was handed over — the job’s own output is the proof it worked. The Scheduler page lists the default clocks, why a tenant may lack some, the monthly check, and the troubleshooting table for a clock that never moves.